15.2 Auditing

     

You've configured your environment to meet the documented security requirements by following the security procedures and plans. These plans were created by technology-specific experts with a thorough review by security administrators and upper management. This should ensure that the initial configuration is secure.

However, you must keep continually vigilant against attacks. The plans you followed almost certainly call for ongoing monitoring of the components that you've installed and configured. This monitoring can be done in a variety of ways. Some applications create log files on the local hard disk. Others send SNMP messages on the network. Many of the newer applications and services, including those included with Windows Server 2003, create entries in the Event Log that can be viewed with Event Viewer.

This centralized location for storing and reviewing audit events provides a great benefit to the security administrator. Event Viewer is a simple tool that can be used to examine these audit events, as well as other system messages, in a single interface. Because other programs know about the Event Log database, these messages can be gathered from disparate systems and combined into one large log file. This log file can then be parsed, either by a security administrator or an automated program, such as Microsoft Operations Manager or Sunbelt Software's Event Archiver Enterprise, to identify security- related events and analyze these events to determine if any unauthorized behavior is taking place.

15.2.1 How Auditing Works

Auditing is specifically designed into most features in Windows Server 2003. When events that might be of interest to administrators or computer owners take place, an audit entry is created in the Event Log.

Audit events can be broken down into two general types of events: success and failure. Each event's audit code is specifically written to detect either success or failure. The resulting condition, along with the event that occurred, the system date and time when it occurred, and potentially helpful supplemental information, are entered into the Event Log as an audit event.

Each application or service may have its own configuration for auditing. Frequently, applications allow several levels of audit event logging. These levels might range from auditing only the most important events to auditing virtually every operation that occurs and creating entries for both the success and failure of each. As you might guess, this can quickly spiral out of control and fill up the logs with useless information. Therefore, discretion should be exercised to ensure you audit the events that will help you detect security issues without auditing so much that the entries become a nuisance.

Overriding the auditing settings is the global auditing configuration. This is similar to an on/off switch for auditing of broad audit categories on the computer. In most configurations, you will turn auditing on for all computers in a domain or OU and then configure specific auditing for services and applications on a per-computer or per-OU basis. This strategy allows you to audit only the necessary events on the computers you're most concerned about and helps you identify and address security issues more effectively.

15.2.2 Configuring Auditing

To correctly configure auditing, you must know what to audit first. Just as with the deployment of all other technologies in this book, you should create a plan for auditing within your organization. This plan should be included in the overall plan for deployment of the technology in question. The considerations when creating an audit plan include:

Are both the success and failure of this event useful in determining what happened ?

For example, you may not be interested in auditing successful login events from client computers. This is a normal event that happens thousands of times a day and could quickly clog your event database with useless information. However, logon failure might be far more interesting, especially when it occurs at a domain controller or when a single account shows repeated logon failures.

What is the expected frequency of the event?

You should consider the frequency of the event to ensure you plan for Event Log analysis correctly. If important events happen often, they will require more time to analyze than will occasional events. If you use automated Event Log analysis tools, you will need to know how many of these events to expect in order to set triggers that will fire when that number of events is exceeded. You must also configure Event Log size behavior based on the number of expected events ”the more audit entries, the larger the log must be.

What should happen when the Event Log is full?

Microsoft Windows Server 2003 allows you to tailor the behavior of the Event Logs to meet your specific needs. If audit events are critical to capture and your policy states that all defined events must be audited , you can configure the server to require those events to be saved and for the server to crash when audits can no longer be saved. Other configurations may not require such rigid Audit Log requirements.

Once the audit policy is written and reviewed, it can be implemented easily. Auditing is one of the simplest technologies to implement in Windows Server 2003. I provide several example scenarios to show the most common audit requirements implemented. I'll provide the details on how to get to the specific Group Policy section that applies to auditing in the first example. Thereafter, I'll simply show the different options you'd select in that same area of the Group Policy Object Editor.

The simplicity of enabling auditing is both a benefit and a detriment. If you have a clear plan and know what you're doing, the task is simple to implement and verify. However, this also makes it easy to misconfigure. Many administrators simply switch on auditing for every event they can with no clear plan or goal. Their Audit Logs quickly fill up and become a useless nuisance. This is the reason planning is stressed repeatedly. Without a plan, auditing can cause far more harm than good.

15.2.2.1 Configuring auditing for domain controllers

