An audit is an evaluation of a collection of one or more objects. The objects can be people, things, processes, or organizations. An audit can be an evaluation of pretty much anything. The purpose of an audit is to determine if the objects of the audit meet some criteria. An audit is more than just collecting information about things. You must compare the collected information with some standards or guidelines and then determine if your collected information is similar to, or different from, the standard information. In most cases, an audit doesn’t focus only on a point in time. Most audits consider information gathered over a specific period. In this way, audits can reveal patterns of performance when compared with standards.

A security audit in a Windows computer environment is a collection of configuration and performance information compared with information contained in your security policy. The purpose of a Windows security audit is to measure how well the audited computer operation complies with your security policy. This process may seem similar to profiling a Windows computer. Although there are similarities, and profiling is often a part of a security audit, the two processes differ. Profiling is the process of comparing computer security settings with a baseline. Windows security auditing is a larger process of comparing computer security settings and performance with your security policy, typically over a period of time. As a general rule, the scope of an audit is larger than just profiling a collection of computers.

A Windows security audit involves several activities. These activities are related and may occur multiple times throughout an audit. Each audit may take different paths but the basic process (FIGURE 7-20) includes:

• Verifying that security controls comply with the security policy

• Collecting configuration and performance information

• Creating initial and subsequent baselines

• Recognizing and analyzing configuration or performance information changes

Collecting initial and subsequent baseline information involves more than just saving analysis reports. You will likely include various audit log files to track access to sensitive resources. Most log file entries of interest will likely be data access for sensitive data and to execute events for administrative programs that can cause damage if used improperly. Log files can provide a wealth of performance information. They can help isolate problems and identify behaviors that both support and violate security policy.

Carefully consider what items you want to audit. Auditing too many events for too many objects can cause your computers to run more slowly and consume more disk space to store the audit log file entries. Consider logging only access failures for most objects you choose to audit. You can audit both access successes and failures for resources that are critical to your organization, but don’t track audit information for all resources.

The key to conducting an effective audit is to establish a consistent process. Define the information you’ll need for the analysis phase and then ensure that you are collecting and storing the necessary information. Planning audit activities improves the likelihood that you’ll capture all the information you need. Auditing should not be viewed as activities that attempt to uncover problems. It should be a continuous process of improving the security standing of your computing environment.