Security Monitoring and Attack Detection Planning Guide

On This Page

	Introduction
	Solution Elements
	Detect Policy Violations
	Identify External Attacks
	Implement Forensic Analysis
	Summary

Introduction

The final step in the creation of a plan for a security monitoring and attack detection system is to create the solution design that addresses the solution requirements. This solution design must target the issues for the three defined scenarios:

Because the main goal of the solution is to identify and profile attacks, the bulk of this chapter discusses the events that can indicate that an attack is in progress. These attack profiles connect to the security issues for each scenario that Chapter 3, "Issues and Requirements," covers. The precise implementation of this solution will vary, based on your organization's network topology.

Top of page

Solution Elements

The solution design uses the same basic components for all three scenarios. The forensic analysis implementation requires additional resources for online, offline, and archive storage, but otherwise its solution architecture does not differ greatly from the implementation for the other two scenarios.

Solution Concept

The solution concept for security monitoring and attack detection requires you to examine and plan the appropriate levels of security audits for the following areas:

The security monitoring and attack detection system collects information from the security event logs and collates this information centrally. The administrator can analyze this data for suspicious activities. Alternatively, the information can be stored and archived for later forensic analysis.

A major component of this solution is the ability to configure per-user auditing, which is a feature of Microsoft® Windows Server™ 2003 with Service Pack 1 (SP1) and Microsoft Windows® XP with Service Pack 2 (SP2). Per-user audits allow you to specify different audit levels for specific user accounts, with higher audit levels for suspicious individuals or sensitive accounts.

Solution Prerequisites

The solution prerequisites for the configuration of a security monitoring and attack detection system are:

Note:  Because computers in a perimeter network may be members of a workgroup rather than a domain, you cannot configure these computers with Active Directory Group Policy settings. However, you can use local policies and template files to configure these computers.

This guide does not recommend any particular technology for central collation of security events but concentrates instead on the identification of the characteristic signatures of an attack. After you decide on a suitable collection mechanism, you can use the events and event sequences that this chapter describes to create queries that identify attacks.

Solution Planning

Before you implement a security monitoring and attack detection system, you should:

For more information about storage requirements, see the "Implementing Forensic Analysis" section later in this chapter.

Review Current Security Audit Settings

Organizations should review their current security audit and security event log file settings to provide a baseline for the changes recommended in this chapter. This review should obtain:

You can use Appendix B, "Implement Group Policy Settings," as a job aid to identify which settings you need to record. For more information about security audit settings, see the Windows Server 2003 Security Guide at http://www.microsoft.com/downloads/details.aspx?FamilyId=8A2643C1-0685-4D89-B655-521EA6C7B4DB.

Assess Administrator Roles and User Tasks

A key element to the implementation of effective security monitoring is to ensure that you know who your administrators are and what roles and responsibilities they hold. For example, most organizations include administrators in the Domain Admins group. Domain administrators can create new user accounts in the domain. However, organizational policies can specify that only the provisioning system can create new accounts. In this situation, if an administrator creates a user account, this action should attract immediate attention.

Assessment of user tasks is simpler, because users have significantly less access to network resources than administrators do. For example, because users do not usually have access to the file systems of computers in the perimeter network, it is unlikely that you need to monitor these servers for user activity.

Review Organizational Policies and Procedures

Reviews of organizational procedures correspond with the assessment of administrator roles and responsibilities. For example, the process of adding users to groups requires careful review. Departments should establish procedures for change requests and define methods for implementation of these requests. Adding a user to a group outside of the approved process requires investigation.

Identify Vulnerable Computers

Vulnerable computers are those that an external attacker is most likely to attempt to access first in an organization's network. For most attack scenarios, these computers are part of the perimeter network.

You should perform a comprehensive review of all vulnerable computers to ensure that you have:

Note:  This review process is not exclusive to vulnerable computers. Good security practice recommends that you apply these checks to all computers on the network.

For more information about how to run services securely, see The Service and Service Accounts Security Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41311.

List High-Value Assets

Although an organization is likely to have already identified its high-value assets, it might need to formalize this as part of an organizational policy by documenting these assets and the protection for each asset. For example, a company might use access control lists (ACLs) and encryption to store financial records securely on NTFS file system partitions. However, organizational policy should identify these records as protected files that unauthorized users or administrators should not attempt to access, and Administrators and users should be aware of this restriction.

