There are a few people that come visiting once a year: some that we enjoy (Santa Claus and the Easter Bunny), and some that we'd rather avoid (the IRS agent and the network auditor). I can't help you prepare for the IRS, but I can certainly offer you some advice to help prepare for your next network audit.
I've had the opportunity to frequently observe how organizations handle annual audits, and the most successful security teams approach the process as a periodic review of the way business is conducted all year, with the goal of compiling a complete scope and picture of enterprise network processes. Organizations that encounter the most difficulty during audits are those that adopt the "cram for the exam" approach. An audit isn't something that can be crammed for, and those that think so likely miss the point of conducting a security audit in the first place.
I recently attended a conference where Investment Technology Group CISO David Drossman compared audit preparation to the training program followed by professional football teams, in that winning the Super Bowl requires year-round preparation. How can you apply this philosophy to your next network audit? I propose that you follow a life cycle based upon the one illustrated below. It's a compilation of the best practices that I've seen throughout my 10 years of work with IT organizations.
The process involves a series of iterative steps:
- Develop a well-documented snapshot of your network and how each device should perform. Repeat this process for each network element that you wish to manage. The number and types of network devices you monitor will depend upon your particular organization's infrastructure and the amount of time you have to dedicate to change monitoring. This snapshot will serve as a network "baseline" that you can use to measure changes against in the future. As an example, assume you are attempting to build a baseline of network firewall configurations. You can build this baseline by compiling the total picture of ports exposed by a data center's servers, as this information accurately reflects the performance of the firewall. Generally speaking, there's no need to go through the laborious process of building such a baseline very often; the frequency of repetition will depend upon how often the environment changes and the degree of compliance with the monitoring/remediation cycle.
- Next, begin a continuous process that will monitor the network for changes. Continuing with the firewall example, you could use a daily Nmap scan to monitor for previously undetected firewall rules. A little Perl scripting and a simple database can automate this task, alerting you only when the environment changes. Alternatively, you may turn to advanced change management tools to detect and/or track changes to your environment. The degree of integration you achieve is limited only by your budget. For example, you might use an integrity monitoring tool and combine it with your organization's change management product. Such an arrangement will automatically reconcile identified configuration changes with change management records.
- Remediate when you detect a change. Each time a network change is discovered, there are
two possible reactions. If the change was expected, as reflected in your change management system,
simply update your baseline and move along. If the change was unplanned and represents a potential
risk to the network, begin investigating, documenting and remediating the problem.
These two options comprise the monitor/remediate cycle. Each time you encounter a change, you can either add it to your baseline or remediate, often by restoring the system to the pre-change state. By following this cycle, you'll stay abreast of network changes and maintain accurate network documentation. Essentially, your network will always be in audit-ready condition. If you use this cycle methodically, it will dramatically reduce the frequency at which you must rebuild your baselines. In an ideal environment where all changes are tracked and reconciled, you may only need to build a baseline when bringing a new system/device online. If changes slip by without proper tracking or remediation, you'll eventually need to rebuild your baseline to bring things back under control.
- Prepare for the audit with an assessment. It's always a good idea to plan an internal assessment about 2-3 months prior to the actual audit. A practice test evaluates your lifecycle process and ensures that the controls you've put in place are functioning properly. Think of the assessment as a dress rehearsal for the audit.
Following a lifecycle approach to network auditing can't guarantee a perfect audit. (After all, auditors wouldn't exist if they couldn't find anything!) It will, however, ensure that you're as prepared as possible for your audit "Super Bowl."
About the author:
Mike Chapple, CISA, CISSP, is an IT security professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Prep Guide and Information Security Illuminated. He also answers your questions on network security.
This was first published in February 2009