Security Manager's Journal: Taking steps to better lock down the network

Our manager decides that, like users, resources on the network should adhere to the rule of least privilege.

The resources on our network have been given too much access to the Internet, and we need to curb that.

One of my primary security philosophies is the rule of least privilege, which can be defined as the practice of granting only the minimum amount of access necessary to get work done. Typically, the rule is met by defining role-based access to applications or data, but I extend this philosophy to all areas of business. This week, I prepared to apply the rule to resources on our network.

Consider production Web servers. They serve up Web pages to the public, so you would expect them to accept requests from the Internet. But what access is needed in the other direction? Should an administrator conducting maintenance on the server be able to use it to access his Yahoo email, Facebook or (shudder) Dropbox? In fact, except for a very small portion pertaining to business-related activity, the vast majority of the Internet should be unavailable from that Web server.

I decided to have my security engineers work with the network team to explore this issue and start to prioritize the work we would need to do. I had them focus on four areas.

The first is the production server network, which includes our DMZ, production and test (preproduction) networks. When you get right down to it, those servers need very little access to the Internet. And many security breaches are successful because a server was able to initiate a connection to a command-and-control server or some other malicious location on the Internet. Our firewalls currently allow virtually any traffic originating from the production network to the Internet. That has to be curtailed.

The next area is our R&D network. Servers on that network also have little reason to initiate a connection to the Internet, but the engineers who work in R&D need to innovate, so I'm willing to be a bit more flexible. Those same engineers, however, constantly complain that patching and antivirus software cause performance to deteriorate, and they refuse to comply with our requirements. Because of this, we isolate the R&D network from the rest of our network.

The third area is our corporate network, or what some call the PC network, since it's reserved for all our PCs. We can't completely lock it down, since we give a good deal of latitude to employees when it comes to accessing the Internet. Nonetheless, we can put some things out of bounds, and so we reviewed our firewalls' ability to block certain categories of websites and applications that could lead to problems for legal, HR or security. We already block pornography, malware and spyware sites. We will be adding phishing sites, anonymizers (which employees use to bypass our filtering), peer-to-peer sites, remote control services (such as LogMeIn), parked domains (Internet domains with no services) and personal file storage.

Finally, there's our critical zone, the area of the production network that contains our most critical resources. Currently, we allow all corporate traffic to this area of our network, when in reality, employees mostly need merely to have Web access. Now that we've incorporated user identity into our firewalls, we can create rules based on who you are and restrict administrative access to our critical resources to those administrators who need it.

Simple, right? Just configure the firewalls and block traffic. Unfortunately, in order to implement all of the changes I've mentioned, we have to conduct a business impact analysis, since we can't afford to make changes that affect our ability to deliver products or services. Therefore, the next course of action is to study the current network traffic to understand any valid business requirements before executing the plan.

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.

Join in the discussions about security!
computerworld.com/blogs/security

FREE Computerworld Insider Guide: IT Certification Study Tips
Join the discussion
Be the first to comment on this article. Our Commenting Policies