Security Watch

Protection Through Isolation

By creating internal network segments, you limit the reach of unauthorized users.

• By Roberta Bragg
• 08/23/2004

It's not that they doesn't trust most employees; it's just that they're wise in the ways of the world. Contractors and visitors bring laptops instead of yellow pads; they also carry wireless PDAs, smart phones and other devices that may be able to connect to the network. Traveling employees and those that do some work at home can return to work with computers that may have been on untrusted networks. There's no question that some of these devices may enter the network infected with malware or compromised in some other way.

One solution is to create internal network segments and keep trusted, managed computers separate from those that aren't. Isolate sensitive systems, such as financial and human resources databases, from the general employee population. Firewalls and packet-filtering routers may be used to segment the networks, and VPN servers may sit on the borders. By requiring authentication, access can be restricted to a limited number of approved employees.

Still, there will be times when unmanaged, untrusted computers may gain access to that part of your network employees must use daily. How can you prevent them from being used to access network resources? Using hardened access controls and authentication can help, but what if someone has access to a user ID and password? If unauthorized users have someone else's credentials, they have that individual's access to resources. And employees bringing computers from home can use their domain credentials to access resources. An attacker might be foiled by a firewall, but if he's able to gain access to the network from the inside, his attack stands a much greater chance of success.

One way to thwart these scenarios is through the use of IPSec polices to prevent connections from unmanaged computers. An IPSec policy can be configured to insist on machine authentication before connections are allowed to proceed. This type of policy doesn't need to require encryption, nor specify IP addresses or ports. In short, when implemented, it will refuse a connection unless the requesting computer presents appropriate credentials. IPSec even provides three choices of authentication credentials: a shared secret, Kerberos or certificate. Shared secrets should only be used for testing. After all, if a lot of people must know the secret, it's quickly no secret at all. Kerberos may be a good choice if all clients and servers are domain members But in many cases, certificates may be the best way to go.

Before you assume that this solution is way too complex or time-consuming for more than a small network, consider this: Microsoft uses certificates and implements just such a solution for tens of thousands of machines on its corporate network. They call the process "Domain Isolation." Read about it at http://www.microsoft.com/technet/itsolutions/msit/security/
ipsecdomisolwp.mspx.

Microsoft lists a number of benefits, including:

• Mitigating the risk of unmanaged computers on the network
• Gaining a better understanding of exactly which computers on the network are managed and, perhaps more importantly, which aren't
• Increased protection of intellectual property; unmanaged computers can't be used to access this data
• Improved malware detection; malware that replaces core network stack components prevents IPSec from functioning (IPSec won't work if the network stack isn't intact)

My Bad

Last week I incorrectly reported that the Microsoft-provided tool or Registry entry, meant to prevent download of XP SP 2 from Windows Update or by using XP's automatic updates, would also prevent downloads from SUS servers. This was incorrect. If SUS administrators have approved XP SP2, all XP clients that obtain updates from that SUS server will be able to download XP SP2. If you use SUS and want to block XP SP2, don't approve its distribution. If some computers can have XP SP2 and others shouldn't, you could point these clients to separate SUS servers; one of the servers should not have approval for XP SP2.

Thanks, and a Request

I get a lot of very valuable feedback from you — the readers of this newsletter. You catch my mistakes, thank me when I help out, and tell me what you want to see more or less of. It's really great and I'd like to thank you.

As some of you know, I also write books. I get feedback on them too, but it's usually after the book is published, and I can't do anything about it; it's way early for a revision, or I start another one. I've been trying to figure out how to change that. I've tried e-books, but again, the chapters are published and no one wants to go back and change them. I'm wondering if it would be valuable to offer chapters in the making for review?

If I can get volunteers, I'll provide them with chapters during early drafts. I'd expect comments and criticisms — things I can do to make the book more valuable. I'm not looking for technical editors or co-authors; just IT pros with an opinion. Suggestions might be in the form of recommended revisions, or simply comments on what you'd like to see in the chapter; and what information, explanation or analysis would be helpful. Telling me when I'm providing what you want would be helpful, too. If any of this makes sense to you, and you'd like to participate, please let me know.