Domain controllers are often the first computers to be attacked when an attacker reaches your internal network. They are also the point at which you can catch casual and unsophisticated internal attackers . Because a domain controller must authenticate domain user account logon activity, it's a great place to monitor for unsuccessful logon attempts. As an added bonus, configuring account logon activity for domain controllers will show us all local logon attempts at those domain controllers. We almost certainly have an administrative policy that restricts the local logon events at these computers, and capturing an Audit Log will allow us to verify compliance with the policy.

Follow these steps to configure logon auditing on domain controllers in the default Domain Controllers OU:

1. Click Start All Programs Administrative Tools Active Directory Users and Computers. This can be done on a domain controller or a computer with the Windows Server 2003 Administration Pack installed.

2. Expand your domain, right-click on the Domain Controllers OU, then click Properties.

3. Click the Group Policy tab, then click Edit to edit the Default Domain Controllers Policy. This starts the Group Policy Object Editor.

   

   If you have a different policy or more than one policy, you can use any of those. Alternately, you can create a new policy by clicking New. Deciding whether to create one large policy or several small policies is discussed in detail in Chapter 5.

   
   

4. Double-click Default Domain Controller Policy (or whatever policy name you are editing), double-click Computer Configuration Windows Settings Security Settings Local Policies Audit Policy. The default domain controller audit policy settings will be listed as shown in Figure 15-1.

5. Double-click Audit Account Logon Events to display the details of the policy. Select both Success and Failure as shown in Figure 15-2.

Figure 15-1. Default Domain Controller Audit Policy

Figure 15-2. Policy settings for auditing account logon events

The domain controllers will now create an audit event for each logon attempt, both successful and unsuccessful. This can prove useful by showing what accounts logged in and where they logged in. For example, if a trusted administrator is on sick leave and you detect a large number of logon failure audits, you can be fairly certain that an attack is being conducted against that account. You can then either take preventive action to stop the account or gather evidence and contact the authorities to prosecute the attacker.

In a domain environment, this configuration will show all logon attempts using domain credentials. However, if you're using the same policy settings to monitor an important computer that is not a domain controller, an attacker could attempt to log in using local credentials. In that case, you must audit both the account logon events (generated when a domain user account is authenticated on a domain controller) and logon events (generated when a user logs onto a computer) to ensure you capture both types of logon attempts.

15.2.2.2 Configuring the Event Log and audit failure behavior

Auditing should be part of your written security policy by now. The different behaviors that must be audited are documented. In addition, the amount of audit data that must be retained should also be documented. Most corporations don't require audit histories to be retained indefinitely; this creates both legal and administrative difficulties. Most corporate data retention policies extend to cover audit and security event data, so this policy should be consulted when configuring auditing.

Auditing may also be required, to the extent that if audit data cannot be captured, data access should not be allowed. This should also be an extension of written security policy. The policy should take into account possible denial-of-service attacks that can leverage such a policy (for example, generating numerous Event Log entries until a computer will no longer allow access).

These settings can easily be applied by Group Policy. To configure the computer to shut down when it can no longer generate security log events:

1. Follow steps 1-4 of the preceding procedure.

2. Under Local Policies at the same level as Audit Policy is the Security Options container. Click this container to show its settings.

3. Double-click the policy object "Audit: shut down system immediately if unable to log security audits."

4. Click Define This Policy Setting, then click Enabled as shown in Figure 15-3.

Figure 15-3. Policy settings for system shutdown when the security Event Log is full

When a computer with this policy applied is unable to generate any kind of security event, including an audit event, it will crash. Your other monitoring software should detect this crash and alert you to the issue so you can correct the situation. To avoid the situation in advance or correct the existing situation, you should modify the settings of the Event Log. These settings should reflect your specific environment and policy to ensure that the events are rolled up into the proper database and then cleared.

