Exam 70-124: Objective 6.1, 6.1.1, 6.2: Auditing Best Practices

You should now be familiar with how to configure auditing, how to look for specific events that an occur, and how to open and look at the Security Log to see the recorded events and their IDs. Let's now take a look at some field tips for better auditing.

The first thing that you should have is an auditing section in your security policy. It should be mandatory that auditing be used on critical systems such as production Web servers and/or any other system on which you absolutely cannot afford a breach of security. More important, you should have a system of checks and balances in place, including administrators being audited as well. Another good idea is to make sure that you do not allow entries to be removed from the Security Log. In Figure 10.17, you can see that we have cleared the Security Log and it was audited as a system event. This is a nice setup because if you audit successful system events, you can catch someone trying to clean out the logs. When the cracker tries to clear this event, it just keeps reproducing the system event that the log was cleared and flags it with an event ID of 517.

Figure 10.17: Viewing Event ID 517 in the Security Log

A cracker can also take advantage of your system by deleing the actual log file instead of just clearing it. The way you get around this problem is that you never store the actual log files on the same physical server. Instead, have a share on the network on another system that only grants access to you. Store all the *.evt logs on that system. This increases security in case the system you are auditing is compromised at any time.

Exam Warning  

Make sure that you are comfortable with Event Log storage. It is not only important for the exam—it's even more so in real-world production scenarios.

Another practice you should get in the habit of is setting up a regular review of these logs. There are tools that can do this for you, such as Microsoft Operations Manager (MOM), but if you don't want to invest the dollars in a product such as that, you must keep yourself on a constant audit schedule. You can only nail an attacker if you perform follow-up work on your initial configurations. Your server will not call you (yet) to tell you it "thinks" it might be under attack. Until this happens, it's up to you, the security analyst, to review and analyze your logs on a constant basis. It is recommended that you do this at least once a week. Here is a list of some other good auditing best practices you can follow:

• You need to know that you can apply more than a single policy to any one computer. Because you have this ability, you could see conflicts within your security policy.

• Make sure that you realize that you have an order or precedence you need to follow. The highest is the OU, then the domain, and then the local computer.

• At the domain level, you can only have one account policy, and it is the default domain policy.

Note 

By default, all users in a domain can access System and Application Logs. The Security Log is restricted to administrators. Make sure that you keep physical access to the system secure. Lock your systems in the rack, lock the doors to the server farm, lock the consoles with a password—anything you can do to keep the system safe. Lastly, make sure that Terminal Server client access is not abused on the systems, or you can simply audit your system to monitor for it.

Security Analysis

Another best-practice tip is to do a quick self-audit on your system using the tools location within the system. A good tip is to have the system analyze itself. Use Security Templates to create a local policy, and then use Security Configuration and Analysis to apply the policy. In Figure 10.18, we opened a new MMC (go the Run dialog box and type MMC /a and then choose Add snap-ins) and added the Security Configuration and Analysis snap-in as well as the Security Templates snap-in. We then started a new database and have the system scanning itself.

Figure 10.18: Analyzing System Security

Figure 10.19 shows a full report of possible problems in our system. Go through the systems analysis and see what you can turn up.

Figure 10.19: Using the Security Configuration and Analysis Tool

Remember, these are just tips for you to follow to make you a better auditor and to get the most out of your analysis. Now let's look at configuring the Event Viewer Logs for maximum efficiency.

Event Viewer Log Size

By default, the Event Viewer has three logs:

• Application

• Security

• System

These logs have a default size of 512K and will overwrite events as needed within seven days. Make sure that when you're auditing, you set the log file higher (to about 2048KB) and make sure that you are the only person who clears the log, as illustrated in Figure 10.20. This is a good practice because it ties in with our other best-practice tip, which is to visit the system frequently to audit and analyze the logs. Save the logs each week as a way to clear them out. To do this, you only need to right-click the log itself and save it to a safe location. Name the log something that you can refer back to by using a solid log-naming convention such as date /log type with the *.evt extension. Here is an example:

Figure 10.20: Adjusting the Security Log Properties

102402SEC.evt 

This filename indicates that we saved the Security Log on October 24, 2002 (10/24/02).

Test Day Tip 

You need to know all about log settings for the exam. Make sure that you are comfortable with setting up, saving, and using logs.