Protection Through Isolation
By creating internal network segments, you limit the reach of unauthorized users.
- By Roberta Bragg
One sure way to protect sensitive computers and systems from attacks is to segment
networks. If firewalls sit between your network and the Internet, you're already
doing some of this; using perimeter defenses is always a good strategy. But no
admins worth their salt rely on perimeter defenses alone — they ensure that
their networks aren't soft and chewy on the inside.
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/
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
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.
About the Author
Roberta Bragg, MCSE: Security, CISSP, Security+, and Microsoft MVP is a Redmond contributing editor and the owner of Have Computer Will Travel Inc., an independent firm specializing in information security and operating systems. She's series editor for Osborne/McGraw-Hill's Hardening series, books that instruct you on how to secure your networks before you are hacked, and author of the first book in the series, Hardening Windows Systems.