The organization should then investigate any changes to the ACL on these protected files. Changes in ownership are particularly important, because ownership changes can indicate that an attacker attempted to access a file without proper authorization. Because ownership changes do not happen very often, they should be easy to detect.

Identify Sensitive or Suspicious Accounts

You should review all sensitive accounts to identify those accounts that require higher audit levels. These accounts include the default Administrator account, any members of the Enterprise, Schema, and Domain Admins groups, and any accounts that services use to log on.

When you notice suspicious activity by an individual, your security policy requirements should require higher audit levels for that person. For more information about how to change audit levels for user accounts, see the "Enable Selective Auditing" section later in this chapter.

List Authorized Programs

Because attackers must run programs to discover information about the network, restrictions on which programs can run on your network significantly reduces the threat of external attacks. You should perform an audit of all authorized programs, and consider any unknown programs as suspicious. Microsoft Systems Management Server 2003 can carry out software audits for large enterprise environments.

Note:  You might need to make exceptions for certain computers, such as developer workstations, because the executable files that the developer creates are not on the approved list. A more secure approach is to require developers to use virtual computers that have no connectivity to the corporate network to develop and test programs.

Solution Architecture

The security monitoring and attack detection solution contains several components that coordinate to provide security warnings. These components include:

Active Directory domain controllers are not a strict requirement, because you can configure security audit levels using local security settings. However, the solution requires Active Directory if you want to use Group Policy to help implement security audits.

How the Solution Works

The solution architecture components work in the following way:

Implementation of security monitoring for forensic analysis requires the following additional actions:

Enable Selective Auditing

New features in Windows Server 2003 with Service Pack 1 enable selective audit levels on user accounts. For example, you can audit logon and logoff activity for everyone and audit all activity for one specific user. Alternatively, you can audit all activity for everyone except one specific user account. Selective audit levels enable you to reduce the number of routine events that you must filter out or to track suspicious individuals. You can selectively audit user accounts only, not security or distribution groups.

You can use the auditusr.exe command-line utility to implement selective audit levels. Both Windows Server 2003 with SP1 and Windows XP with SP2 have this utility. For more information about how to configure per-user audits, run auditusr.exe /? at a command prompt.

Note:  Per-user audits cannot exclude events for members of the built-in Administrators group.

Top of page

Detect Policy Violations

Chapter 3, "Issues and Requirements," identifies that the greatest threats to a network are from internal users within an organization. Even institutions with the most rigorous recruitment and selection procedures cannot afford to neglect to monitor their most trusted internal users. This chapter includes the majority of internal threat scenarios, along with a discussion on how to detect these occurrences.

Unintentional system or network configuration errors usually result from administrator actions. For example, consider an administrator who followed an approval process before implementation of a configuration change, and then used the correct administrator credentials to log on at a workstation that was visible to other users. In this example, the administrator did not attempt to hide his actions. Factors such as whether an administrator attempts to conceal his activity usually distinguish deliberate sabotage from accidental configuration errors.

Note:  Implementation of security monitoring is much more effective if you have already created and implemented a suitable change management process. Without the change management process in place, it is much more difficult to check that changes were made using the correct procedures, as there is nothing against which to check.

Attack profiling for policy violations relies on identification of an event or sequence of events that can indicate a potential attack. You can use this information with your event correlation system to look for attack signatures.

Detecting policy violations covers the following activities:

Access Resources by Changing File Permissions

Administrators can view files to which they have no read permissions by changing ownership of the file and then adding themselves to the read permissions list for the file. In Windows Server 2003 and later, they can disguise this action if they change ownership and permissions back to their original states.

It is counterproductive to configure object access auditing on all files—any illicit activity would be lost in the sheer volume of events. However, security audit levels should be set to check all access or changes to high-value files and the folders that contain them. ACL entries alone are not a suitable defense against unauthorized access.

To thwart illegal activity effectively, you should identify the following factors for all high-value files:

Because Event Viewer does not provide sufficient filter settings to identify this information, you must use EventComb MT or other third-party utilities to perform this analysis.

The following table lists the audit events that changes to file permissions can cause. The audit category is Object Access.

Table 4.1: File Permission Change Events

Access Resources by Password Resets

Password resets should occur within an approved framework only. Properly configured security audit levels should record password resets in the security event logs and identify those resets that do not follow the correct procedures.

The following table lists the audit events that resets to passwords cause. The audit category is Account Management.

Table 4.2: Password Reset Events

Create, Change, or Delete User Accounts

