Chapter 5: Application Security Needs

Overview

The security of your organization is going to live or die according to the security of your applications. This is true regardless of whether your application is a firewall, VPN gateway, file server, or network printer. Due to the enormous variety of applications and security configurations, this is not a book that can offer configurations on all possible configurations, but we can hit on some of the highest risk areas.

Many times when lecturing or consulting, I am asked the question, "What is the single greatest step I can make in securing my network?" This invariably launches me into a ten-minute discussion that good network security is never a single action, but a combination of actions. There is no single technology that will make your network more secure. Once that explanation is clear, I am then invariably asked the familiar question, "What is the single greatest step I can make in securing my network?" Depending upon my mood at that point, one of the most accurate answers I provide is to, "Keep up to date on your security patches."

It is sad to say, but the majority of network administrators are lax in their attention and application of security patches. Network administrators have a number of good reasons to behave this way. First, few administrators have the luxury of being full-time network security professionals. They have any number of things on their plates on a daily basis, from fixing the loose RJ-45 jack on Nate's computer to explaining to the CEO how to check e-mail while they are in a hotel room. Wading through security bulletins and picking out the patches that are critical to their systems can be time consuming.

Many system administrators have also been burned applying a security fix. Most experienced administrators can relate a story of a simple "fix" that ended up breaking a mission-critical application. Nobody likes spending the weekend fixing something that should be working in the first place. Even worse, nobody likes spending a workday fixing something that was working last night while their supportive user base offers one helpful hint after another. Instead, it is often easier to not install a fix when it is released but, instead, schedule some downtime on a semi-periodic basis and apply many fixes at once. An even better solution is to create a test network where the patches can be installed and assessed for impact prior to applying the fix to a production network.

Still other system administrators just do not know how or feel comfortable working with vendors' patches. Many times, instructions can be cryptic and difficult to understand if you are not working with the program on a daily basis. Most system administrators have so many responsibilities that they are rarely experts in any one element of their network. It is easy for individuals who are slightly uncomfortable with a procedure to put it off. If you do not believe me, think about the last time you had to go to the doctor.

Unfortunately, not taking the time to apply security patches is one of the number-one vulnerabilities that a network will face. Applying security fixes to a working configuration is usually a matter of understanding the basics of network security, reading the documentation of a product, and checking the right options on a configuration screen specific for your organization. The very nature of a patch means that something that you thought was working correctly is not. Thus, a network administrator may initially start with a network configured to meet the needs of their security policy, but as time passes and new vulnerabilities are discovered in the hundreds of applications and services that the average network runs (many of which users and administrators do not even know are running), the network moves further and further away from the goal of the security policy. All of this happens without the network administrator changing a thing on the network.

The shameful result is that most networks are compromised by attacks for which prevention already exists. From time to time, information security reports will reveal a totally unknown, new attack that has compromised a large number of systems or caused other havoc, but most attacks take advantage of the fact that hackers are more efficient in utilizing old vulnerabilities than administrators are in patching them.

A simple example of this is that as I write this chapter, the SQL Sapphire/Slammer worm is attacking large portions of the Internet. While the attack itself is interesting in the aggressive nature that the worm takes in spreading itself, the vulnerability that has allowed this worm to spread has been known for about six months. Furthermore, Microsoft had released a patch to prevent exactly this type of event. Nevertheless, large portions of the Internet are being rendered unusable due to the number of systems that have been affected and the IP traffic that the worm generates. Just to illustrate the difficulty in keeping up-to-date with patches, it turns out that Microsoft itself has been hit with the worm.