2010 Security Resolutions

Many people create New Year’s resolutions to motivate themselves to improve on something. Let’s do the same thing for the security of our IT environment. My advice for security would be to keep it simple and remember that security is a process, not an end-point. Everything we do that raises our bar a little higher and makes it more difficult for bad things to happen – whether it’s malicious or unintentional – is a good thing. Here are two resolutions that you should follow to make your environment more secure.

Defense in depth: I know that’s a catchy phrase that you see in many places but it’s a great way to think about security. The opposite, to state the obvious, is a single point of failure. If you have only one way to protect a resource, any time that protection is either compromised or disabled, you are going to be vulnerable. Just like this list, I like to keep things simple. List out three, four, or five things that you care most about protecting in your environment. Do you have at least two ways (three ways?) that each of those resources is protected? If not, take the initiative to add one layer to each one.

In almost all cases, the best protection is an actual mechanism (technology) that enforces the policies you have defined. It’s good to have a policy that states how passwords will be handled, it’s better to have a mechanism that enforces it. If you can add a mechanism to raise the bar on one of those 3-5 resources you just listed, do it. If not, then at least add some type of process or policy that helps you. For example, if a Web application you have is not instrumented to log security exploits (i.e., create an alarm if somebody is injecting cross site scripting text or trying some type of command injection), then create an automated process (script) that periodically reviews the Web logs to look for those events and create an email or some type of event for somebody to follow up on. Don’t be afraid to use simple techniques that make a big difference in either preventing or detecting when things are not going well.

Controlling Network Traffic: I want more people to accept the fact that they need to be just as concerned about what goes “out” of their network as they are about what comes “in.” Almost every organization has spent a lot of time thinking about how they want their routers, gateways, or firewalls setup to filter, forward, route, or block incoming traffic. Unfortunately, most of these same organizations have not spent a lot of time thinking about how to address outgoing traffic. Often, they will allow most if not all traffic “out” to ensure they don’t introduce access issues for people inside the boundaries of these devices.

In a nutshell, most viruses, Trojans, and worms succeed because of this situation! Most of these kinds of problems depend on the ability to get around to other systems near them (because people tend to trust systems on the inside) and then to propagate themselves to other systems and networks. This often succeeds because trust levels are too high within a particular network segment and outbound traffic isn’t managed very well.

A good starting point for defining rules for your outgoing traffic is to start with the same rules you just setup for incoming traffic and adjust only for those ports, services, or protocols that are absolutely essential. Not only will this help to thwart “infections” you do incur on the inside of your perimeter, it will help to minimize unwanted traffic and save more bandwidth for production and work oriented services.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published.