You should always follow an established process to create a new user account. In large organizations with automated provisioning systems, this process can involve multistep business logic processes that require managers to log on to a Web site to approve account creations for new hires. Even in small organizations, creation of a user account in Active Directory should result only from an official request. Every event that records creation of a user account should then correspond to account creation requests. An unreliable administrator can easily create a plausible user account for a nonexistent employee and then use that account for unauthorized access and malicious activity.

You should also confirm that only a short interval exists between creation of a new user account and when that user logs on and changes her password. If a new user does not log on to the new account within a predetermined timeframe, the provisioning system should disable the account and the security officer should investigate the reason for the delay.

To use security monitoring and attack detection to identify user account issues, you should configure queries that:

The following table lists the events that identify user account changes. All events belong to the Account Management audit category.

Table 4.3: User Account Change Events

Place Users into Groups

Good security practice advocates the principle of least privilege, which translates into giving users the minimum rights and permissions they need to do their jobs. Most user accounts should be members of the Domain Users group only, together with any organization-specific security groups.

Placement of users into security groups, particularly users who have high privileges such as Domain, Schema, or Enterprise Admins, should occur within policy guidelines only, and should make use of established and approved accounts or processes. You should treat any other changes as suspicious and investigate further.

Note:  Distribution group membership does not provide access to network resources, because distribution groups are not security principals. However, membership of certain distribution groups can create other types of security issues. For example, placement of user accounts into the Vice-Presidents or Directors distribution group by mistake could cause users to receive e-mails that are inappropriate to their position.

The following table lists the events that identify group changes. All events belong to the Account Management audit category.

Table 4.4: Group Membership Change Events

Attempt to Use Unauthorized Accounts

Promotion of the first Active Directory domain controller in a forest creates an administrator account that is a member of the Domain Admins and Enterprise Admins groups. This account requires particular protection because it is the only account for which the account lockout settings do not apply. Hence, even with an account lockout policy in place, this account is vulnerable to dictionary attacks.

Security monitoring should identify any attempt to log on this administrator account, even if you have renamed it. For more information about elevation of security on administrative accounts, see The Administrator Accounts Security Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41315.

Attempts to log on with disabled or expired accounts can indicate that a former employee, temporary worker, or contractor has tried to gain access to the network without current authorization. These events require immediate investigation.

The following table lists the events that identify unauthorized account usage. The events belong to the Account Logon and Logon audit categories.

Table 4.5: Unauthorized Logon Events

Log on Interactively with Service Account Credentials

When a service starts, that service must present logon credentials. In some cases, service accounts can require a domain account to connect and run services on remote computers. Some service accounts must run with administrator credentials or interact with the desktop.

In Windows Server 2003 and later you can start some service accounts (such as the Alerter service) with the –LocalService switch. Services that need network connectivity can use the Network Service account, NT AUTHORITY\NetworkService. You should check all services that require user accounts to make sure these accounts use strong passwords. Security monitoring should confirm that logon events for those accounts occur only when the relevant service starts. For more information about elevation of security on service accounts, see The Service and Service Accounts Security Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41311.

The primary security concern develops when a service account logs on interactively instead of as a service. This event can occur only when an intruder has discovered the password to the service account and logs on with that account. If that service account has administrator privileges, the intruder has substantial power to disrupt usual network services.

You should identify all resources that a service account can access. For example, a service account might occasionally have a good reason to require write permissions on a log file directory, but this is generally not the case. Service accounts should not have unexplained permissions to access high value data. You should closely scrutinize service accounts that can interact with the desktop because these accounts provide greater opportunities for attackers.

The following table lists the events that identify unauthorized use of service account credentials. The events belong to the Account Logon and Logon audit categories.

Table 4.6: Logon with Service Account Credentials Events

Run Unauthorized Programs

Because administrators are trusted personnel, they can install and run programs. Organizations should create both a list of approved (and licensed) programs and a process for approval of new programs. In addition to tests on new programs in isolated network segments, administrators should not run any programs that the approved list does not include.

Security audits on process tracking can identify unauthorized programs. However, process tracking generates multiple security log entries, so you must ensure that the number of events do not overwhelm the detection mechanism.

The following table lists the events that identify the use of unauthorized programs. The events belong to the Process Tracking audit category.

Table 4.7: Run Unauthorized Programs Events

Access Unauthorized Resources

This case requires the identification of audit failures on Event ID 560. The following table lists the events that result from access to unauthorized resources. The audit category is Object Access.

Table 4.8: Access Attempts to Unauthorized Resources Events

Damage Authorized Files