To configure the Event Log settings to retain 32MB of security logs (a nice big size that shouldn't burden your system) and never delete security log entries automatically:

1. Follow steps 1-4 of the first procedure in this section to open Group Policy Object Editor to the Local Policies node.

2. Under Security Settings at the same level as Local Policies is the Event Log container. Click this container to display the Event Log settings as shown in Figure 15-4.

3. Double-click Retention Method for Security Log.

4. Click Define This Policy Setting, then select "Do not overwrite events (clear log manually)" as shown in Figure 15-5.

5. Double-click Maximum Security Log Size.

6. Click Define This Policy Setting, then set the size as 32768KB.

Figure 15-4. Event Log settings

Figure 15-5. Configuring the security policy log to never overwrite events; this setting can be potentially disastrous if you don't plan it properly

You have now configured Windows Server 2003 to retain a maximum of 32MB of security log entries and to never overwrite events. The Event Log must be manually cleared (after being saved or transferred per your policy) before the security Event Log reaches this maximum size. If the security Event Log does reach this size and "Audit: shut down system immediately if unable to log security audits" is enabled, the computer will crash, and an administrator will have to manually restart it.

15.2.2.3 Auditing account management

Now that I've shown how to configure auditing settings, the configuration of additional audit settings is almost entirely the same. You may, for example, want to audit account management functions such as user account creation or group membership modification. Again, this will tie in with your established security policies and provide the ability to review activity to ensure no improper actions have been taken.

To configure account management auditing, simply follow the steps listed in the earlier "Configuring auditing for domain controllers" section. However, you should configure the Audit Account Management policy setting for success and failure actions. This will provide details on all account management activities with a single Audit Policy modification.

15.2.2.4 Setting up a honey pot

Attackers will find their way onto your network eventually. Whether it's a disgruntled employee searching for blackmail material on her boss or an industrial espionage attack that penetrates your firewall, nothing is impervious. A common administrative tactic is to entice the attacker to find what you want her to find and attack that particular resource. It's akin to setting mousetraps around the perimeter of your house and then putting a particularly yummy piece of gouda in the middle of your living room. But that gouda isn't for the mouse's benefit; it's rigged with video cameras and mouse-seeking missiles.

In computer security, we call this piece of tasty cheese a honey pot . Honey pots are computers placed at locations where an attacker is likely to find her way, such as just inside a DMZ. We give these computers tempting names such as DataCentral or HRServer and install unpatched operating systems with services known to contain well-documented exploits such as IIS. When an attacker sees this kind of server, she is drawn to it like a bee to honey. Hence the name.

What attackers don't realize is that administrators have placed triggers and surveillance devices all over the honey pot. From the moment an attacker attempts to access the honey pot, Audit Logs are being generated and monitoring software is alerting administrators that some activity is taking place. Steps can then be taken to trace the network traffic back to its origin and begin compiling evidence of the break-in. This evidence can be used both to enhance future security by determining the point of entry and to prosecute the attacker.

To set up a honey pot, you first configure a computer as mentioned earlier. I would recommend you install Windows 2000 Server and do not apply any service packs or hot fixes. This lures the attacker into believing that this is simply a neglected server on your network. Common configuration errors, such as an administrator account with a weak or blank password, should be used.

Next, configure auditing as shown earlier in this section. The auditing should capture all logon success and failure activity, as well as account management activity (in case the attacker plants or elevates credentials).

Shares should be created on the computer. These shares should have tempting names such as HRDocs or Unfiled Patents and contain concocted datafiles that may have very little data but will serve as bait. Although these names sound a bit too tempting within this context, try to consider it from an attacker's viewpoint. If an attacker saw a share with this name, would she immediately double-click it? The shares should be set for Everyone: Read permission. The files on the share should have filenames consistent with the share name and should be in application-specific format such as Microsoft Word or Microsoft Excel files.

Finally, file auditing should be set on the directory that contains the files acting as bait. To configure file auditing for the HRDocs directory and its contents:

1. Configure Audit Object Access to audit Success and Failure audits as shown earlier in this chapter.

2. In Windows Explorer, right-click the HRDocs directory, then click Properties.

3. Click the Security tab, then click Advanced.

4. Click the Auditing tab to show the auditing entries for this directory.

5. Click Add to add an auditing entry to this directory.

6. Type Everyone , then press Enter to audit all users' access to this folder. This is done because we don't know what user context the attacker will use to access the folder.

7. In the Full Control row, click both the Successful and Failed checkboxes as shown in Figure 15-6. This will ensure we capture all types of access attempts to the contents of this folder. Then click OK.

8. Click "Replace auditing entries on all child objects with entries shown here that apply to child objects." This will show the completed file auditing settings shown in Figure 15-7. Click OK to apply these settings.

Figure 15-6. Configuring logging for both success and failure events

Figure 15-7. Replacing audit entries on child objects helps to ensure application of your desired settings to all necessary objects

Now the honey pot is fully configured from the Windows side. You should ensure that your Audit Log monitoring software is obtaining frequent log updates from the honey pot computer and is configured to page the on-duty security administrator as soon as the log entries begin to appear. This will allow your group to quickly respond and identify the attacker as well as capture and retain all pertinent evidence.

Before taking any type of legal action based on this book, you'll obviously consult with a lawyer experienced in this field. The information you gather by using the steps in this book may or may not be considered evidence in court . Also, honey pots do walk a fine line between enticement and entrapment that only lawyers and judges can help clarify.