In this three-part series, Wes Noonan, author of "Hardening network infrastructures," will review steps you can take from both a Windows and network perspective
to protect your data regardless of what is occurring at the network perimeter. Click to jump ahead to part two on eight ways to protect Windows from perimeter threats or part three on five ways to control network access.
Known for its coverage of tools and techniques to combat hackers, the recent Black Hat Briefings held in Las Vegas brought attention to yet another problem that many IT professionals overlook -- the "de-perimeterization" of the network.
De-perimeterization means that the network perimeter no longer does an effective job blocking malicious traffic. It may still keep out some unsavory things, but overall the perimeter is becoming more and more porous, leaving many doors open for unauthorized access to Windows systems.
Network administrators often allow HTTP, SMTP, DNS, terminal services, rix, VPN and all sorts of other traffic through firewalls because the business demands it. In turn, exploits typically use these "permitted protocols" as a distribution method, enabling them to traverse the network perimeter.
For instance, if the firewall permits HTTP and an exploit uses HTTP to propagate (i.e., CodeRed), the traffic may go right through your firewall. Consequently, you may consider removing the network perimeter because it is no longer an effective security barrier -- or is it?
Now, I personally wouldn't go so far as to say, "Yep, you can go ahead and get rid of your firewalls," but I do think a porous network perimeter can be a security nightmare. Think about your own network perimeter. In many cases, I bet you can identify at least 10 protocols permitted through it -- not including things like VPN-related traffic.
What can you do about this problem? Some say the answer is to close the perimeter, but that isn't being realistic. Security has been and always will be pitted against business needs. The perimeter is porous because business requirements dictate that traffic from SMTP, HTTP or VPNs need to be able to pass through the firewall.
The solution is to stop relying exclusively on perimeter devices such as firewalls, VPN concentrators and network-based intrusion detection and prevention systems for data protection. Instead, focus on how to protect your internal Windows resources and the data itself, while also maintaining a strong and secure network perimeter.
You may recall the Twinkie analogy for network security: hard on the outside, soft and gooey on the inside. This is the old method of securing the network; it's a model that frankly no longer applies as new exploits have been released. This method frequently overlooks what we ultimately try to protect -- the data.
Now that I have explained what not to do, I'll cover what you should do over the next two articles in this series. I will review steps you can take, from both a Windows and network perspective, to protect your data regardless of what is occurring at the network perimeter. I will discuss how to configure your Windows servers and network devices, and offer some actions to take at the network perimeter, to ensure that your data is protected. Overall, I will cover how you can effectively and functionally de-perimeterize your network, without removing the perimeter completely.
About the Author
Wesley J. Noonan has been working in the computer industry for over 12 years, specializing in Windows-based networks and network infrastructure security design and implementation. He is a senior network consultant for Collective Technologies, LLC (www.colltech.com). Wes recently authored the book "Hardening network infrastructures" for Osborne/McGraw-Hill and previously authored a chapter on network security and design for "The CISSP training guide" by QUE Publishing.
For More Information
Learn 10 steps NOT to take when securing your Windows perimeter.
Find out how many companies are restructuring network policies today.
View our collection of the Web's best resources about network infrastructure security.
This was first published in September 2004