People often ask me which OS is the most secure, and my answer is the OS with the best administrators. The most important factor in your overall network security is how well you manage the network. A large component of managing network security is knowing which systems are present on your network, finding security holes, and getting them fixed. Even well-built, well-managed systems are vulnerable to ever-new security risks, so running one or more network security auditing tools is essential.
You need to audit your entire network, not just the parts that you think are important. Although smaller networks can use the easy-to-manage security model of allowing only one way in or out through a firewall, a larger network must have many access points. Using a hardened perimeter to protect a large network is becoming as obsolete as using moats and drawbridges to protect a city. Internal security is important in the event of a virus-borne attack as well. If you properly protect your network shares, a virus can't corrupt as many files. Finally, attackers can use unprotected, seemingly unimportant systems to obtain access to crucial systems.
Choosing Your Software
Choosing a vulnerability scanner is difficult. Several scanners are on the market, and each one claims to be the best. The more comprehensive scanners check for hundreds of vulnerabilities, and they frequently have different names for the same check. Tools that follow the Common Vulnerabilities and Exposures (CVE) list are easier to compare. (For information about CVE, visit http://cve.mitre.org/about.) Making comparisons even more difficult is that under the covers, these tools work differently. Comparing the available scanners is beyond the scope of this article, so let me give you a few general guidelines so that you can do your own research and choose the package that best suits your needs. "Related Articles," page 2, contains references to many product reviews available on the Windows 2000 Magazine Network Web site and is a good place to start your search. Here are some tips to keep in mind when you select your scanner.
Your needs depend on your environment. Each scanner has strengths and weaknesses, so choose a scanner that's strong in the areas important to your environment. For example, a network with mostly one OS needs a scanner focused on that OS. You might also consider buying a specialized scanner for particular system types, such as Web servers or databases.
A "living" scanner is best. The best scanners are those under active development. Good vendors issue regular updates to enable the scanners to check for newly discovered vulnerabilities and exploits.
Completing the scan is only a small part of the job. After your scan is completed, you must fix all the holes. You need time to evaluate the quality of each vulnerability description and the fix information. On a large network, you can find thousands of vulnerabilities; therefore, managing the information about the problems you find becomes important.
You might also consider using more than one scanning product. Every scanner has some checks that don't work as well as others because of developer error or the difficulty of writing a particular check. For example, I wrote a check that has a 50 percent false-positive rate. However, I use it because it reduces 3000 candidate systems to only 20 or 30 that I have to manually check. Running more than one scanner is like getting a second opinion.
Preparing to Scan
Let's look at what you need to do before you use a scanner on your network. I've seen instances in which administrators simply installed the scanner, turned on all the possible checks, then proceeded to cause mayhem on their networks. If you'd like to keep your job, I wouldn't advise this method.
Before you run a security scanner on a network, you need to notify administrators (and possibly end users) that you're going to conduct an audit. The extent of the notification depends on the size of your network. In a small company, you might simply send a broadcast email message. If you're dealing with a larger network, you might need to follow more formal procedures, such as making an entry into change control to notify the Help desk and operations.
I ran a surprise scan of a fairly sensitive network, and the scan caused an email flood the next day when surprised administrators checked their logs, discovered an attack, then notified all their friends. As you increase the intensity of your scans, make sure you notify crucial support people. Although it's unusual, network infrastructure hosts can die unexpectedly. If the administrators don't know what you're doing, you might repeat the scans and continue to cause problems.
Network security auditing tools can have adverse effects on the network and on the hosts they scan. Some problems that scanners can cause are well documented. For example, nearly every scanner has a set of Denial of Service (DoS) attacks. If you run DoS attacks against unsuspecting systems, you'll cause a lot of damage and have only yourself to blame. If you need to run DoS attacks against your network, target them against a limited number of systems at a time, and be sure that the relevant administrators are standing by to quickly deal with any problems that might occur.
Other problems can crop up from seemingly benign activities. For example, some older versions of the Hewlett-Packard (HP) JetDirect network printer devices can fail because of a simple TCP port scan. (For more information about this vulnerability, see SecurityFocus.com at http://www.securityfocus.com/vdb/bottom.html?section=discussion&vid=1124.) Although SecurityFocus.com cites Nmap as the tool that causes the problem, nearly any port scanner can cause problems with these devices. Your scanner is a powerful tool. If you're careful and use it correctly, your network will be much more secure.
For your first scan, enable only a few scanner checks. The objective is to identify what's on your network. Most networks, particularly large networks, change frequently. You'll also use this scan's results to target which checks are important to you. For example, I don't have many UNIX systems on my network, so I disable many of the UNIX-specific checks to speed up my scans. If you have a large network, you might want to divide your slower, more intensive scans into manageable network segments.
When you have a basic understanding of what's on your network and how many hosts you have, you can gradually increase the number of checks you run and create targeted scans. For example, a suite of UNIX remote procedure call (RPC) checks can take a long time to complete, especially on systems not running UNIX RPC services. Running these checks on a network segment full of Windows systems will slow down the scans. However, sometimes Windows systems (especially Win2K or Windows NT systems) have services running that you'd typically expect to find only on UNIX systems, so targeting your scans for different sets of vulnerabilities will let you be thorough but keep your scans from putting a heavy load on your network.
Vendors typically market a scanner based on the number of checks it has. However, that number isn't always an indicator of a product's effectiveness because some checks cover areas you're unconcerned about. For example, if your corporate policy says all users must set workstation restrictions, a scan to see which users aren't in compliance would be useful. However, if your corporate policy doesn't require assigning workstation restrictions, turning on that check will give you results with thousands of "vulnerabilities" that you don't care about. Learn about the checks, and turn off the ones that don't apply. You can create several scans: a scan that looks for your top 5 or 10 problems, a scan that's more comprehensive, and scans targeted for different system types.
As I mentioned earlier, be especially careful when running any check labeled as a DoS attack. Some scanners can check for DoS vulnerabilities without crashing a server, and others can't. Password-guessing attacks can also place a fairly high load on some systems because, to complete scans in a reasonable amount of time, scanners usually open several connections at once. Most scanners let you configure the number of connections, and although the default settings don't usually disturb a regular workstation or server, they might put high loads on some network equipment.
Understanding Scan Results
After you conduct your scans, you need to interpret the results. A blank-administrator-password vulnerability in the results is easy to understand, but what about colorful vulnerability names? For example, people name attacks after cartoon characters; even some of the more straightforward names are sometimes convoluted, and their meaning isn't obvious from their name. Drill down on the vulnerabilities, pull up the scanner's Help system, and learn what the vulnerabilities mean. Sometimes the details are important. Vulnerability scanning isn't a precise science, and you'll have to do a little extra work to see whether a system is really vulnerable or whether a reported vulnerability is truly a concern.
An understanding of the checks the scanner performs is essential in some cases. Consider a Web server vulnerability that depends on certain files being in just the right place. It's hard to write a scanner that consistently finds these vulnerable systems, and you'll likely end up with a check that finds only the vulnerable systems that are easiest to exploit. If the same scanner can leverage administrator-level access to the file system and check file sizes and versions, it can much more accurately determine whether a hotfix is missing. When you take the time to learn exactly how some of these exploits work, you can use a scan as a first step to determine how many of your company's important assets a problem places at risk.
Taking Corrective Action
Now comes the hard part—you need to fix all these problems. First, take care of problems on crucial systems—the ones your production servers and systems network administrators usually log on to. Next, fix the biggest problems. Worrying about an obscure attack that works only if several conditions align is senseless if you have blank administrator passwords and missing patches.
If you have a large network, identify who's responsible for which systems. You can then create individual reports that list only the problems each administrator needs to fix. Learning who's responsible for what can be quite a bit of work, and it might take some effort to track down the right people.
After you've started notifying administrators about fixes they need to make, check subsequent scan results to see where you find improvement. Thank the people who fix things promptly, and if you have a network segment in which problems remain, check to be sure you're notifying the correct person. If you thoroughly understand a particular vulnerability, provide a demonstration of it to prompt an unresponsive administrator to close the security hole.
What to Do If Scans Cause Problems
Some people might blame your security scans for everything that goes wrong on the network. If someone complains that your security scans are causing problems, first check to see whether the same problem is happening to other systems with the same configuration. Next, check to see whether the problem occurs only during scans. Try performing controlled tests, in which someone carefully monitors the system while you scan it. If you can reliably reproduce the problem, you need to do a little detective work to determine which vulnerability check is causing the problem. When you isolate a problem to a particular check and type of target system, contact the vendors of both the target system and the scanning tool. The vendors might be unaware of the problem, and one or both vendors might need to make changes to their products. In rare cases, you might even end up with your name on a security advisory.
Let's look at two real-life examples of scanners as scapegoats. These experiences are useful for demonstrating what you might expect when you incorporate vulnerability scanning into your security picture.
One of my network administrators asked me to stop scanning her system because her machine was randomly locking up. She was angry because she thought that the scanner was "abusing" her system. I had no reports of other systems doing the same thing, so I told her that I didn't think the scans were causing her problems. The problems continued, and she became angrier. The scanner had timestamps in the scan logs, which I consulted to see when her system was being scanned, and the NT 4.0 audit logs on her computer showed the scanner's password-guessing attempts. Her system logs also showed some I/O errors that happened at times when the system wasn't being scanned. A closer investigation revealed that she had a CD-ROM drive that was slightly out of balance, and its vibrations loosened her CD-ROM's IDE cable. When the cable started making intermittent contact, it caused problems with the motherboard. After she replaced the CD-ROM drive, the scanner wasn't quite so "abusive"!
A second problem came up when some network devices were showing high load levels only when they were being scanned. These devices turned out to have a Telnet service, and the scanner was trying to quickly check a lot of passwords on that service. To remedy the problem, I excluded those systems from scans until the administrators could reconfigure the systems to accept Telnet sessions only from networks the device's administrators would be logging on to.
Keeping Up the Good Work
New exploits constantly appear, and networks change. So run your scanner regularly, and keep your scanning software up-to-date. Some vendors offer update-notification services, but checking their Web sites for updates is still a good idea. Subscribe to one or more security-related mailing lists, such as the Windows 2000 Magazine Network's Security UPDATE (http://www.win2000mag.net/email), to keep abreast of new attacks. If the code or details of an exploit are available, you might want to manually check your systems for the vulnerability until your scanner vendor gets the check built into the software. You should also compare the results of your manual check with the results of the vendor's check.
Most likely, one check will work better than the other, so don't blindly switch to the vendor's check until you're sure it works as well as what you have.
A security-auditing tool can substantially improve your network security—if you use the tool properly. However, scanners don't always find every vulnerability, and the most secure OS is still the one with the best administrators.
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com.|
MARK JOSEPH EDWARDS
"The Handy Security Toolkit Revisited," October 1999, InstantDoc ID 7192
"The Security Suite Spot," October 1999, InstantDoc ID 7208
"WebTrends Security Analyzer 2.0," August 1999, InstantDoc ID 5770
Lab Notes, "2nd Annual Labsolutely Awards," January 1999, InstantDoc ID 4702
You can obtain the following articles from the Windows IT Security Web site at http://www.WindowsITsecurity.com.
"CyberCop 5.5," May 2000, InstantDoc ID 9203
"HackerShield 2.0," May 2000, InstantDoc ID 9206
"Internet Scanner 6.1," May 2000, InstantDoc ID 9205
"NetRecon 3.0," May 2000, InstantDoc ID 9204
"WebTrends 3.0," May 2000, InstantDoc ID 9207