In this case, a user deliberately damages files to which they have access because they do not care about the consequences. This type of behavior is most common in cases where an organization has fired a user, but the administrator has not yet disabled that user's account.

To reduce the opportunities for such deliberate sabotage requires well-documented and effective de-provisioning strategies that immediately disable the user's account and forcibly log off the user.

Introduce Unauthorized Operating Systems

Administrators and users can introduce unauthorized operating systems into a network through the following mechanisms:

Unauthorized operating systems can cause significant problems, such as:

Organizational policies can specify whether users who work from remote locations can connect to the corporate network through remote access services or virtual private networking. For more information about how to ensure that remote computers comply with organizational security policies before they connect to the network, see Implementing Quarantine Services with Microsoft Virtual Private Network Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41307.

Note:  Some distributions of open source software are available on startup CDs. To start one of these operating systems, the user can insert the CD and restart the computer. Event log monitoring might not be able to detect this occurrence, because the open source software runs separately from Windows. However, log on attempts from user "root" in a homogenous environment could indicate the presence of unauthorized operating systems. Removal of CD drives from client computers can address this issue but is not always practicable.

Users can also obtain a Windows XP installation CD and restart their computers to reinstall Windows XP. In this case, event log monitoring of other computers might detect attempted logon attempts from user "Administrator" that have an unidentified workgroup name or the default name of "Workgroup."

Virtual PC images provide a complete emulation of the computer environment on a host computer. This emulation runs its own operating system with its own computer name, accounts, workgroup or domain memberships, and programs. The virtual PC image can start, run, and close down without affecting the host computer. The virtual PC can also request an IP address and access corporate network resources. Virtual PC images are a threat because they are unlikely to be secure, often with blank or easily guessable passwords. A user who runs an unsecured Virtual PC image can map drives to network shares or install components, such as Microsoft Internet Information Services (IIS), that possess inherent vulnerabilities that later service packs or security updates addressed.

You should configure security monitoring to detect:

The following table lists the events that identify the use of unauthorized operating systems. The events belong to the Process Tracking audit category.

Table 4.9: Run Unauthorized Platform Events

Note:  To ensure more reliable detection of rootkits, evaluate third-party products such as RootkitRevealer from Sysinternals or Blacklight from F-Secure. For more information about RootkitRevealer, see RootKitRevealer, at http://www.sysinternals.com/utilities/rootkitrevealer.html. For more information about Blacklight, see the Revolutionary F-Secure BlackLight Technology press release at http://www.f-secure.com/news/items/news_2005030701.shtml.

Obtain Other Users' Credentials

One unintended consequence of good password policy (such as the requirement for a certain password length and enforcement of regular password changes) is that users write down their passwords. This situation is particularly noticeable in heterogeneous environments that have multiple identity stores that require users to log on several times.

Note: For information about password management in heterogeneous environments, see the Identity and Access Management Series at http://www.microsoft.com/technet/security/guidance/identitymanagement/idmanage/default.mspx

Organizations must guard against users who write down their passwords and leave them out in plain sight, because an unauthorized person can then enter an office and easily find the user's logon credentials. Security monitoring should detect when a user logs on to a computer that the user does not typically use. Detection of this type of attack requires cross-correlation of logon successes with workstation names, and user access or authorization to those workstations.

Note: Active Directory enables you to control the workstations onto which a user can log on. This feature requires support for network basic input/output system (NetBIOS) naming, for example through the Windows Internet Naming Service (WINS).

Events for these occurrences are identical to those that Table 4.5, "Unauthorized Logon Events," lists.

Attempt to Circumvent Auditing

An attacker can use a variety of methods to elude discovery. For example, an attacker can change the security policy of a computer or domain so that the event logs do not record suspicious activities, or they can deliberately clear the security logs so that audit data is lost. Detection of attempts to cover tracks can be a challenge, because many of these events regularly occur as part of typical network operations.

The following table lists the events that identify events likely caused by attackers who are trying to hide evidence of security breaches. The events belong to multiple audit categories.

Table 4.10: Circumvent Auditing Events

Create or Break Trust Relationships

Trust relationships enable user accounts in one domain to access the network resources of another domain. Automatic two-way transitive trust relationships span all domains within the same Active Directory forest. You might need to manually create trust relationships in other situations, such as:

Creation of trust relationships is not a routine operation that only an enterprise administrator should perform through a clearly defined, approved, and established process. Similarly, an enterprise administrator should only break trust relationships after a careful analysis of the effect on the network and by reference to a clearly defined, approved, and established process.

