A solid Windows security audit strategy is one that collects just enough information to satisfy audit needs and no more. Collecting too much information slows down your computers and wastes disk space. It also makes the auditing task harder with excessive information to review. You want to continually refine the audit information collection process to add collectors for information you need and remove collectors for information that is irrelevant.

Here is a list of Windows security audit best practices that will help you design, develop, and maintain an audit process that is efficient and effective. Modify these guidelines to suit your organization but pay attention to the suggestions—they can help you avoid wasting time and resources.

• Create initial baselines that represent a “secure” starting point for each computer. Develop security templates in SCA that contain the security settings for each type of workstation and server. Change the templates as needed and use them when building new computers. You can apply up-to-date templates to new Windows installations to quickly configure a new computer to your security standards.

• Run SCA/MBSA using command-line interface options to compare computer settings and configurations with your standards. Schedule scans to run periodically, such as weekly or monthly, and review the resulting output files for any identified problems.

• Develop batch files to run scans and collect ongoing operational information. Collect information using a set daily, weekly, or monthly schedule and archive collected data files.

• Maintain current backups of all audit information, so you can recover historical audit information in the case of a disaster.

• Enable Windows auditing only for sensitive or critical resources.

• Do not enable Read or List auditing on any object unless you really need the information. Read/List access auditing can create a tremendous amount of auditing information.

• Do not enable Execute auditing on binary files except for administrative utilities that could be used in an attack.

• Limit enabling all auditing actions to files, folders, programs, and other resources that are important to your business functions. Don’t be afraid to enable auditing for any object—just ensure you need the information you’ll be saving.

• Enable auditing for all change actions for your Windows install folder and any folders you use in normal business operation. It is also a good idea to audit changes to the Program Files folder.

• Audit all printer actions. You may need to be able to know who printed a document that found its way into the wrong hands.

• Ignore Read and Write actions for temporary folders but do audit Change Permissions, Write Attributes, and Write Extended Attributes actions. These actions can help identify attacker activities.

• Develop Windows policies and Group Policy Objects that are as simple as possible and still satisfy your security policy. Complex policies are difficult to verify.

• Develop clear guidelines to evaluate each element of your security policy. An audit should be a structured process to verify your security policy, not an unorganized hunt for problems. Know what you will be looking for before you search through lots of audit data.

These best practices guidelines are only a starting point, but they give you guidance on how to develop an auditing strategy that will work for your organization.