Conducting a thorough network security audit has never been more critical. Almost every organization is connected to the Internet in some way, the number of interconnections between organizations is growing, and the ranks of telecommuters are increasing. Of course, for an audit to be effective, you need to know where and how to look for vulnerabilities.

This article will present a comprehensive list of things that should be a part of a security audit, including procedures and potential tools to help you identify problems. In my next article, I will give you some tips on fixing the issues you may run across during your audit.

The preliminaries
Before starting a security audit, you should create a project plan that describes what you are preparing to do and the purpose of each step. Down the line, this document may be helpful if you need to go to senior management with procedural changes. Besides that, it gives you a script to work from and makes the process a little less chaotic.

A full audit should be comprehensive and include the following items:

  •         External and internal network vulnerabilities (including partner relationships)
  •         Remote user procedures
  •         Internal network vulnerabilities
  •         Host vulnerabilities (Windows, UNIX, Mac, etc.)
  •         Desktop software vulnerabilities and policies
  •         Password procedures
  •         Organizational procedures

As you can see from this list, much more than technology needs to be addressed to complete a successful security audit. A good audit will involve management and will evaluate the policies (or lack thereof) that an organization has in place regarding installed software, passwords, and so on.

Four phases leading up to an audit
A formal security audit consists of four phases:

  •         Assessment—During this phase, information is gathered and problems are identified and analyzed.
  •         Critical fixes—Problems that are extremely serious or that require only simple, quick fixes are addressed during this phase.
  •         Update other fixes—During this phase, fixes with low to intermediate priority are addressed.
  •         Continuing work—This phase never ends. The information from the prior three phases is used to continually maintain the environment and keep it secure. Of course, this process should be undertaken on a regular basis in order to keep things secure.

I will focus here on the assessment phase and on the critical fixes and update phases in my next article.

Assessment phase
Perhaps the most humbling aspect of assessing your systems is seeing just how vulnerable your environment is. Who knew that your predecessor had secreted holes in the firewall so he could remotely control the servers with VNC without having to go through the hassle of logging in to the VPN? That’s the kind of thing you are likely to find.

In addition, as organizations grow, so do their networks and services. But the way that everything interacts is not always carefully investigated. I’m sure that every reader can sympathize with the admin who gets handed a task when his or her plate is already overflowing and completes it as quickly as possible with every good intention of going back and fixing potential holes after the fact.

Gather information
If you are setting up the assessment for your organization and you played a role in developing its infrastructure, do your best to remove yourself from the situation. It will be hard to honestly assess the environment if you have to defend decisions you made in the past. If you do find yourself heading up the assessment efforts, you can take some basic steps to begin to investigate.

Talk to your IT department peers and create detailed, accurate network diagrams. This type of information gathering serves two purposes. First, it helps you to quickly identify where there may be major weaknesses in a network. Second, it gives you infrastructure documentation. By carefully diagramming the network as it exists—not from your memory—you may discover, for example, that there is a network connection from the switch in front of your firewall to a switch behind it.

Uncover weaknesses
Use software tools to look for weaknesses in the infrastructure. For example, use L0phtCrack against a Windows server to see if users are using strong passwords. Remember, if you can use this type of tool to crack passwords, so can a hacker who gains access to your network.

Scan for vulnerabilities
A number of other areas should be addressed during this phase of your audit. For one thing, you need to determine exactly what is open to the outside world. Don’t just rely on the firewall—test it.

I used to work for someone who abhorred firewalls. He understood their purpose but also realized that they can make admins complacent about security matters. Rather than tightly lock down a machine, they may instead rely on the firewall to protect it. In reality, both should be implemented, a firewall as well as diligent server security to harden it.

One excellent tool to use for this purpose is the Security Auditor’s Research Assistant (SARA). Based on SATAN, SARA is a capable scanning tool that can scan hosts, ranges of hosts, and entire networks. Certified by SANS, SARA is updated twice a month. With new exploits being found every day, timely and frequent updates are critical.

SARA’s features also include:

  •         Integration with nmap (if installed) that allow for high-grade OS fingerprinting.
  •         Integration with Samba for SMB-type scans.
  •         Plug-ins allowed for third-party applications.
  •         Operation on most UNIX/Linux machines, including Mac OS X.

SARA, shown in Figure A, has a number of ways to detect vulnerabilities ranging from light detection, which will catch only horribly blatant problems, to extreme detection, which has the potential to cause unpatched services to fail.

Figure A
SARA’s scanning options range from light to extreme.

At the end of the scanning process, SARA lets you know what it found via configurable reports. One of the things I like most about SARA is that its informational messages completely describe the error—why it’s bad and how to fix it. You can see an example of this in Listing A.

Another excellent utility is Internet Scanner, which is one of four tools offered by Internet Security Systems (ISS). It performs selective probes of communications services, operating systems, and network devices to determine what types of attacks they may be open to. Internet Scanner looks for hundreds of known exploits, ranging from GetAdmin for Windows NT (which allows a guest user to surreptitiously obtain Administrator credentials) to checking Watchguard firewalls to test whether they are subject to certain denial of service attacks.

Regularly updated, this utility is an excellent choice for an IT department that wants to completely test the reliability of its security infrastructure. When run from outside a firewall, Internet Scanner can give you a complete list of exactly what could potentially be exploited by hackers. A list of sample reports based on its findings can be found here.

Internal security concerns
Finding critical holes using the tools mentioned is an important step in a security assessment. However, there is more to do. In addition to looking for the obvious holes, you need to look for other, less obvious things, especially in terms of your internal network security.

For example: Joe Johnson, the accounting employee who was laid off a few weeks ago—did you remember to remove and/or disable his login? How about Sally Smith? She moved from marketing to operations. Did you remember to change her group memberships? While these are simplistic examples, they are easily verified. User account records should be routinely checked to make sure that they are accurate.

You should also keep careful track of file permissions. It might be a simple task to give every user admin rights to all files on the server (don’t laugh—I’ve seen it, unfortunately), but it’s obviously a terrible idea with potentially disastrous results. I’m extremely stingy when it comes to rights to files and directories. I give people only the absolute minimum that they need to do their jobs. If they need additional access, they can always request it.

You can verify your rights assignments in Windows NT or 2000 using Cacls or Xcacls. Listing B shows some sample output generated when I ran Cacls from the root of my Windows XP workstation.

Using this utility, I can see who has rights to every file and folder on the system. Of course, for large installations, this would be an extremely tedious task, so automating it in some fashion would be recommended.

On UNIX and Linux, you can use the ls –al command to get a directory listing with user and group ownership information, as shown in Listing C.

We’ve taken an introductory look at how to conduct an audit in your organization, and we’ve discussed some of the utilities you can use to help you assess your vulnerabilities. In my next article, I will show you how to fix some of the more common security problems that your audit may turn up.