The following table lists the events that identify trust relationship actions. The events belong to the Policy Changes audit category.

Table 4.11: Changing Trust Relationships Events

Make Unauthorized Changes to Security Policy

Changes to approved security configurations should occur only within the framework of an agreed process and set of procedures. You should view any changes to security configurations outside of this framework either as an inadvertent administrator error or as intentional sabotage.

Security configuration settings that should not change outside a defined framework include:

This list represents minimum requirements, and most organizations will probably add more Group Policy settings. You need to configure security audits to identify both successful and unsuccessful attempts to change these settings, and all successful attempts must correlate to a user account that has the appropriate authorizations.

The following table lists the events that identify policy changes (either Group Policy or local system policy). The events belong to the Policy Changes audit category.

Table 4.12: Policy Change Events

For more information about Group Policy settings, see the Security Policy Settings topic at http://www.microsoft.com/resources/Documentation/windowsserv/2003/all/techref/en-us/W2K3TR_sepol_set.asp.

Top of page

Identify External Attacks

External attacks result from the actions of a person, or from the effects of malicious programs. These attacks can overlap; for example, a Trojan can gain access to a desktop computer that a person can then directly exploit.

External attackers often attempt to breach security by privilege elevation until they gain administrative access to one or more computers. This approach generally starts with a successful intrusion through a user account that has limited privileges. The attacker then attempts to escalate privileges by creation of a process or service that runs in the System context. The attacker then uploads and executes software to explore the network further (for example, tools that intercept passwords or scan network packets).

An attacker can also attempt to install a rootkit on a server. Rootkits are software components that take complete control of a computer and conceal their existence from standard diagnostic tools. Because rootkits operate at a very low hardware level, they can intercept and modify system calls. You cannot find a rootkit by searching for its executable, because the rootkit removes itself from the list of returned search results. Port scans do not reveal that the ports the rootkit uses are open, because the rootkit prevents the scanner from detecting the open port. Hence, a major difficulty when dealing with rootkits is to ensure that none exist.

Trojan applications are usually less difficult to detect than rootkits, although they can be more destructive. Trojans can provide similar remote control functionality as rootkits or can simply destroy data like a virus would. The main distinguishing feature of a Trojan is that, like its classical namesake, it attempts to trick the user to run it because it appears to be useful.

Most malicious programs are not as flexible or reactive as a human-driven attack. However, you should pay particular attention to possible virus delivery mechanisms, such as e-mail, that circumvent the perimeter network. Strict e-mail attachment filters can help reduce this kind of attack.

External attacks include the following categories:

Attempt to Compromise Credentials

Attackers use several approaches to obtain user account credentials. The most well-known approach subjects a single user account to a dictionary attack. In this case, the attacker only knows one user account name. Another approach applies the same set of passwords to every user account contained in the directory service database. In this second case, the attacker probably has access to the organization's directory service. To detect this second attack, you need to be able to monitor account lockouts and multiple logon failures for a series of accounts, even if the total number of logon attempts is below the account lockout threshold.

Password changes or resets are another way to gain a user's logon information. Because password change or reset operations generate the same event for both success and failure, an attacker can avoid detection by circumvention of the account lockout policy. A security monitoring solution must identify multiple password change or reset attempts, particularly those that occur outside the organizational framework for password change or reset.

Password cycling is not an attack, but occurs when a user-initiated script that cycles through a number of password changes and allows the user to return to a previously used password. The number of password change attempts equals the password reuse threshold. This scenario appears as a rapid series of 627 events in which the Primary Account Name equals the Target Account Name. Implementation of a password minimum age causes these password change attempts to fail.

The following table lists the events that result from attacks that target user credentials. However, these events can also occur as part of typical network operations, or when legitimate users forget their passwords.

Table 4.13: Attack Authentication Credentials Events

Exploit Vulnerabilities

Because vulnerabilities can exist on any computer, attackers attempt to exploit these vulnerabilities to penetrate an organization's network. The best protection against attackers who try to exploit vulnerabilities is to define an effective patch management process that uses Microsoft Systems Management Server 2003 or Windows Server Update Services.

For more information about patch management, see Patch Management Using Systems Management Server 2003 at http://www.microsoft.com/downloads/details.aspx?FamilyID=e9eab1bd-13e7-4e25-85c5-ce2d191c3d63 and Windows Server Update Services at http://technet.microsoft.com/en-us/wsus/default.aspx

