ISAserver.org Monthly Newsletter of April 2011 Sponsored by: Portcullis Systems

Welcome to the ISAserver.org newsletter by Debra Littlejohn Shinder, MVP. Each month we will bring you interesting and helpful information on ISA Server. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to dshinder@isaserver.org

1. The Role of the Firewall in Data Leakage Protection

Over the years we've talked about the best ways to focus our security efforts. Sure, it would be great if we all had unlimited time and unlimited resources so that we could enable the highest levels of security at the network, client, server and data levels. But for most of us, that day never existed and it's never going to exist. And as things stand right now, for the foreseeable future you can probably expect to get fewer resources in terms of time and money to spend on your security efforts.

So exactly where should you spend your time and money and training? One way to answer this question is to see what it is that you're actually trying to accomplish. To begin your analysis, consider the following questions:

• Is your goal to prevent external users from reaching your intranet?
• Is your goal to log all connections from the Internet to your intranet?
• Is your goal to log all connections from your intranet to the Internet?
• Is your goal to prevent a denial of service situation for your Internet link?
• Is your goal to prevent a denial of service situation for some server workload?
• Is your goal to encrypt communications that move over the network?
• Is your goal to prevent unauthorized users from accessing corporate information?

Of course we want to do all of these, but we're talking here about narrowing our focus. There's a good argument to be made that if you need to focus your security efforts, you should make the last option your goal. When you think about all the high profile security breaches that have occurred in the last few years, the problem generally was that someone who was not authorized to access some collection of information got access to this information and was able to easily disseminate the information for which that person had no rights (was not authorized to view).

There are a number of measures you can take to prevent this. You can try to place strict controls at the perimeter in an effort to keep the bad guys out. You can also place controls at the perimeter to prevent users from posting content to public sites, such as public web mail sites, public file storage and sharing sites and others, or you can focus on configuring permissions to restrict access to services or files.

Alternately, you can move your security focus all the way back to the actual data itself. One way to do that is through rights management. In all of the high profile security incidents you've read about in the last few years, most of them could have been prevented if the information that was stolen had been rights managed. When data is rights-managed, only authorized individuals can read that information. In addition, rights-managed information can also be configured to "time out" or "self-destruct", which adds even more security to the content because it helps ensure that information doesn't just "sit around" waiting for inadvertent disclosure.

Rights management - like most of the measures we apply to protect our data - can circumvented, of course. But it's unique in that it doesn't just work to prevent unauthorized persons from getting access to data directly; it also helps to prevent authorized persons from inadvertently or deliberately sharing the data with those who shouldn't have access to it. If you could enforce rights management on all high business impact data in your organization, you might be able to reduce your investments in other areas of security enforcement. But what does this have to do with the firewall, and what's the role of the firewall (or what should be the role of the firewall) in a rights-managed environment? And specifically, what opportunities are there for the TMG firewall, in the future, to take advantage of rights management as a core security strategy?

As I see it, we spend a lot of time trying to block our users from reaching particular sites that might enable them to leak information. In the long run (and even the short one), this is pretty much a losing proposition because you'll never be able to keep up with all of the sites, and in many cases, you want users to be able to send files as email attachments or post them to public shared directories - you just don't want them to share the wrong files.

Instead of blocking sites, then, how about having the TMG firewall block content that isn't rights-managed? The TMG firewall would inspect the file, determine whether rights management has been applied to the file, and if the file is rights-managed, then the TMG firewall would allow the file to move past the perimeter.  Even better, you can also configure the TMG firewall to require specific rights management policies that you determine are appropriate for posting information to an Internet site, so that you have different rights management policies for posting to a public site versus a partner site.

Pairing rights management and rights management enforcement at the TMG firewall might just be the magic bullet that makes the TMG firewall a "must have" component on all networks.

Let me know what you think. Do you think that rights management applied to information is one of the places where you can get the most bang for your buck? Do you think that putting rights management intelligence into the TMG firewall would be a killer app? Or do you believe that with limited resources, we should focus on something else rather than rights management? Send me your opinions at dshinder@isaserver.org.

See you next month! - Deb.
dshinder@isaserver.org

======================
Quote of the Month - "What men value in this world is not rights but privileges." - H. L. Mencken
======================

