Lesson 2: Designing a Security Auditing Strategy

Windows 2000 and IIS allow you to track the activities of users and services in order to detect possible intruders. By logging specific events, you can monitor a broad range of security-related activity. You can then view the logged activity to determine whether certain areas of your servers or sites might be subject to attacks or other security problems. Windows 2000 and IIS provide two primary methods that you use to track activity: the Windows Security log and IIS logging. You can set up Windows 2000 to record security-related events in the Security log. In addition, you can set up a Web site in IIS to log information about user activity. In this lesson you’ll learn how to design an auditing strategy that uses the Security log and IIS to track activities that can affect your site’s security.

After this lesson, you will be able to

• Log Windows 2000 security events in the Security log
• Log IIS activity for specific Web sites

Estimated lesson time: 25 minutes

System Auditing

Auditing refers to the process of maintaining a secure list of events on your system. For example, auditing can provide you with information about who logged into the site, when users logged in, and what files they accessed. Auditing is an essential component in any secure system. In Windows 2000 and IIS, the two primary methods that you can use to audit your system are logging Windows 2000 security events (using the Security log) and logging site activity (using IIS logging).

Logging Windows 2000 Security Events

Windows 2000 allows you to set up your system so that security-related events are recorded in the Security log. An event is any significant occurrence in the system or in an application that requires an entry to be added to a log. The Security log can record security events such as valid and invalid logon attempts as well as events related to resource use, such as creating, opening, or deleting files. You can specify which events are recorded in the Security log. For example, you can set up your system to log successful logon attempts. When you do, Windows 2000 records all successful logon attempts in the Security log.

Figure 11.7 provides an overview of the process that occurs when a user logs on to the system and that system is configured to audit account logons.

Once events have been recorded, you can use Event Viewer to view the contents of the Security log. Event Viewer allows you to search, filter, sort, and view details about events. You can use the log to help track changes to the security system and identify any possible breaches to security. You can also archive logs in case you need to access event information at a later date.

Figure 11.7 - Account Logon event added to the Security log

When you view the Security log in Event Viewer, you’ll see two types of log entries (assuming both types of events occurred): Success Audit and Failure Audit. A Success Audit event is an audited security access attempt that succeeded. A Failure Audit event is an audited security access attempt that failed. For example, if you configure your Group Policy settings to audit failed logon events, a Failure Audit event will be added to the Security log whenever someone attempts to log on to the system and that attempt fails.

Generating a Security log can take a large amount of disk space, so you should be careful when selecting the events to be audited. Consider the amount of disk space that you’re willing to devote to the Security log. You can configure Event Viewer to overwrite log entries that are more than a specified number of days old. You can also configure the server to stop running when the Security log is full.

Setting Up Auditing

To enable auditing, you must configure your Group Policy settings in the Group Policy snap-in, as shown in Figure 11.8. For each policy, you can configure successful attempts, failed attempts, or both.

If you want to audit access to files and directories, you must first configure the Audit Object Access policy in the Group Policy snap-in. From there, you must set up auditing by configuring the properties (access control settings) of the specific directory, as shown in Figure 11.9.

You can access the auditing properties by clicking the Advanced button in the Security tab of the Properties dialog box.

Figure 11.8 - Using the Group Policy snap-in to configure audit policies

Figure 11.9 - Configuring auditing in a directory’s properties

Once you’ve set up auditing, you can review the Security log for suspicious security events in order to determine whether there have been attempts at unauthorized access to your system. You should inspect the Security log for the following types of activity:

• Invalid logon attempts
• Failed use of privileges
• Failed attempts to access and modify .bat or .cmd files
• Attempts to alter security privileges or the Security log
• Attempts to shut down the server

Logging Site Activity

In addition to configuring auditing in Windows 2000, you can configure IIS to track access to your server. IIS logging is easy to implement and can be used in conjunction with a log file analysis tool, such as WebTrends. IIS logging can help you collect data about the following types of suspicious activity:

• Multiple failed commands to the Scripts directory or another directory configured for executable files
• Attempts to upload files to the Scripts directory or another directory configured for executable files
• Attempts to access executable files (such as .bat, .exe, or .cmd files) and subvert their purpose
• Attempts to send .bat or .cmd commands to the Scripts directory or another directory configured for executable files
• Excessive requests from a single IP address attempting to overload the system or cause a denial-of-service attack

A denial-of-service attack is an attack that causes system resources to be consumed so that no resources are available for other users. A denial-of-service attack can also cause a system to crash.

IIS logging allows you to record log entries about user and server activity on a Web or FTP site. You can use the logs to regulate access to content, determine content popularity, plan security requirements, and troubleshoot potential site problems.

IIS logging is more extensive than the Windows 2000 logging that you can view through Event Viewer. IIS uses modules that operate independently of other activities on the server, and you can choose the log format for each individual Web site or FTP site. In addition, you can choose not to log individual directories that are part of a site that’s being logged. For example, you can enable logging for the default Web site, but you can disable logging on the IISHelp directory.