Security monitoring on the perimeter network is particularly important, because these computers are most readily available to an attacker. Unless a mechanism exists to detect that an attack is under way, an organization might not be aware that anything is amiss until an attacker compromises its network. Security monitoring on computers in the perimeter network must be able to detect a range of events.

Typical occurrences for exploits of vulnerabilities include unauthorized access attempts and privileged identity usage. The following table covers some of the events that can identify possible attacks on computers.

Note:  See Table 4.13, "Attack Authentication Credentials Events," for additional events that might identify these kinds of attacks.

Table 4.14: Identifying Events from Exploiting Vulnerabilities by Escalating Privileges

Note:  Versions of Windows earlier than Windows Server 2003 will list event 576 in the Privilege Use category. In Windows Server 2003 and later, the Logon category also lists this event. Hence configuration of audit settings for either category causes this event to appear.

Install a Rootkit or Trojan

Detection of the installation of a rootkit through security monitoring is difficult but not impossible. An unknown program that starts and stops in quick succession can indicate a rootkit. Once a rootkit starts, the operating system can no longer detect it. Hence the program appears to exit and does not generate any more events.

Trojans are generally easier to identify than rootkits because they do not possess the stealth characteristics of a rootkit. Keystroke loggers (programs that attempt to record keystrokes) also reside in this category.

The following table lists the events that can result from installation of a rootkit.

Table 4.15: Rootkit or Trojan Events

Trick a User into Running a Malicious Program

In this approach, the attacker attempts to circumvent the firewall and perimeter network to deliver an executable attachment to a user. E-mail is the most common delivery mechanism, but other connections, such as to an infected Web site, can achieve the same result.

The attacker's first challenge is to get the user to run the program. If the user executes the program, program initiates in the user's security context. The program can then attempt to escalate privileges, for example to gain administrator equivalence or to obtain network access.

You can configure process tracking to detect program startup attempts. If software restriction policies are in place to restrict the programs that a user can run, unauthorized program startup attempts create an audit failure event that you should investigate. You should be especially concerned if the following events occur:

Table 4.15, "Rootkit or Trojan Events," lists the events that might occur when an attacker tricks a user to start a malicious application.

Access an Unauthorized Computer

Administrators increasingly use remote management facilities such as Terminal Services to connect to particular computers. You should therefore monitor these computers for interactive logon attempts and check the connection attempt for validity. Checks include:

This type of monitoring is particularly important for high value assets, such as financial or customer records. You should place these resources onto a separate server and enable strict policies to govern who accesses these resources.

Security monitoring should indicate who attempts to connect to these computers, and you should cross-reference this information to the list of allowed users. The following table lists the events that result from use of an unauthorized computer.

Table 4.16: Unauthorized Computer Usage Events

Top of page

Implement Forensic Analysis

Chapter 3, "Issues and Requirements," identifies how forensic analysis is fundamentally different from detection of policy violations and identification of external attackers. Forensic analysis uses many of the elements that this guide has already covered but focuses on the analysis and long-term storage of the resultant data. Most forensic investigations then proceed as types “list all events for user A” or “list all events from computer B.”

Security monitoring for forensic analysis requires you to:

Three main factors determine the storage requirement:

Note: A domain controller with all audit categories enabled except for object access can produce in the region of 3,000 security events per hour. Storage of this information as a .CSV file from Event Comb MT results in a 1-MB file. Use of object access audits and process tracking can significantly increase these figures.

The result of your analysis can tally up to unrealistic storage requirements. If this is the case, you must make a tradeoff among the number of monitored computers, the events that you monitor, and the duration that these events are stored online before relocation to offline storage.

Appendix A, "Exclude Unnecessary Events," of this guide lists events that do not provide useful information. This appendix is intended to help you exclude events do not add any useful security information.

Top of page

Summary

An effective security monitoring and attack detection system is an essential component in the maintenance of network integrity. To plan a monitoring and attack detection solution based on Windows security audits requires a comprehensive knowledge of the system's goals. It also requires a knowledgeable appreciation of the threat risks to which your network is susceptible and the attack signatures connected to each threat type.

Windows Server 2003 provides the basic components for a security monitoring and attack detection system that uses security logging. Microsoft provides server-based components such as Microsoft Operations Manager and utilities such as Event Comb MT that can correlate event logs from multiple computers and provide analysis of security events. Microsoft Partners provide additional tools and utilities that enable rapid identification of attack profiles.

Top of page

5 of 8