2. ISA Server 2006 Migration Guide - Order Today!

3. ISAserver.org Learning Zone Articles of Interest

• TMG Web Proxy Client Concepts and Configuration (Part 1)
• Forefront TMG Advanced Web Protection Overview
• TMG Firewall Interface Configuration
• Optimizing Performance on the Forefront Threat Management Gateway (Part 2)
• Customizing error messages and forms based authentication in Forefront TMG
• TMG Back to Basics - Part 6: Reports
• Celestix MSA Threat Management Gateway Series Voted ISAserver.org Readers? Choice Award Winner - Hardware Appliances
• Optimizing Performance on the Forefront Threat Management Gateway (Part 1)
  

4. ISA/TMG/UAG Content of the Month

Do you know what type of hardware you need for your TMG firewall? Do you know what type of hardware you need for each member of a TMG firewall array? What processor should you use, in order to get the most out of your TMG firewall? How much memory should be installed? How does the deployment scenario affect your choice of hardware?

If you don't know the answers, no problem! You can find out the answers to these questions and more in the article Forefront TMG 2010 Hardware Recommendations over here.

5. Tip of the Month

There several supporting services that you need to consider before you deploy a TMG firewall. These include DNS, DHCP, WINS(!) and more. Probably one of the most important considerations is the Public Key Infrastructure (PKI). The TMG firewall uses certificates to support a number of scenarios, including the following:

• Web site certificates that are used on Web Listeners to support incoming SSL connections to the TMG firewall.
• IPsec certificate to support remote access VPN client connections using L2TP/IPsec.
• IPsec certificate to support site to site VPN connections using L2TP/IPsec.
• Web site certificate to support remote access VPN client connections using SSTP.
• CA certificate, which is used by the TMG firewall to perform outbound SSL inspection.
• Computer (server) certificate to support authentication and encryption for TMG firewalls that participate in a workgroup environment.

You're obviously going to need a PKI to issue all these certificates. For more information on planning your PKI support for the TMG firewall, check out the article titled "Planning for server certificates".

6. ISA/TMG/IAG/UAG Link of the Month

Performance is something that always weighs on the minds of TMG firewall administrators. It's a high priority for those who need Internet access to get their work done. When users call and say "the Internet is slow", inevitably someone points a crooked finger at you and says,"it's the TMG firewall's fault".  Is it really the firewall's fault? How can you find out? What can you do to optimize performance for the TMG firewall? A good place to start by reading Richard Hicks' two part series on TMG firewall performance You can find Part 1 here and Part 2 here.

7. Blog Posts 

• TMG and UAG and NLB and Procurve
• Issues When Migrating from ISA to TMG
• Results for the Forefront TMG Contest Round One
• Preparing Forefront TMG 2010 for Enterprise Workgroup Deployment
• How Many TMG Firewalls will you Need?
• Questions for TMG Quiz 1
• DirectAccess Gets Props from The Register
• TMG Survival Guide on TechNet Wiki
• User Activity report for multiple users not working error 0xc0040432
• Block Attachment Download from Public WebMail Sites with the TMG Firewall
  

8. Ask Sgt Deb

QUESTION:

Hi Deb!

I have an ISA 2006 firewall. When I tick "require all users to authenticate" in "configuration -networks - internal - web proxy - authentication" SecureNAT computers cannot connect and if I don't tick "require all users to authenticate" in report and online user monitoring user name don't show up. Please help me!
Thanks! - Iraj

ANSWER:

Hi Iraj,

Thanks for writing! The problem you've run into is a common one. I assume that what you want to do is make sure that users authenticate before they can access the Internet so that their user names show up in logs and reports, allowing you to track who's doing what. To authenticate, client systems need to be configured as web proxy or Firewall (TMG) clients. You note that your SecureNAT clients cannot connect when you require authentication. The reason for that is that SecureNAT clients (that aren't also configured as web proxy or firewall clients) are unable to authenticate with the firewall, by definition. Now, there are third party solutions that will allow you to require SecureNAT clients to log on using a form and log the information so you can tell what user matches up with what IP address. An example is Captivate by Collective Software, which you can read about here.

Do you have any questions or ideas for content? Email me on dshinder@isaserver.org.