IIS logging supports four log file formats, as described in Table 11.3.

The W3C Extended format, Microsoft IIS format, and NCSA format are all American Standard Code for Information Interchange (ASCII) text formats. You can use a text editor to view these types of log files. For the ODBC Logging format, you must first create a table in the database that contains the appropriate fields for the logged data. You can then view the table as you would any other data source.

Table 11.3 Log File Formats

Format	Description
Microsoft IIS	Microsoft IIS is a fixed format that includes basic items such as the user’s IP address, username, request data and time, HTTP status code, and the number of bytes received. The items are separated by commas. Microsoft IIS records more items than the NCSA Common format.
NCSA Common	The NCSA (National Center for Supercomputing Applications) Common format is a fixed format available for Web sites but not FTP sites. It records basic information about user requests such as remote host name, username, date, time, request type, HTTP status code, and the number of bytes received by the server. Items are separated by spaces.
ODBC Logging	The ODBC (open database connectivity) Logging format is a record of a fixed set of data fields in an ODBC-compliant database, such as Microsoft Access or Microsoft SQL Server. Items logged include the user’s IP address, username, request date and time, HTTP status code, bytes received, action carried out, and the target.
W3C Extended	The W3C (World Wide Web Consortium) Extended format is a customizable format with a variety of different fields. You can specify which fields to include in the log. Fields are separated by spaces.

You can configure IIS logging through the properties of each Web site or FTP site. Figure 11.10 shows the Extended Properties tab of the Extended Logging Properties dialog box for the W3C Extended format. You can access this dialog box by clicking the Properties button on the Web Site tab (or FTP Site tab) of the site’s Properties dialog box.

Figure 11.10 - Configuring logging in IIS

Making a Decision

Windows 2000 and IIS support two main methods for auditing your system. You can log Windows 2000 security events (using the Security log) and you can log site activity (using IIS logging). Table 11.4 provides information on the considerations that you should take into account when auditing your system.

Table 11.4 Auditing Your Web Site

Type of Logging	Considerations
Windows 2000 event logging	You can configure Windows 2000 to audit security events. These events are recorded in the Security log, which you can view by using Event Viewer. To set up Windows 2000 auditing, you must configure Group Policy settings. For each policy, you can configure successful attempts, failed attempts, or both. If you want to audit access to files and directories, you must first configure the Audit Object Access policy and then set up auditing for the specific directory or file.
IIS site logging	IIS logging is easier to implement than event logging. In addition, it can be used with log file analysis tools. IIS logging can be implemented for each Web site or FTP site, and you can choose not to log individual directories that are part of a site that’s being logged. In general, IIS logging is more extensive than the Windows 2000 logging.

Recommendations

Auditing is an essential part of any security plan and you should use it, but you must take into consideration the process of managing log files. You should audit only those resources that require auditing in order to conserve resources. For IIS-related auditing, you should use IIS logging. For all other auditing, you should use Windows 2000 events. You should also use Windows 2000 events when IIS logging doesn’t provide you with specific types of information you might need. In general, your auditing strategy should be based on your organization’s needs, your security requirements, and the availability of your resources. However, you shouldn’t limit auditing because of lack of resources. It’s better to supply the resources you need to maintain an efficient auditing program than not perform auditing. You must ensure that your auditing strategy includes regular review and analysis of logged data to determine potential security risks.

Example: Directory Auditing for Fourth Coffee

Fourth Coffee supports a Web site for clients to use to place orders and update customer data. Administrators at Fourth Coffee are concerned that someone might be trying to add executable files to the Scripts directory in order to introduce a virus into the system. The administrators plan to audit the directory for several days and then review the logged data for suspicious activity.

The first step that the administrators take is to configure the Audit Object Access policy in Group Policy. They set the policy to audit successful attempts and failed attempts. From there, they set up auditing on the Script directory by configuring the Create Files/Write Data access type to audit successful and failed events. Once auditing has been set up, they plan to use Event Viewer to view the Security log and review the events that have been recorded. They will review the events on a daily basis over a seven-day period to determine whether there’s any suspicious activity.

Lesson Summary

Auditing refers to the process of maintaining a secure list of events on your system. In Windows 2000 and IIS, the two primary methods that you can use to audit your system are logging Windows 2000 security events (using the Security log) and logging site activity (using IIS logging). Windows 2000 allows you to set up your system so that security-related events are recorded in the Security log. Once events have been recorded, you can use Event Viewer to view the Security log’s contents. When you view the Security log in Event Viewer, you see two types of log entries (assuming both types of events occurred): Success Audit and Failure Audit. To enable auditing, you must configure your Group Policy settings in the Group Policy snap-in. If you want to audit access to files and directories, you must also set up auditing in the specific directory or file. In addition to configuring auditing in Windows 2000, you can configure IIS to track access to your server. IIS logging allows you to record log entries about user and server activity on a Web or FTP site. IIS logging supports four log file formats: Microsoft IIS, NCSA Common, ODBC Logging, and W3C Extended. You can configure IIS logging through the properties of each Web site or FTP site.