Security Monitoring and Attack Detection

On This Page

The Midsize Business Challenge
Appendix A: Excluding Unnecessary Events
Appendix B: Implementing Group Policy Settings


Welcome to this document from the Midsize Business Security Guidance collection. Microsoft hopes that the following information will help you create a more secure and productive computing environment.

Executive Summary

The number of high profile cases of malicious software threats and incidents that have dominated media reporting for years has served to raise awareness and spur most businesses to invest time and resources into defending against this prevalent security issue. However, the greatest threat to business infrastructure may not be in the form of an attack from the outside, such as from a virus, but may well reside within the internal network itself.

Attacks launched from inside a business network have a very high potential for damage, especially if performed by personnel who hold trusted positions and who have access to all the network resources within a company. When the risks posed by both external and internal threats are carefully examined, many businesses decide to research systems that can monitor networks and detect attacks wherever they may originate.

Security monitoring practices are not open to consideration for businesses that are governed by regulatory restrictions—they are a requirement. These same regulations may even control how long and in what way security monitoring records must be kept and archived. The ever-changing regulatory environment and continually increasing demands placed on regulated businesses to secure their networks, track the identification of people who access resources, and protect private information places greater demands on businesses around the world to institute effective security monitoring solutions.

There are several reasons why security monitoring and attack detection should also be an important issue to midsize businesses that do not need to comply with any regulatory requirements. These reasons include the consequences any business could face if an attack on that business’s infrastructure were to succeed. Not only could business operations be disrupted, resulting in productivity losses and even monetary loss. A business could even suffer from a loss of reputation, which often takes longer to recover from than any other loss incurred due to an attack.

The security log facilities available in Microsoft® Windows® can be the starting point for a security monitoring solution. However, security logs alone do not provide enough information to plan responses to incidents. These security logs can be combined with other technologies that collect and query that information to form the central part of a comprehensive security monitoring and attack detection solution.

The primary goal of a security monitoring and attack detection system is to help identify suspicious events on a network that may indicate malicious activity or procedural errors. This paper will describe how to develop a plan to help address the need for such a system on Windows–based networks. It will also provide instructions about how to implement, manage, and validate such a system.


This paper consists of four main sections that focus on essential concepts and issues required to design and implement an effective security monitoring and attack detection solution. The first section is the "Introduction," which you are currently reading. The remaining sections are:


This section provides information that is useful for understanding the processes involved with the generation and application of the solution presented in this paper.

The Midsize Business Challenge

This section describes many of the common challenges faced by midsize businesses in relation to a security monitoring and attack detection system.


This section provides detailed information about how to develop, implement, manage, and validate the solution presented in this paper, and is further divided into two subsections. "Developing the Solution" discusses prerequisite activities and creates planning steps. "Deploying and Managing the Solution" provides information that will assist efforts to deploy, manage, and validate a security monitoring and attack detection system.

Who Should Read This Paper

This paper addresses privacy and security concerns for midsize businesses, especially those that require identity protection and controls over data access because of regulatory constraints. Accordingly, the intended audience for this paper ranges from technical managers and decision makers to IT professionals and technology implementers who are responsible for the planning, deployment, operation, or especially the security of a company’s network.

Although portions of this paper should be useful to most technical decision makers, readers should have familiarity with the security and risk issues in their own network environment and have an understanding of Windows event logging services concepts to apply all of the subject matter presented within.


This paper uses the Microsoft Operations Framework (MOF) Process Model in addition to the MOF Security Administration and Incident Management service management functions (SMFs).

In particular, the solution presented in this paper recommends use of a continual process approach instead of a linear deployment approach to security monitoring and attack detection. Specifically, this solution should involve the steps shown in the following figure:

Figure 1. Applying MOF

Figure 1. Applying MOF

A security monitoring solution is actually a continual process of planning, implementing, managing, and testing, because that is the very nature of security monitoring. Because the threats to business networks are always changing, the system that monitors the security in a business network must also change.

Application of this process to security monitoring fits with the Security Management SMF, which seeks to accomplish the following:

  • Assess business exposure and identify which assets to secure.

  • Identify ways to reduce risk to acceptable levels.

  • Design a plan to mitigate security risks.

  • Monitor the efficiency of security mechanisms.

  • Re-evaluate effectiveness and security requirements regularly.

To read more about MOF, refer to the Microsoft Operations Framework Web site at More information about the Security Management SMF is available at

Risk management is the process of determining an organization’s level of acceptable risk, assessing current risks, finding ways to reach that acceptable risk level, and managing risk. Although this paper deals with some risk management concepts and some steps that will assist with risk assessment, an in-depth discussion of risk management is a subject in its own right and deserves its own dedicated focus. For more information about risk analysis and assessments, see the Security Risk Management Guide at

The Midsize Business Challenge

Midsize businesses contend with numerous challenges when attempting to construct an effective security monitoring system and institute policies that support that effort. These challenges include:

  • Understanding the need and the benefits of securing the entire network environment from internal and external threats.

  • Designing an effective security monitoring and attack detection system that includes methods that detect and prevent efforts to work around established policies.

  • Implementing comprehensive and effective monitoring polices that not only detect attacks but also provide an overall picture of an environment’s security level for remediation efforts.

  • Maintaining policies and processes that efficiently correlate security reports with established policies to ease administrative efforts in detecting suspicious activities.

  • Implementing and enforcing efficient business practices and policies that support security monitoring efforts while balancing business needs.

  • Determining acceptable risk thresholds to balance usability and risk mitigation.


As discussed earlier, a comprehensive security monitoring process not only assists with the need to perform forensic analysis but can also be a proactive security measure capable of supplying information prior to, during, and after an attack. By providing a centralized repository for security reports, an attack can be detected during the probing phase, as the attack occurs, or immediately following the attack to supply responders with the information they need to react to an attack effectively, which can reduce the impact of intrusion attempts.

Understanding the range of benefits that can be gained by implementing security monitoring is important during the conceptualization phase of development so that the design and policies can take advantage of all these benefits. Some of the advantages that security monitoring provides include:

  • Identification and remediation of systems that do not comply with security or update policies to reduce the vulnerability profile of a midsize business.

  • Produce information that can alert staff to intrusion attempts before an actual attack occurs by identifying unusual activity.

  • Create security audit information and protect it to improve forensic analysis, which not only meets regulatory requirements but also reduces the impact of any attack that might occur.

  • Assist with security level analysis efforts to improve overall security.

  • Detect activities that occur outside of established business processes, whether intentional or accidental.

  • Assist with the identification of unmanaged systems on a network or the remediation of vulnerable devices.

Developing the Solution

Security is an important issue for many businesses. Although most companies put a reasonable degree of resources into physical security by using methods ranging from the common door lock to those as elaborate as card-based access controls, many still do not sufficiently address the security of the data that they have become increasingly reliant upon.

When data security and monitoring issues do get attention, companies commonly focus data security efforts at the perimeter with firewalls. However, reliance on this approach leaves other sources of attack quite vulnerable. According to the 2004 E-Crime Watch Survey, published by the United States Secret Service and the CERT Coordination Center at, 29 percent of identified attackers were actually from internal sources, including current employees, contractors, and prior employees. When this information is considered, it becomes apparent that a multilayered security approach should be made to safeguard against internal threats in addition to threats that originate from the outside.

One method that is used to address both internal and external threats from a reactive security stance is to implement a security audit logging process. All versions of Microsoft Windows, from Microsoft Windows NT® 3.1 to present versions, use a built in security event log file to record security events. However, although this built-in functionality alone can be useful when performing a forensics investigation in response to an intrusion that has already occurred, it would be difficult to use this functionality by itself in a proactive manner to identify precursory attack activity or alert the proper personnel to intrusion attempts while they occur.

As mentioned, security logs are often used reactively during a forensic analysis of a security incident after it has occurred. However, in the 2005 Insider Threat Study, published by the US Secret Service and CERT at, an analysis of key findings found that security logging and monitoring can be used for proactive detection rather than solely for reactive forensics. Also, most attackers, internal and external, will attempt to cover their tracks by altering logs; therefore, steps should be taken to protect system logs. It turns out that security logs and other methods used to monitor and detect attacks can be a vital tool in the network security arsenal if used and secured correctly.

Although system security logs are the focus of this document, they only form the core of security monitoring and attack detection methodology. Other issues that should be considered include how to identify and remediate any systems that are not compliant with established security policies or have not implemented currently recommended vulnerability patches. Internal network infrastructure should also be monitored, including switch port security reporting (to prevent unmanaged systems from gaining access to the network) and wireless security monitoring (to prevent unauthorized connections or packet sniffing). Many of these monitoring topics are beyond the scope of this document, but they deserve attention in any well-rounded security monitoring solution.

Implementing Security Monitoring

The following subsections provide information about various implementation considerations with regard to a security monitoring system.

Windows Security Event Logging

All versions of Microsoft Windows, from Microsoft Windows NT version 3.1 and later, are able to record security events using built-in log file functionality. In a Microsoft Windows–based environment, this functionality provides the basis for security monitoring. However, without additional utilities or tools to correlate this information it becomes difficult to use proactively because it is dispersed.


Figure 2. Event Viewer Security log

The Security event log (shown in the preceding figure) uses a custom file format to record security monitoring data. Although it is possible to read portions of these records with a text editor, a suitable program such as Event Viewer is necessary to see all of the information recorded in these logs. The Security event log file (SecEvent.evt) resides in the %systemroot%\System32\config directory. Access to event logs is always governed through the Event Log service, and the Event Log service enforces access controls to each log.  The default permissions on the security log are very strict compared to other logs on the system; only Administrators have access to the security log by default.

There are two types of events that are recorded in the Security event log: success audits and failure audits. Success Audit events indicate an operation that a user, service, or program performed has completed successfully. Failure Audit events detail operations that have not completed successfully. For example, failed user logon attempts would be examples of Failure Audit events and would be recorded in the Security event log if logon audits were enabled.

The Audit Policy Group Policy settings, located under Computer Configuration\Windows Settings\Local Policies, control which events create entries in the security logs. Audit Policy settings can be configured either through the Local Security Settings console or at the site, domain, or organizational unit (OU) level through Group Policy with Active Directory.

Interpreting Audit Events

Audit events are discussed in much greater detail throughout this paper, so a basic understanding of audit event structure and the information contained in audit events is important.

Figure 3. Event Properties Window

Figure 3. Event Properties Window

Events are made up of three basic parts: the event header, the event description and a binary data section.

Event headers consist of the following fields:

Table 1. The Event Header




The date the event occurred


The local time when the event occurred


A classification of the event severity or type. For security audit events these are either of type Success Audit or Failure Audit.


The application that logged the event. This can either be an actual program, like SQL Server, a driver name, or a component of the system, like Security for instance.


The event source’s classification of the event. This is pertinent in security audit logs as it corresponds to an event type that can be configured in Group Policy.

Event ID

This code identifies the specific type of event. In the figure above the Event ID is listed as 680, this Event ID indicates that a set of credentials was passed to the authentication system by a local process, remote process, or user.


The username of the user on whose behalf the event occurred. This name is the client ID if it was caused by a process or the primary ID if impersonation s not taking place. In security events both the primary and impersonation information will be displayed if possible and applicable.


The name of the computer where the event occurred.

The event description field actually contains a variety of information that can vary from event to event. For example, in the Event 680 sample shown in the preceding figure, the Error Code: field specifies 0xC000006A, which means an incorrect password was supplied. Each event type will display event specific information in this field.

Windows Security Event Log events do not use the binary data section of the event record.

Technical Issues

To implement a security monitoring and attack detection system based on Windows security event logging, the following issues must be addressed:

  • Manage high volumes of security events. To cope with the high volume of security events that will be generated careful attention will need to be given to which specific security audit events should be tracked. These considerations are particularly important when dealing with file and object access auditing, both of which can generate very large quantities of data.

  • Store and manage event information in a central repository. Storage of event information can involve terabytes of data depending on the configuration of a monitoring system. This is most important when considering forensic analysis needs and is covered in detail under that section.

  • Identify and respond to attack signatures. In order to identify patterns of activity which can signal an attack a reviewer or configured query must be able to pick out the events associated with such activity imbedded within the information provided. Once a suspicious activity is identified there should be a mechanism in place that prompts a timely and appropriate response.

  • Restrict staff from circumventing security audit controls. Personnel with elevated privileges on a network, especially administrators, should be compartmentalized in order to restrict access to audit information so that only security specialists are responsible for the administration of audit systems.

Solution Planning

The following activities should be completed before implementing a security monitoring and attack detection system:

  • Review current security audit settings.

  • Assess administrator roles and normal user tasks.

  • Review business policies and procedures.

  • Identify vulnerable systems.

  • List high-value assets.

  • Identify sensitive or suspicious accounts.

  • List authorized programs.

For more information regarding storage requirements, see the "Implement Forensic Analysis" section later in this paper.

Review Current Security Audit Settings

Businesses should review their current security auditing and Security log file settings to provide a baseline for changes recommended in this paper. Such a review should be conducted regularly after implementing a solution and will need to obtain the following information:

  • Current effective security audit settings.

  • Level to which these settings apply (local computer, site, domain, or OU).

  • Current log file settings (size limits and behavior when maximum size reached).

  • Additional security audit settings that may apply (for example, audit the use of backup and restore privileges).

Information in "Appendix B: Implementing Group Policy Settings” at the end of this paper can be used to assist with the identification of which settings to record. For more information regarding security audit settings, see the Windows Server 2003 Security Guide at

Assess Administrator Roles and Normal User Tasks

A key element to the implementation of an effective security monitoring solution is to ensure that administrator account holders are known and their roles and responsibilities are understood. For example, most businesses include administrators in the Domain Admins group so they can create new user accounts in the domain. However, business policies may specify that only an installed provisioning system is permitted to create new accounts. In such a situation, an account creation event initiated by an administrator account would prompt an immediate investigation.

An assessment of user account tasks is usually much simpler because such accounts typically have significantly less access to network resources than administrator accounts do. For example, since normal users usually have no need to access the file system on computers residing in the perimeter of a network, there is little need to monitor such servers for normal user activity.

Review Business Policies and Procedures

A review of business processes and procedures corresponds closely to, but is not limited to, an assessment of administrator roles and responsibilities. Important components of such a review would include an examination of the user creation process and the change control process, for example. Examination of the mechanisms that provide an approval process and audit trail for all events that occur on a network is vital to provide a correlation to what would be authorized audit events and what may be an intrusion attempt.

Identify Vulnerable Systems

Vulnerable systems are the computers and devices on a network that an external attacker is most likely to probe and launch access attempts against before they try any other approach. Typically, these computers reside in the perimeter of a network, but internal devices can also be vulnerable to attack and should not be completely ignored.

A comprehensive review of vulnerable systems should ensure the following:

  • All relevant security updates and service packs have been applied.

  • Unnecessary services and user accounts have been disabled.

  • Services are configured to run under Local Service or Network Service accounts when possible.

  • Services that require user account credentials are checked to ensure they require that level of access, especially when such accounts have administrator privileges.

  • High-security policy templates have been applied.

Note   This review process should not be limited to vulnerable computers residing on the perimeter. A good security practice would apply these checks to all computers on a network.

For more information about how to configure services to run securely, see The Services and Service Accounts Planning Guide at

List High Value Assets

Most businesses are likely to have already identified the high-value assets that reside in their networks, but they might not have formalized this information as a part of an organizational policy by documenting and detailing the protections in place for each asset. For example, a company might use access control lists (ACLs) and encryption to store sensitive financial records securely on NTFS file system partitions. However, an organizational policy should identify such records as protected files that unauthorized users and administrators should not attempt to access so that administrators and users are aware of this restriction.

Any changes to an ACL that is used to protect such files should be investigated, especially when ownership changes are involved because these events can indicate illicit attempts to access files without proper authorization. Because ownership changes of this nature should be very rare, they should be easy to detect after high-value assets are identified and documented.

Identify Sensitive or Suspicious Accounts

All sensitive accounts should be reviewed to identify which accounts require a higher auditing level. Such accounts will include the default Administrator account, any members of the Enterprise, Schema, or Domain Admins groups, and any accounts that are used by services.

Aside from sensitive accounts, it is also important to adjust security audit levels for accounts held by individuals who have been identified as risks or who may be suspected of participating in suspicious activity. For more information about how to adjust audit levels for individual user accounts, see the “Policy Violations and Thresholds” section later in this paper.

List Authorized Programs

To discover information about a network, an attacker must run programs on systems that reside within that network. By restricting what programs are permitted to run on a network, a business can significantly reduce the threat of external attack. To establish a list of authorized programs, an audit should be performed on all programs currently authorized or identified as necessary in a network environment. Any unknown programs discovered during such an audit should be considered suspect and investigated immediately. Microsoft Systems Management Server 2003 can assist with software audits but is not required.

Note   Some exceptions may be required for certain computers, such as developer workstations where executables under development may not be on an approved programs list. However, a more secure approach would be to require that development and testing only occur in a virtual computer environment or only in an isolated development network domain.

Detect Policy Violations and Thresholds

Policy violations form the largest category of security issues for which businesses must plan. These types of incidents include:

  • Creation of user accounts outside of the established process.

  • Improper or unauthorized usage of administrator privileges.

  • Use of service accounts for interactive log on.

  • File access attempts by unauthorized user accounts.

  • Deletion of files that user accounts have permission to access.

  • Installation and execution of unapproved software.

Although the most common type of policy violation is unintentional user access attempts, such as browsing to restricted directories, such violations are usually the least significant because access limitations and well-designed rights policies address this issue. Administrative policy violations are the most significant type of event, whether deliberate or accidental, because of the very nature of administrative rights.

Administrative account privileges grant a significant degree of systems access to the individuals who require that type authority to perform their duties. However, this authority does not imply the authorization to use those system rights outside of authorized scope or process. The ability of administrative accounts to enable user account creation, modify user accounts, view restricted data, and modify data access rights requires careful consideration of ways to mitigate the risks associated with such powerful capabilities.

Threat Modeling

As can be seen, some sets of threats can be mitigated with auditing, others may not, and some can be mitigated with auditing yet may not be worth the cost to do so. The main point to understand is that not every vulnerability presents a threat to a network. To make determinations as to which vulnerabilities can or should be mitigated, it may be useful to apply principles of threat modeling.

Threat modeling is an engineering technique that can be used to help identify threats and vulnerabilities to more efficiently create countermeasures in the context of a specific environment. This process generally involves three basic steps:

  • Understanding the attacker’s perspective.

  • Identifying the security profile of the system.

  • Determining and ranking the relevant threats.

More to the point, examining a network environment from an attacker’s perspective involves determining what targets would be most tempting to a person attempting to gain access to a network and what conditions must be met for an attack on such targets to succeed. When vulnerable targets of opportunity have been identified, the environment can be examined to determine how existing safeguards affect the attack conditions. This process reveals relevant threats, which can then be ranked according to the level of risk they present, which remediation activities can deliver the most valuable solution to that threat, and whether mitigation may affect other areas in beneficial or detrimental ways that may affect the value of that remediation.

Accordingly, there are actually a few specific steps to a successful network threat modeling process that are based on these requirements:

  1. Identify Critical Assets. Part of determining where best to spend security resources is to list the assets that are critical to business operations. This process should involve the business process owners as well as the technology owners, because each will have important perspectives concerning which assets would cause harm to the business if compromised.

  2. Identify Possible Attack Points. This identification phase actually involves two different perspectives as well. First, it is necessary to classify the types of boundaries that data on the network can reside within. These boundaries reside within either the critical, sensitive, and public realms based on the damage that could be done if said data was exposed. Second, a technology perspective examines the attack points by way of vectors and what possible points of vulnerability could grant exposure to critical and sensitive assets. This combination of information can help narrow the focus of security efforts to vulnerabilities at the points where critical information can be accessed.

  3. Identify Actual Threats. When critical assets and the possible access points have been revealed, a list of what attackers could do to cause damage can be created. With such a list it is then possible to focus efforts on actual specific threats.

    There are different methods that can be used to identify actual threats. STRIDE is one method that examines threats based on the types of attacks that can be used (Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, and Elevation of Privilege). Other iterative measures exist as well, such as breaking threats down by logical layers (for example, network, host, and application). The approach is up to the organization based on what makes the most sense for a given environment.

  4. Categorize and Rank Threats. This step brings common risk assessment and management principles into play by ranking threats based on the probability of their use and the potential impact those threats could have on a business. The standard formula used is as follows:

    Risk = Probability of Exploitation x Potential Business Impact

    There are actually a number of methods involved in such a process, as well as a number of tools available to help with such risk assessments that are well beyond the scope of this paper. For more information about risk management and these methods please refer to the Security Risk Management Guide at

  5. Remediate and Re-evaluate. The product of the previous steps provides a list of actual threats that are capable of affecting the business, which are ranked in order of the risk the present to that business. This list enables a focused remediation effort that should also be evaluated for the cost-to-benefit ratio they present. After all, there may be several different ways to mitigate specific risks and some may address other vulnerabilities that then make such security efforts even more effective.

Even after a remediation plan is enacted, the threat modeling method is an iterative process that should be performed on a regular basis with constant re-evaluation efforts to ensure that security efforts are as effective and comprehensive as possible.

Background Investigations and Reviews

Most businesses already perform some sort of background check on prospective employees as a condition of employment, but do not perform checks afterwards. Businesses should consider performing background checks at regular intervals during employment, especially for critical positions with access to restricted information.

Computer Use Policy Agreements

Computer or network usage agreements are important not only to inform employees about how they may use company assets but also to inform them about policies to monitor network activity and computer use in addition to the possible consequences of any attempts to violate these policies.

Usage policy statements also act as legal documents when they define these issues in explicit terms and require employee signatures as an indication of agreement. Without proof that an employee was fully aware of internal security monitoring policies and the expectation of acceptable use of company assets, it is increasingly difficult to prosecute abusers in case of any wrongdoing.

It is also important to issue an access and unauthorized usage warning at any access point on a company’s network that informs any person who attempts access that it is a private network and that any unauthorized access is prohibited and will be prosecuted. For example, Windows operating systems have the capability to display a warning statement during an attempted logon event that can be used to inform users that they are about to attempt access to a protected company resource and that unauthorized access is prohibited.

Although it is outside the scope of this document to discuss the legal issues involved with the exact wording and use of such documents, it is important to mention that such documents and policies should exist. Many examples of such usage and access statements may exist on the Internet, but these materials should only be prepared with the support and consultation of qualified legal advisors because there are many unique local and international legal issues that require careful consideration.

Separation of Duties

Just as different functionalities for systems are segmented across a network for security, performance, and availability purposes, it is also important to provide for duplication and separation of duties when developing staffing requirements for an IT security department.

Important roles that involve access or control of sensitive data and systems should be redundant whenever possible and reasonable, not only to protect against issues surrounding the loss of knowledge if a staff member is lost but also to provide a security function in cases of internal sabotage. For example, it would be difficult to recover if only one staff member knew the administrator passwords and that staff member left without providing those passwords.

In addition to role redundancy, it is also important to separate critical roles, especially for security monitoring. The people who manage the network should not also be responsible for reviewing security audit information, and the security staff should not have administrative rights that are equal to the administrators. Sometimes it is also necessary to safeguard departmental information from administrative staff to further apply separation of duties. For example, some businesses have organizational units that have their own systems or administrative accounts to protect sensitive information such as finances or human resources.

Note   Although it may not be possible to prevent administrator account holders from finding workarounds for such separations of duties, it is important to at least establish set guidelines for authorized usage for administrative authority that uses the principle of separation of duty.

Validate Security Monitoring Functionality

Regular testing of a security monitoring solution should be planned carefully before implementing such a program. Although initial testing is important to validate a security monitoring solution, it is important to have a schedule of tests that occur regularly due to the ever-changing security environment.

Testing can include intrusion attempts and testing use of administrative privileges to determine whether the solution is effective at finding such activities. However, it is also important to research the latest changes in security techniques and attack profiles to determine if changes need to be made. The threats to business networks are constantly changing as attackers adjust to security implementations, so the defenses and monitoring techniques should constantly evolve to remain effective.

Establish Processes

To separate authorized events from unauthorized security events it is necessary to create a plan for established mandatory change control and problem management processes. Such a plan can provide a detailed paper trail that can be cross-correlated with security log information. Although issue tracking is commonplace in most companies by way of help desk tickets or other problem tracking processes, change control is often neglected. Change control is a necessary mechanism, and may be used not only to track trends for spotting problematic systems or applications but also as a vital security mechanism.

Change control processes should occur as a proactive procedure, and reactive changes should be limited to use of a problem management process. A change control process should require submittal and approval prior to any change and include the following details:

  • Approver name

  • Implementer name

  • Timeframe of the change

  • Reasons for the change

  • Changes to be made

  • Systems affected by the change

  • Business impact

  • Actual results of the change

Another process that should be established is a user provisioning process via an add/change/delete user procedure that also creates an audit trail to guard against unauthorized account changes. Prior to the establishment of such a process, it is important to perform a security audit of the current user accounts that exist to verify the validity of those accounts and periodically validate that list as it changes.

Use of automatic user provisioning and identity management solutions, such as Microsoft Identity Integration Server (MIIS) 2003, can be helpful as well by automating account changes and the processes behind such activities. When using such solutions it is important to remember that administrator accounts still retain the capability to create new accounts but that they would have no need to do so—because accounts would be created by established processes. Therefore, any events associated with account creation, such as event 624, should only correlate to the MIIS 2003 or other established service account that is used for automatic provisioning.

Although external threats to business networks are constantly aired in the media, experience shows that networks and company data are much more vulnerable to loss or compromise from incorrect configurations or procedural missteps. It is important to protect against all threats external and internal, and many vendors exist to help protect your company from external threats, but no one can sell a business a package that will prevent mistakes made by the people responsible for your network and security. The best way to mitigate such risks is by implementing and enforcing sound processes and procedures regarding changes performed on the network.

Define Security Responses

To limit the damage a security breach can cause, it is important to develop a defined suitable response plan and establish processes for responding to incidents. Incident reports, the formation of a rapid response team, and an emergency response protocol are good examples. The speed and effectiveness of incident responses will enhance an organization's security profile and limit the actual and perceived damage an intrusion attempt may cause.

The formation of an established security response process not only helps limit the damage an actual incident may cause, it also acts as a deterrent by notifying staff and other individuals that an incident will provoke a coordinated and immediate response to any security violations.

Human Resources

According to studies done by CERT and the U.S. Secret Service, many attacks from internal sources could be averted if businesses were more aware of and took actions in response to an employee’s behavioral changes or threats. Probably the most valuable security resources in a business are the employees themselves, because they are aware of when a staff member may become disgruntled or alert the proper personnel to when a visitor may be acting suspiciously. In fact, one of the first actions by an outside security auditing group will be to perform a “walk around” in an attempt to find password information on paper, spot unsecured devices, or to attempt intrusions by connecting directly to the internal network.

A business’s staff can serve as an important layer of protection against internal and external threats. Encouraging open door policies to discuss worrisome behavior from peers and training support personnel to take any reports of unusual computer activity from staff seriously can help mitigate intrusion attempts or malware incidents. Internal training is also important as a method of teaching employees how to spot types of computer behavior that should be reported. Training also serves as a preventative measure with regard to avoiding social engineering attacks.

Correlate Security Policy Violations with Audit Events

Correlating security event information involves the collection of security events from multiple systems and the placement of this data into a secure central location. When security information has been correlated, the appropriate personnel can analyze this central repository to identify violations or external attacks. This repository is not only important for forensic analysis, but also as a tool to detect attacks and address vulnerabilities. Although there are several third-party solutions that exist for this purpose, the following Microsoft products and tools can help address this need by correlating security event logs and other security monitoring information into a central repository.


EventCombMT (multi-threaded) is a component of the Windows Server 2003 Security Guide, which is available at This tool can parse and collect events from the event logs on multiple computers. It runs as a multi-threaded application that enables the user to specify any number of parameters when scanning event logs, such as:

  • Event IDs (individual or multiple)

  • Event ID ranges

  • Event sources

  • Specific event text

  • Event age in minutes, hours, or days


Figure 4. EventCombMT

Certain specific search categories are built in to EventCombMT, such as account lockouts (shown in the preceding figure), which provide search functionality for the following events:

  • 529. Logon failure (bad user name or password)

  • 644. A user account was auto locked

  • 675. Pre-authentication failed on a domain controller (incorrect password)

  • 676. Authentication ticket request failed

  • 681. Logon failure

Another security-related event that does not reside in the Security log file is event 12294, which is from the System log file. It is important to add this event to any search, because it can be used to detect attack attempts against the Administrator account which does not have a lockout threshold and is therefore a vulnerable and tempting target for any would-be attacker.

Note   Event 12294 appears as a Security Accounts Manager (SAM) event in the System log, not in the Security log.

EventCombMT can save events to a Microsoft SQL Server™ database table, which makes it useful for long-term storage and analysis. After it is stored in a SQL Server database, the information from the event logs can be accessed by an array of different programs, such as SQL Query Analyzer, Microsoft Visual Studio® .NET, or a number of third-party utilities.

Log Parser 2.2

Log Parser is a free tool available from Microsoft that can be used to search for data in a log, upload logs to a SQL database or CSV file, and generate reports from event logs, CSV files, or other log formats (including IIS logs, for which it was originally designed).

This command-line scripting tool can be used as a resource to correlate event log information into a central location, parse events that are of interest, and even generate reports. However, the scripting and command-line interface require a level of detail that is beyond the scope of this paper. More information about Log Parser, its uses, and scripting resources is available on the Log Parser 2.2 page at and in the "How Log Parser 2.2 Works" article at


EventQuery.vbs is a tool that was released with Windows XP. It can be used to list events and event properties from one or more event logs. The command-based script host (CScript.exe) must be running to use this script. If the default Windows Script Host has not been set to CScript, you can accomplish this by running the following command:

Cscript //h:cscript //s //nologo

This command-line script utility is very flexible and can accept many different parameters to adjust the filtering and format applied to its output. For more information on this tool's usage and available parameters, refer to the Managing event logs from the Command Line topic in the Windows XP Professional Product Documentation at\_commandline.mspx?mfr=true.

Internet Information Services Logging

The additional logging functionality available with Internet Information Services (IIS) provides the ability to report on the identity of site visitors, what a visitor accessed, and when that visitor accessed it. IIS logs record successful and failed attempts to access sites, virtual folders, and files, and can be configured to selectively audit that information to minimize storage requirements and limit the recording of unnecessary information.

These logs can either be stored in native format as a file, which can then filtered by using one of the parsing and collation tools listed earlier, or directly to a centralized location by using ODBC database logging, which can be used to store the information to a SQL database or any other ODBC-compliant database.

Certain activities and sequences of events should be monitored closely, including the following:

  • Multiple failed commands attempting to run executable files or scripts.

  • Excessive failed logon attempts from a single IP address or range of addresses, which can indicate either a DoS attempt or a privilege escalation attempt.

  • Failed attempts to access or modify .bat or .cmd files.

  • Unauthorized attempts to upload files to a folder that contains executable files.

Beginning with Windows Server 2003, new auditing capabilities are built-in with IIS and can either be used with the new logging capabilities of IIS, integrated directly into the Event Log, or accessed with ASP pages for custom solutions. For more information about these capabilities and how to implement them, refer to the IIS documentation.

Microsoft Internet Security and Acceleration Server

Microsoft Internet Security and Acceleration (ISA) Server is an advanced stateful packet and application layer firewall that also provides additional functionality, including VPN and proxy caching capabilities.

In addition to the active defense utility that ISA Server provides, it can also serve a security monitoring function by using its ability to act as a centralized logging tool that can monitor all activity flowing through the perimeter of a network. The logging capabilities in ISA Server include the ability to capture firewall traffic, Web proxy activity, and SMTP message screening logs. These logs can be filtered, queried, or monitored on a real-time basis by using the built-in real-time log viewer (shown in the following screen shot) or monitoring dashboard.


Figure 5. Microsoft ISA Server 2004 Real-Time Log Viewer

In addition to the built-in logging functionality, ISA Server has an alerting feature that can issue alerts via e-mail and event log entries or even start or stop services. The ability to log suspect activity to event log entries is particularly useful in the scope of this paper. This capability allows for the recording and storage of possible attack information into a centralized location with other audit event log data.

In addition to this logging and alerting functionality, there are also built-in intrusion detection tools that can be enabled in ISA Server. These basic intrusion detection services (IDS) are licensed from Internet Security Systems and include several IP packet filters, DNS application filters, and a POP application filter. These services are capable of detecting many common exploits.

The intrusion detection functionality in ISA Server is capable of logging events and generating alerts when potential attacks are detected. It can also terminate services or suspicious connections. Some of the attack profiles that can be detected include:

  • WinNuke (Windows out-of-band attacks)

  • Land attacks

  • IP half scan attacks

  • UDP bombs

  • Port scans

  • DNS hostname length overflow Attacks

  • DNS zone transfers from privileged or high TCP/IP ports

In any case, whether using ISA Server or some other firewall and IDS solution, it is important to consider the perimeter network (also known as DMZ, demilitarized zone, and screened subnet) when designing a security monitoring and attack detection system.

Microsoft Operations Manager 2005

Microsoft Operations Manager (MOM) monitors multiple servers in an enterprise environment from a central location. The MOM agent collects events from event logs and forwards them to the MOM management server, which then places those events into the MOM database. MOM 2005 and later versions are capable of collecting events from computers that do not run the MOM agents.

MOM uses its management pack rules to identify issues that affect the operational effectiveness of servers. Additional rules can be created to monitor for specific events and, when these events occur, send alert notifications via e-mail, pop-up messages, or directly to pager devices.

Although MOM provides many useful features that can be used for security monitoring and attack detection, it was not designed for this functionality. Future releases of MOM will provide greater security log collection functionality.

Microsoft Systems Management Server 2003

Microsoft Systems Management Server (SMS) 2003 can monitor and manage servers and workstations in a network from a central location. Although it is geared to management tasks, it can also help serve vital security-related functions in a security monitoring solution by managing security updates distribution and reporting or by reporting on any unauthorized software installations.

The SMS inventory functionality can help serve a vital need in a security monitoring solution by serving as a real-time centralized inventory management solution, which is vital to any security audit and monitoring process.

Implement Forensic Analysis

Forensic analysis is a large subject in its own right and this paper cannot explain this topic in entirety. In particular, this paper does not discuss the evidence handling requirements of forensic analysis or describe forensic data other than information supplied by security event logs.

Determining the timing, severity, and results of security breaches and identifying systems affected by attackers can be accomplished with forensic analysis. To be effective, the information gathered for forensic analysis must contain the following information:

  • Time of an attack

  • Duration of an attack

  • Systems affected by an attack

  • Changes made during an attack

Again, because of the myriad number of details involved with understanding the laws that govern evidential procedure, key data types in regard to forensics, the tools required for analysis, evidence collection, evidence preservation, and forensic methodologies, it is impossible to address this subject in detail in this paper. However, there are some excellent resources, such as the First Responders Guide to Computer Forensics from CERT at\_v1.3.pdf, which are available at sites devoted to security studies.

Business Issues

Planning for the use of forensic analysis differs from approaches to other solutions, because it involves the investigation of incidents after they have occurred instead of a real-time analysis of incidents. Therefore, a detailed history of events from multiple systems must be maintained for a longer period of time. Because of this additional need, an effective forensic analysis system should be centralized and have a significant amount of storage capability to store a large number of records in a suitable database structure.

One of the mitigating business decisions regards the length of time that such records should be kept for forensic analysis, and also what type of retention cycle should be used. Such factors can greatly affect storage and equipment requirements for a forensic analysis plan. The following table illustrates the typical retention times that are often found at businesses that have established forensic analysis plans.

Table 2. Storage Limits for Forensic Analysis

Storage factors

Storage limits


Online storage (database)

21 days

Provides for rapid access to event details

Offline storage (backup)

180 days

Reasonable archival limit for most organizations

Regulated environment

7 years

Archival requirement for regulated businesses

Intelligence agencies


Intelligence and defense organizational requirements

Note   Some regulated industry practices (such as those in businesses that handle medical records, for example), use time limit specifications in terms of “do not retain longer than” instead of a set retention time.

One option for consideration is to use online databases to retain the online forensic analysis data and then archive older events into a more compressible format, such as comma-delimited (also known as comma-separated values or CSV) text for offline storage. If necessary, CSV files can be imported back into the online database for analysis if needed.

Ensure that whatever solution is selected serves the business requirements for the rapid investigation of recent events with the added ability to recover older events when necessary. A history of security incidents within a business along with a list of available resources should guide the development of a plan that provides the best combination of data retention times for online and offline storage. If possible, test the event collection system in a reasonably large database with the reports that you wish to run, and verify that the reports run in a reasonable amount of time and deliver actionable information.

Security for forensic analysis data must also be considered, because access to this information should rarely be necessary. If access is needed, it should only be provided to a select few trusted security personnel. Administrator access to this information should be strictly regulated within an established change control process that has additional security oversight. No one else should have the capability to access this information, disrupt its collection, or modify it.

Technical Issues

Planning a security monitoring solution for forensic analysis requires careful provisioning for the secure and reliable collection of, and storage for, a very large number of events. Security monitoring requirements are similar to those detailed in other solution scenarios, but require far greater resources for database storage and highly efficient data management.

Some technical challenges that should be considered include:

  • Reliable and secure storage for online data.

  • Provisioning for large amounts of high performance disk space for online storage.

  • Reliable backup systems to store older events to archival media.

  • Secure archive storage management processes.

  • Tested restoration processes to retrieve information from backup storage.

These challenges should not be specific to security monitoring, because database administrators have similar concerns for other applications such as online transaction processing (OLTP) databases. However, unlike other traditional database applications such as OLTP, a forensic analysis database must cope with a far greater volume of writes rather than reads.


To plan for an effective forensic analysis program, the following requirements must be addressed:

  • Proper configuration of security logging settings.

  • Secure log entry checking processes are established.

  • A secure and centralized collection point and process created for security logs.

  • Reliable storage of security monitoring information.

  • Effective archival plans and schedules developed.

The requirements, capabilities, and regulatory restrictions of a business environment should be factored into any forensic analysis solution because each organization varies in these regards.

Deploying and Managing the Solution

The ability to identify, profile, and respond to an attack is the basic goal of any security monitoring and attack detection solution. Therefore, the bulk of this section will be a detailed discussion of pertinent events that may indicate attacks in progress when found in an event log. With this in mind, a security monitoring and attack detection plan should address the following requirements:

  • Detect internal policy violations

  • Identify attacks from external sources

  • Enable efficient and precise forensic analysis

The solution detailed in this paper uses similar components for each of these three requirements. The implementation of forensic analysis capabilities has additional requirements that will be discussed later.

Security Monitoring and Attack Detection

The solution concept for security monitoring and attack detection requires planning the appropriate levels of security audits for the following areas:

  • Account management

  • Protected file access

  • Security policy changes

  • Trust creation and deletion

  • User rights usage

  • System restarts and time changes

  • Registry modifications

  • Unknown program execution

The security monitoring and attack detection system collects information from the security event logs and collates this information in a central location. Security auditors can then analyze this data for suspicious activity. In addition, this information can also be stored and archived for later forensic analysis should the need arise.

A major component to this solution is the ability to configure a feature of Microsoft Windows 2003 with Service Pack 1 (SP1) and Microsoft Windows XP with Service Pack 2 (SP2) called per-user auditing. Per-user audits allow for a specification of different audit levels for specific user accounts, thereby permitting a higher level of audit detail for sensitive or suspicious accounts.

Solution Prerequisites

Configuring this security monitoring and attack detection solution has the following prerequisites:

  • Servers must run Windows Server 2003 SP1 or later and reside in an Active Directory domain.

  • Client computers must run Windows XP SP2 or later as members of an Active Directory domain.

Note   If the computers in a company’s perimeter do not reside within a domain, they cannot be configured with Active Directory Group Policy settings. However, local policies and templates can be used to configure such systems.

This paper concentrates on identifying the characteristic signatures of attacks and does not make any recommendations for any specific technology to be used for the collation of security events, even though it lists some possible solutions. After a decision is made regarding a suitable collection mechanism, the events and event sequences listed in this paper can be used to design queries and alerts to identify suspicious behavior.

Policy Violations and Thresholds

New features available in Microsoft Windows Server 2003 and Microsoft Windows XP with SP2 allow for selective audit levels on individual user accounts. For example, audit levels can be set to report only logon and logoff activity for all users while auditing all activity for a specific user. Per-user selective audit can also be used to reduce the volume of events in the Security log by allowing certain accounts to be excluded from audit generation for certain activities. Only user accounts can be audited using this functionality; security and distribution groups cannot be so audited. Accounts that belong to the Administrators local group cannot be excluded from audit using the per-user selective audit mechanism.

The command-line utility used to set per-user auditing policy for selective auditing on Windows Server 2003 and Windows XP SP2 is Auditusr.exe. Valid selective auditing categories are:

  • System Event

  • Logon/Logoff

  • Object Access

  • Privilege Use

  • Detailed Tracking

  • Policy Change

  • Account Management

  • Directory Service Access

  • Account Logon

When Aauditusr.exe is run from the command-line without any parameters, it will display the current selective auditing settings, which will be blank at first. There are two ways to populate the selective auditing parameters; input one per-user manually as command-line parameters, or multiple parameters by importing a per-user auditing settings file.

Usage of Audituser.exe is as follows:

Audituser.exe /parameter useraccount:”category”

(or a comma-delimited list of categories).

For example, to enable failure auditing of System Events and Logon/Logoff events on an account named LocalUser, the following command-line entry would be used:

Audituser /if LocalUser:”System Event”,”Logon/Logoff”

The following parameters can be used at the command line:

  • /is – adds or changes an include-success entry

  • /if – adds or changes an include-failure entry

  • /es – adds or changes an exclude-success entry

  • /ef – adds or changes an exclude-failure entry

  • /r – removes all per-user auditing entries for a specific user account

  • /ra – removes all per-user auditing entries for all user accounts

  • /e – exports settings into the specified filename

  • /i – imports settings from a specified filename

A per-user auditing settings file is a plain text file, and uses the format shown in the following figure.

Figure 6. Sample Auditusr.exe import file

Figure 6. Sample Auditusr.exe import file

Note   The import file must start with the line “Auditusr 1.0” as shown to import successfully.

So to import the audit settings file shown in the preceding figure, the following command would be used:

Audituser /i path\audit.txt

You can use this utility to help establish thresholds for audit logging information, which can reduce storage requirements and increase the likelihood that intrusion attempts will be noticed.

Security Policy Violations and Audit Event Correlation

Although this section makes no distinction between policy violations caused by external or internal sources it is important to note that internal policy breaches can be just as devastating to a business as attacks that originate from the outside. As noted previously in this paper, a significant percentage of malicious attacks are carried out by internal sources, and this percentage does not include the accidental damage caused by inappropriate use of elevated privileges outside of established procedural scope.

Because of the risk involved with accidental or intentional abuse of elevated privileges by internal sources, it is important to establish policies and procedures regarding the appropriate use of those privileges and to establish audit trails for cross-correlation. After the institution of a change management process and documentation policy, a correlation can be developed to match audit information with approved and unapproved events, thereby easing the ability to detect unusual behavior within a business. This section will assist with that correlation by describing the different types of events that can be tracked and how they might apply to policies and processes.

Accessing Unauthorized Computers

Administrative and support staff increasingly use remote management facilities, such as Terminal Services, to connect with and manage remote systems. These systems should be monitored for interactive logon attempts and each connection attempt should be checked for validity. Such checks should perform the following actions:

  • Identify service account logons.

  • Record access attempts by unauthorized accounts.

  • Investigate attempts from unusual geographic areas.

  • List attempts from external IP address ranges.

Particular attention should be paid to monitoring high-value assets. Such critical resources should reside on specific servers configured with strict audit monitoring and access control settings.

The following table lists Logon audit events, which should be compared to lists of authorized accounts when seen on high-value asset systems.

Table 3. Unauthorized Computer Usage Events

Event ID




Successful Logon

Check Workstation Name and User Account Name. Ensure Source Network Address resides within a network.


Logon Failure – Unknown User Name or Bad Password

Check for attempts where Target Account Name equals Administrator or the renamed default administrator account. Also check for multiple logon failures that are below the account lockout threshold.


Logon Failure – Time Restrictions

Indicates an attempt to log on outside permitted time range. Check User Account Name and Workstation Name.


Logon Failure – Account Currently Disabled

Check for Target Account Name and Workstation Name. This event can signal attempted intrusions from former users and should provoke an investigation.


Logon Failure – The Specified User Account Has Expired

Check Target Account Name and Workstation Name. This event can signal abuse attempts from contract or temporary employees and should provoke an investigation.


Logon Failure – User Not Allowed to Logon at This Computer

Indicates that a user may be attempting to logon to restricted workstations.


Logon Failure – Logon Type Not Allowed

Check Target Account Name, Workstation Name, and Logon Type. This event indicates a failed attempt to log on interactively with service account credentials when Group Policy settings prevent interactive logons with such accounts.


Logon Failure – The Specified Account’s Password Has Expired

Indicates that a user is attempting to logon with an account that has an expired password. May prompt investigation if repeated without a corresponding password change or support call.


Logon Failure – The NetLogon Component Is Not Active

Check to ensure that the NetLogon service is operational. Otherwise, this event may prompt investigation.


Successful Logon

This event is the network equivalent of Event 528.

Trojans, Rootkits, and Malware

Event ID 592 is particularly useful for detecting occurrences of Trojans, rootkits, and other malware, because it is created whenever a new process starts. Any occurrence of this event should prompt immediate investigation whenever the Image File Name does not correspond with a process listed in an approved programs list.

Although Trojans and keyloggers are relatively easy to identify, rootkits are particularly stealthy. They can be detected by locating unknown programs that start and stop in quick succession. However, when a rootkit is started the operating system has no way to detect it and therefore does not generate any further events.

Other malware attempts can take the form of e-mail attachments or infected Web sites, and may attempt to escalate privileges when the executing account does not have the rights to launch new programs. In such cases, the unauthorized software should create a failure event that should be investigated, especially when the following events occur:

  • Processes spawning as LocalSystem. Processes that run as LocalSystem should be well defined in a list of approved programs, and can include such processes as Services.exe.

  • Processes spawned at unexpected times. If the monitored system does not use any scheduled batch processes, certain activities (such as backups, CGI, or scripts) should be investigated when they occur. In other cases, an investigation should occur when such events occur outside of the regularly scheduled batch times.

Table 4. Event 592

Event ID




Creating a New Process

Check the Image File Name and User Name entries for unapproved process, unexpected launch times, or when unknown programs start and then stop in quick succession.

Access Resources by Changing File Permissions

It is possible to use administrative privileges to access files to which access would normally be denied by changing ownership of the data and then adding the accounts to the read permissions list to that data. It is also possible to disguise such activity in Windows Server 2003 by changing ownership and permissions back to the original settings.

Identification of high-value assets and data is important in this regard, because it would be counterproductive to implement object access auditing for every file on an average midsize business network because of the sheer volume of access events that occur normally each day. Object access auditing should be enabled for sensitive files and folders; ACL entries are insufficient as a suitable defense against unauthorized access attempts.

To detect illicit activity efficiently, the following factors should be easily identifiable for all high-value files:

  • Which object was targeted by an access attempt?

  • Which account was used to request access?

  • Which account authorized access?

  • What type of access was attempted?

  • Was the event a success or failure?

  • Which system was used to launch the attempt?

The built-in event viewer does not have sufficient filter settings to identify this information. Therefore, EventCombMT or some other mechanism must be used to perform this analysis.

The Object Access audit events in the following table deal with attempts of this nature.

Table 5. File Permission Change Events

Event ID




Access Granted to Existing Object

Indicates a successfully granted access request to an object. Check Primary Logon ID, Client User Name, and Primary User Name to detect unauthorized access. Check Accesses field to determine operation type. This event only detects access requests, not whether an actual access occurred.


A Permission Associated with a Handle Used

Indicates the first instance of an access type to an object and that permissions were changed if the Access field includes “WRITE_DAC.” Correlate with event 560 by comparing Handle ID fields.

Access Resources by Resetting Passwords

Password changes should only occur within an approved framework of established procedures. Properly configured audit levels should record the Account Management events shown in the following table and correlate those events against recorded procedures to identify activity that does not follow that procedure.

Table 6. Password Reset Events

Event ID




Change Password Attempt

Indicates a password change request in which the requester supplied the original password. Compare Primary Account Name to Target Account Name to determine if the requesting account is the changed account.


User Account Password Set or Reset

Indicates a password reset from an administrative interface rather than a password change process. The requester should be an authorized account, such as a help desk account or self-service password reset account.


Change Directory Services Restore Mode Password

Indicates an attempt to change the Directory Services Restore Mode password on a domain controller. Check Workstation IP and Account name. This event warrants an immediate investigation.

User Account Modification

Any account modification, whether adding, deleting, or changing an account, should correspond to an established process that involves a multiple-step business logic process initiated by an official request from a management level employee. All of the events in the following table should correspond to an official account modification request or prompt an immediate investigation.

Table 7. User Account Change Events

Event ID




Creating a User Account

Indicates a network account creation occurrence.


Deleting a User Account

Indicates a network account deletion occurrence.


Changing a User Account

Indicates security related user account changes not covered by events 627-630.


Changing a User Account Name

Indicates a user account name change.

To effectively identify Account Management issues, queries should be configured to accomplish the following:

  • Find irregular or unusual account activities.

  • Identify administrator level accounts that abuse privileges to create or modify accounts.

  • Detect patterns of account activities that occur outside of organizational security policy.

It is also important to confirm the interval between account creation and initial logon and password change. If a new account is not used within a predetermined timeframe, (usually an account creation process will record the expected start date of a new user), the account should be disabled and an investigation initiated to determine the reason for delay.

Group Membership Changes

A good security practice involves the principle of least privilege, which means granting accounts the minimum level of access required to perform their functions adequately. When this practice is applied, most accounts will be members of the default Domain Users group with additional membership to business-specific security groups.

Security group membership changes should only occur within established policy guidelines, especially when accounts with elevated privileges are involved. Such group membership changes should only be performed by established accounts used for account management, and such events should correlate to an established process for said changes. Any changes outside of this process should provoke an immediate investigation.

The account management audit events in the following table detail group membership changes.

Table 8. Group Membership Change Events

Event ID



631, 632,
633, 634

Security Enabled Global Group Change

Examine the Target Account Name field to determine if the group changed was global or had broad access privileges.

635, 636,
637, 638

Security Enabled Local Group Change

Examine the Target Account Name field to determine if the group changed was Administrators, Server Operators, or Backup Operators.

639, 641,

Security Enabled Group Change

Indicates a change to a group other than deletion, creation, or membership changes. Examine the Target Account name to ensure that a high privilege group was not altered.

659, 660, 661, 662

Security Enabled Universal Group Change

Examine the Target Account Name field to ensure that a high privilege group, such as Enterprise Admins, was not altered.

Note   Distribution group membership does not provide access to network resources, because distribution groups are not security principles. However, membership of certain distribution groups can create security issues, depending on the group. For example, placement of user accounts into a management or executive distribution group could result in a user receiving e-mail messages inappropriate to their position.

Unauthorized Account Usage Attempts

Promotion of the first Active Directory domain controller in a forest creates an administrator account that is a member of both the Domain Admin and Enterprise Admin groups. This account requires particular protection, because it is the only account that is not affected by account lockout settings. Therefore, even when an account lockout policy is in place, this account is especially vulnerable to dictionary attacks.

Effective security monitoring should be able to identify all attempts to log on with this administrator account, even if it has been renamed. For more information about elevating security on administrative accounts, see The Administrator Accounts Security Planning Guide at

In addition, 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 credentials. Such events should prompt immediate investigations.

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

Table 9. Unauthorized Logon Events

Event ID





Logon Success

528 is a common event. However, event 540 should provoke an examination of the Target Account Name to determine if it was caused by the default administrator account.


Logon Failure – Unknown User Name or Password

Always investigate when Target Account Name is the Administrator or renamed default administrator account. Also investigate if logon failures are just below the lockout threshold. Also check for attempts where Target Account Name is administrator or root and when Domain Name is unknown.


Logon Failure – Disabled Account

Examine the Target Account Name and Workstation Name to determine source. This event should prompt an investigation as a possible intrusion attempt by former account users.


Logon Failure – Expired Account

Examine the Target Account Name and Workstation Name to determine source. This event should prompt an investigation as a possible intrusion attempt by former account users.


Special Privileges Assigned to New Logon

Indicates a privilege assignment that can grant a new account administrative privilege or the ability to alter the audit trail. Compare Logon ID field with events 528 or 540 to easily determine if an account obtained administrator equivalence.

Another security issue that involves unauthorized use of account credentials stems from use of effective password policies, such as strong password policies and shorter password expiration times; sometimes users write down or otherwise record their passwords so that they can remember them. This issue is particularly noticeable in environments that have multiple identity stores without identity management services, which demand use of multiple passwords and accounts.

Note   For information about password management in heterogeneous environments, see the Microsoft Identity and Access Management Series at

Organizations must guard against users recording their passwords, especially in plain sight, because unauthorized individuals could discover and use this information to launch an attack. Monitoring this type of intrusion is possible using the information from the preceding table, but involves a cross-correlation of this information with a history of logon successes for the user account in question so that a list of workstations common for that account to access can be created for comparison.

Note   It is possible to restrict user accounts to specific workstations using built-in Active Directory functionality. However, to use this functionality the network must support network basic input/output system (NetBIOS) naming, as supplied by Windows Internet Naming Service (WINS), for example.

Interactive Logon with Service Account Credentials

When services start they must present logon credentials. Sometimes, certain services may require the use of a domain account to run services or connect to remote computers. Some services may even require administrator credentials, or must interact with the desktop as well.

In Windows Server 2003 and later, some service accounts (such as the Alerter service) can be started with the –LocalService switch. In addition, services that require network connectivity can use the Network Service account NT AUTHORITY\Network Service. All services that require user accounts should be checked to ensure that the accounts used are protected with strong passwords. Security monitoring should confirm that logon events for such accounts occur only when associated services start. For more information about elevated security for service accounts, see The Services and Service Account Security Planning Guide at

The primary security concern with service accounts develops when such accounts log on interactively instead of as a service. Such events only occur when a service account has been compromised by an intruder and logs on with that account. If the compromised service account has administrator privileges, the intruder has gained access to substantial capability and can disrupt normal network services.

All resources that service accounts can access should be identified and should not have any unexplained permissions that involve access to high-value data. For example, a service account may occasionally require write access to a log file directory, but this is generally not the case. Service accounts that can interact with the desktop also deserve special scrutiny because such accounts provide greater opportunities for attackers to exploit.

The following table lists Account Logon and Login audit events that identify unauthorized use of service account credentials.

Table 10. Logon with Service Account Credentials Events

Event ID




Logon Success – Console Attack or Terminal Services

Indicates an attack in progress if a Logon Type 10, a service account, or the local system account is associated with this event. This event should prompt an immediate investigation.


Logon Failure – Logon Type Not Allowed

Indicates a failed attempt to log on interactively with service account credentials when forbidden by group policy settings. Check the Target Account Name, Workstation Name, and Logon Type when this event occurs.


Process Was Assigned a Primary Token

Indicates a service is using a named account to log on to a system running Windows XP or later. Correlate with information in events 672, 673, 528, and 592 to investigate.


User Attempt to Install a Service

This event should not occur often in a business environment with a clearly defined acceptable applications policy and system standardization process. This event should prompt an investigation when change control processes do not correlate in such environments.

Unauthorized Program Execution

Administrator level accounts are capable of installing and executing programs, and are therefore typically only delegated to trusted personnel who require such elevated capabilities. Because of the risks associated with untested software, it is important to design a list of approved and licensed software along with a process for requesting, testing, and approving new applications. Unapproved applications should be limited to an isolated test environment, and should not be installed in a production network environment outside of an established change control process. Even then, they should only be allowed after being added to an approved software list.

The following table lists process tracking events that can identify the use of unauthorized programs.

Table 11. Run Unauthorized Program Events

Event ID




Creating a new Process

Indicates a new process was created. Examine the Image File Name and User Name fields and compare with an authorized programs list when there is an established permissible program policy in a business. Also look for instances where LocalSystem is used to launch a command prompt, because this is a common method for evading an audit trail.


Creating a Scheduled Job

Examine the Target Name and Task Time when such events occur at unexpected times.

Note   Process tracking security audits are capable of identifying unauthorized programs. However, process tracking generates multiple Security log entries, so care must be taken that the number of events does not overwhelm security detection mechanisms.

Access Unauthorized Resources

The following table of object access audit events involve attempts to access resources that a user is not authorized to use.

Table 12. Access Attempts to Unauthorized Resources Events

Event ID




Access Refused to Existing Object

Examine the Object Name field to determine the accessed resource and correlate the Primary User Name and Primary Domain fields or the Client User Name and Client Domain Fields to determine the source.


Attempt Made to Create a Hard Link to an Audited File

Indicates a user or program attempted to create a hard link to a file or object. An established hard link allows an account to manipulate a file without creating an audit trail if the account has rights to the object.

Use of Unauthorized Operating Systems

The use of unauthorized operating systems can cause significant issues, ranging from reduced protection from vulnerability exploits to the increased likelihood of data corruption on file systems. Administrators and users can introduce unauthorized operating systems into a network through the following mechanisms:

  • Personal computers connected to the network locally or remotely.

  • Use of CD-bootable operating systems.

  • Reinstallation of a Windows operating system.

  • Use of Virtual PC images.

Organizational policies can specify how users may connect to the network from remote locations via a virtual private network or remote access service, and include requirements for connecting systems such as operating system type, update level, and installation of protective measures such as personal firewalls and antivirus software. For more information about how to ensure remote systems comply with business security policies, see the Implementing Quarantine Services with Microsoft Virtual Private Network Planning Guide at

It is also possible for users to use Windows XP installation CDs and restart their computers to install an unmanaged operating system. In such cases it may be possible to detect this type of activity by locating logon attempts from an Administrator user account from an unidentified workgroup name or the default Workgroup name.

Note   Some open source distributions are available in CD-bootable form, which enables use of the operating system without installing in on a local system. Because the operating system is not actually installed on the local computer, it is difficult to spot such activity. However, logon attempts from user accounts named “root” in a homogenous network environment or from unexpected computer names can indicate the presence of an unauthorized operating system in use. It is possible to prevent this type of activity by disabling the ability to boot from CD in a computer’s BIOS settings and then password protecting the BIOS configuration, but this approach might not be practical in some environments.

Virtual PC images provide a complete emulation of a computer environment on a host computer. This emulation runs its own operating system with its own computer name, user accounts, directory services structure, and programs in a virtual environment. A virtual PC instance is also capable of starting, running, and stopping independently from a host system and so will not likely create any audit events on that host computer. This capability, along with the ability of a virtual computer to connect to the host’s network, obtain IP addresses, and even map to shared drives, presents a number of security risks ranging from weak password protection to increased vulnerability to exploits, because it would not likely be governed by any established update process in place on the network. Given these risks presented by virtual PCs, it is important to restrict the usage of virtual PC software to authorized personnel and establish documented processes regarding the creation and usage of virtual PC instances.

To detect unauthorized operating system usage, a security monitoring solution needs to be able to detect the following:

  • Unrecognized user accounts, computer names, workgroups, or domain names.

  • Duplicate or out-of-range IP addresses.

  • Attempts to log on with the default Administrator account.

The Process Tracking events listed in the following table can be used to detect the use of unauthorized operating systems.

Table 13. Unauthorized Platform Usage Events

Event ID




Logon Failure – Unknown User Name or Password

Check for attempts in which the Target Account Name field equals Administrator or root or where the Domain Name is unknown.


Logon Failure-User Not Allowed to Logon at This Computer

Indicates that a user may be attempting to log on to restricted workstations.


Creating a New Process

Check the Image File Name and User Name fields to ensure that the program is authorized for that use by that account.

Create or Break Trust Relationships

Trust relationships enable accounts in one domain to access resources residing in another domain. The creation of trust relationships is clearly not a routine operation and should only occur within the scope of an established change control process. Breaking trust relationships is also an activity that should only be performed after being approved in a change control process and after careful consideration with regard to this action’s effects on the network.

The Policy Change audit events in the following table identify trust relationship activities.

Table 14. Changing Trust Relationships Events

Event ID




Trust Relationship with Another Domain Was Created, Deleted, or Modified

These events will be generated on the domain controller that established the trust relationship. This event should prompt an immediate investigation when not correlated with an established change control request process. Examine the User Name field to determine the requesting account.

Unauthorized Security Policy Changes

Changes to approved security policy settings should only occur within the framework of an established change control process. Any changes occurring outside of this approval process should lead to an immediate investigation.

This type of security policy changes include:

  • Group Policy settings

    • User account password policy

    • User account lockout policy

    • Audit policy

    • Event log settings applying to the security event log

    • IPsec policy

    • Wireless network (IEEE 802.1x) policies

    • Public key and Encrypting File System (EFS) policies

    • Software restriction policies

  • Security settings

    • User rights settings

    • User account password policy

    • Security options

The preceding list only represents minimum requirements, because most businesses will likely add more Group Policy settings in their environment. Security audits will need to identify both successful and failed attempts to change these settings, because successful attempts should correspond to accounts with the authority to make these changes within an established process to do so.

The following table lists Policy Change audit events that identify Group Policy and local system policy changes.

Table 15. Policy Change Events

Event ID




Changing Audit Policy

Indicates a change to an audit policy. These events should be correlated with an established change control policy to determine if they were authorized.


Changing IPsec Policy

Indicates a change to the IPsec policy. Should be investigated when they occur outside of a system startup.


Encrypted Data Recovery Policy

These events occur when an encrypted data recovery policy is in use. Any occurrence outside of specified policies should prompt an investigation.

Note   For more information about Group Policy settings, see the "Security Policy Settings" section at

Attempt to Compromise Credentials

Attackers can use several approaches, ranging from dictionary attacks to social engineering efforts, to obtain user account credentials. Although the most well-known approach involves dictionary attacks against a single account, another common approach is the use of a set of passwords on all accounts in a directory services database. In the second case it is likely that the attacker either has access to the organization’s directory database or has guessed at the user name nomenclature and has a list of employees. To detect this type of attack it is necessary to have the ability to detect multiple logon failures on multiple accounts, even if account lockout thresholds are not triggered.

Password resets are another way to gain control of account credential information. Because password reset or change operations generate the same event for both success and failure, an attacker can avoid detection by circumventing the account lockout policy. To thwart these attempts, a security monitoring solution must be able to identify multiple password change or reset attempts, especially those that occur outside of established policies and business process frameworks.

Although password cycling is not an attack (it occurs when users attempt to circumvent password reuse policies by using scripts to cycle through numerous passwords to use the original password), they still present a threat to security efforts. During such efforts, the number of password resets will roughly equal the password reuse threshold and therefore will appear as a rapid series of 627 events. Implementation of password minimum age policies can cause such attempts to fail.

The following table lists events that can result from attack attempts on authentication credentials, but these events can also occur as part of normal network operations—such as when legitimate users forget passwords.

Table 16. Attack Authentication Credentials Events

Event ID




Logon Failure – Unknown User Name or Password

Check for attempts in which Target Account Name equals Administrator or some other administrative level account that may not be authorized to change passwords. Check for multiple logon failures that are below the lockout threshold. Correlate with Event 529 with Event 539 to identify patterns of continuous account lockouts.


Logon Failure – Logon Type Not Allowed

Indicates that a user attempted to log on with an account type that is not permitted, such as network, interactive, batch, or service. Check Target Account Name, Workstation Name, and Logon Type fields.


Account Locked Out

Indicates an attempt to log on with an account that has been locked out. Correlate with Event 529 to detect patterns of continued lockouts.


Replay Attack Detected

Indicates that an authentication package, usually Kerberos, detected an attempt to log on by replay of a user’s credentials. Although this event could be a sign of incorrect network configuration, it should still prompt an immediate investigation.


Change Password Attempt

Indicates that someone other than the account holder attempted to change a password when the Primary Account Name field does not match the Target Account Name field.


User Account Password Set or Reset

This activity should be restricted to authorized accounts, such as a help desk account or a user self-service password reset account.


User Account Automatically Locked

Indicates an account lockout due to the number of sequential failed logon attempts being greater than the account lockout limit. Correlate with events 529, 675, 681, and 676 (Windows 2000 Server only). Also refer to the entry for event 12294 in this table.


Pre-authentication Failed

Indicates a possible time synchronization issue or computer accounts that are not correctly joined to the domain. Correlate with event 529 to determine the exact reason for logon failure.


Account Lockout Attempt

Indicates a possible brute force attack against the default administrator account. Because account lockout policies are not enforced on this account, it is recorded as SAM Event 12294 in the System event log. Any occurrence of this event should prompt an investigation because it can indicate the use of an unauthorized operating system. Check the Domain Name field for unknown domains.

Vulnerability Exploits

Vulnerabilities are a prime target for an attacker to exploit in an intrusion attempt, because they can exist on any computer and require time and effort to remediate. The period of time between the discovery of vulnerabilities and the development of exploits for those vulnerabilities, typically called the vulnerability to exploit window, has grown shorter over time, which means there is less time to develop, test, and distribute patches for those vulnerabilities.

The best defense against vulnerability exploits is still an effective patch management process that quickly tests and deploys security updates within an environment. Some services that can assist with this process are Microsoft Systems Management Server (SMS) 2003 or Windows Software Update Service (WSUS).

Security monitoring on the perimeter network is also particularly important in this regard, because computers residing there are most readily available to an attacker. Without mechanisms in place to detect attacks as they occur, an organization my not realize that anything is amiss until the network has already been compromised. Therefore it is vitally important that computers residing in the perimeter network are carefully monitored for a wide range of audit events.

In addition to events already discussed, most notable events detailed in the “Attempt to Compromise Credentials" section include unauthorized access attempts and privilege identity usage. The following table lists some events that can identify such attacks.

Table 17. Vulnerability Events Cause by Vulnerability Exploit Escalation of Privileges

Event ID





Local Logon and Logoff

Correlate the Logon ID field when such events occur on perimeter computers. Should prompt investigation when User Account Name, Time, or Workstation Name fields contain unexpected values.


User Initiates Logoff

This event can be considered as equivalent to Event 538, because a token leak can cause a failure to audit Event 538 but will cause Event 551 to occur instead.


Privileged Logon

Indicates an administrator account logon, an account logon with sufficient privileges to tamper with the Trusted Computing Base (TCP), or sufficient privileges to take over a computer on a Windows Server 2003 with SP1 or later. On earlier versions of Windows, this event is only of interest when associated with sensitive privileges such as SeSecurityPrivilege or SeDebugPrivelege.

Note   In Windows versions prior to Windows Server 2003, event 576 will list in the Privileged Use category. In Windows Server 2003 and later, the Logon category will also list this event. Therefore configuration of audit settings for either category will cause this event to appear.

Attempts to Circumvent Auditing

Just as there are multiple methods available to attack a business’s network, there are also various techniques available to hide those attempts and elude discovery. For example, an attacker can change the security policy on a compromised system or domain to prevent event logs from recording suspicious activity, or a Security log can be deliberately erased so that any audited information is lost.

It is possible to detect attempts to elude a security monitoring solution with such techniques, but it is challenging to do so because many of the same events that can occur during an attempt to cover the tracks of intrusive activity are events that occur regularly on any typical business network.

The following table of multiple event types can help identify auditing circumvention attempts by attackers who are trying to hide evidence of a security breach.

Table 18. Circumvent Event Auditing Events

Event ID




Windows Start Up

Usually occurs after Event 513. Unexpected restarts should be investigated.


Windows Shut Down

Usually occurs before Event 512. High-value computers should only be restarted by authorized personnel, and even then only in accordance with an established change control or other procedure. Occurrence of this event on any server should prompt an immediate investigation.


Audit Failure

This event can occur either when too many events overwhelm the event log buffer or when the security log is not set to overwrite. Although these issues can be prevented by limiting the types of events monitored on most computers, high-value or vulnerable computers require more detailed monitoring to secure and therefore need to be carefully monitored.


Clearing Security Event Log

Security event logs should never be cleared without authorization. Check the Client User Name and Client Domain fields to cross-correlate with authorized personnel and procedural approval records.


Changing the System Time

This activity can be used to mislead forensic investigations or provide attackers with false alibis. Check the Client User Name and Client Domain fields for cross-correlation with authorized personnel in addition to checking the Process Name to ensure it is listed as %windir%\system32\svchost.exe.


Unable to Log Events

Occurs when Windows is unable to write events to the event log. This event should be investigated whenever it occurs on any high-value systems.


A User Account Privilege Was Assigned

Occurs when a new privilege is assigned to a user account. The event log records this action along with the user account Security Identifier (SID), not the user account name.


A User Account Privilege Was Removed

Occurs when a privilege was removed from a user account. The event log records this action along with the user account’s SID, not the user account name.


Changing Audit Policy

Although this event does not necessarily indicate that there is a problem, an attacker can modify audit policies as part of an attack. This event should be monitored on high-value computers and domain controllers.


System Access Was Granted to an Account

Occurs when a user was granted access to a system. The User Name and Account Modified fields should be checked when the access permission is listed as interactive.


System Access Was Removed from a System

This event may signal that an attacker has attempted to remove evidence involving Event 621 or is attempting to deny service to some other account(s).


Changing the Domain Security Policy

Occurs when there is an attempt to modify password policy or other domain security policy settings. Check the User Name and correlate with any authorization records.

Forensic Analysis

Although forensic analysis relies on many elements discussed in this paper, it is still fundamentally different from the other monitoring and attack detection solutions discussed because it focuses on storage and analysis of security information and is used in response to an attack after it has occurred. Most forensic investigations begin as a list of events associated with a specific user or system.

Security monitoring for forensic analysis requires:

  • Archival of selected event types.

  • An estimate of the expected number of events each day.

  • Set time limits for online, offline, and archive storage.

  • Databases scaled to cope with the expected number of events.

  • Backup system capable of coping with the expected daily event load.

  • Set policies regarding management of the archival system.

There are three main factors that determine storage requirements for a forensic analysis program:

  • The number of events that must be recorded.

  • The rate these events are generated by target computers.

  • Online storage duration for availability.

An understanding of business needs along with the information provided in previous sections should help make determinations with regard to these three factors so that a reasonable storage requirement can be obtained.


It is clear in today’s network environment that an effective and comprehensive security monitoring and attack detection solution is not an option but a necessity for any midsize business. The threats and risks facing business networks are numerous and not only originate from outside the perimeter but also include internal threats both intentional and accidental. Well-reasoned security monitoring systems take all risks into account and require a thorough understanding of those risks in addition to the current architecture of a business network and the hallmarks of potential threats and activities that could endanger the data residing on that network’s systems.

Microsoft clearly takes security very seriously, and has accordingly provided many tools that can be used to help build an effective security monitoring and attack detection system. Windows Server 2003 and other versions of the Windows operating system help supply the basis for this security monitoring solution with their built-in security audit logging functionality. When combined with other components such as Microsoft Operations Manager and EventCombMT and the necessary business policies and processes, a comprehensive monitoring system can be developed.

Appendix A: Excluding Unnecessary Events

The events listed in the following table are typically excluded from security monitoring queries because of their frequency and because they do not usually provide any useful results when included in a security monitoring solution.

Table A1. Unnecessary Events

Event ID




User Logoff

This event does not necessarily indicate the time that a user has stopped using a system. For example, if the computer is shut down or loses network connectivity it may not record a logoff event at all.


A Handle to an Object Closed

Always records as a success.


Client Context Deleted by Authorization Manager

Expected occurrence when Authorization Manager is in use.


Process Generates Nonsystem Audit Event with Authorization Application Programming Interface (AuthZ API)

Expected activity.


Privilege Service Called, Privileged Object Operation

These are high volume events, which typically do not contain sufficient information to act upon since they do not describe what operation occurred.


A Handle to an Object was Duplicated

Expected activity.


Indirect Access to an Object was Obtained

Expected activity.


Backup of Data Protection Master Key

Expected activity. Occurs every 90 days under default settings.


Recovery of Data Protection Master Key

Expected activity.


Kerberos AS Ticket Request

Does not contain any additional information if audit details from logon events 528 and 540 are already being collected. This event records that a Kerberos TGT was granted, actual access will not occur until a service ticket is granted, which is audited by Event 673. If the PATYPE is PKINIT, the logon was a smart card logon.


Account Logon

Activity already recorded by other events.


Password Policy Checking API Called

Expected activity.


Forest Namespace Collision

This event is not security related.


Trusted Forest Information Added, Deleted, or Modified

Expected activity. These events should not be confused with the addition, modification, or deletion of the trust itself.


Various Active Directory Replication Events

These events are not security related.

Note   There are some risks associated with the exclusion of any information from an audit, but this level of risk should be compared to the benefits involved with reducing the load on an analysis agent.

Appendix B: Implementing Group Policy Settings

This appendix should be used to check the current settings in an environment, and includes additional settings that affect security monitoring and attack detection. To configure Group Policy security audit events properly, the settings in the following table need to be applied.

Table B1. Group Policy Security Audit Settings

Policy path


Policy setting and comments

Local Policies/ Audit Policy

Audit Account Logon Events

Enable audit success for all computers because this event records who accessed the computer. Enable audit failures with caution because an attacker with network access but no credentials could launch a Denial of Service attack (DoS) by forcing a computer to consume resources while recording these events. Enable audit success with caution as well because this setting can result in DoS attacks if computers are set to shut down when audit logs are full. Correlate any administrator logons with any other suspicious entries.

Local Policies/ Audit Policy

Audit Account Management

Enable both success and failure events. Correlate all successful audit entries with administrator authorizations. All failures should be regarded as suspicious.

Local Policies/ Audit Policy

Audit Directory Service Access

The Default Domain Controllers Group Policy enables this setting by default. Configure audit settings on sensitive directory objects by use of system access control lists (SACLs) in Active Directory Users and Computers or Active Directory Services Interface Editor (ADSI Edit). You should plan your SACL implementation, and you should test your SACLs in a realistic lab environment before deploying them to a production environment. This approach prevents overload of the security logs from too much data.

Local Policies/ Audit Policy

Audit Logon Events

Enable audit success for all computers because this event records who accessed the computer. Enable audit failure with caution because an attacker with network access but without credentials could create a DoS situation by generating excess failures.

Local Policies/ Audit Policy

Audit Object Access

Use caution when enabling this setting because it can result in very high audit volume. Configure audit settings only for high-value folders via SACLs, and only audit the specific types of access that are of interest. If possible, only audit write events and not read access events.

Local Policies/ Audit Policy

Audit Policy Change

Enable both success and failure auditing. Cross-correlate any success events with administrative authorizations.

Local Policies/ Audit Policy

Audit Privilege Use

Do not enable auditing for privilege use because of the high volume of events that this configuration would generate.

Local Policies/ Audit Policy

Audit Process Tracking

Enable this setting on vulnerable computers and immediately investigate unexpected application activity, by isolation of the system if necessary. Do not enable this setting on Common Gateway Interface (CGI) Web servers, test systems, servers that run batch processes, or developer workstations because this setting can cause event logs to fill up.

Local Policies/ Audit Policy

Audit System Events

Enable both success and failure auditing.

Local Policies/ User Rights Assignment

Generate Security Audits

This setting is assigned by default to Local System, Local Server, and Network Service. This right should not apply to any accounts other than service accounts. An attacker can use this setting to generate spurious or inaccurate events in the security log.

Local Policies/ User Rights Assignment

Manage Auditing and Security Log

Use this setting to restrict administrators from making changes to audit settings on files, folders, and the registry. Consider creating a security group for administrators who are permitted to change audit settings and remove the administrators group from the Local Security Policy settings. Only members of a security group should be able to configure auditing.

Local Policies/ Security Options

Audit: Audit the Access of Global System Objects

This setting adds SACLs to named system objects such as mutexes, semaphores, and MS-DOS devices. Default settings on Windows Server 2003 do not enable this option. Do not enable this setting because it results in a high volume of events.

Local Policies/ Security Options

Audit: Audit the use of Backup and Restore Privilege

Backup and restore operations provide an opportunity to steal data by circumventing ACLs. Do not enable this setting because it results in a very high volume of events.

Local Policies/ Security Options

Audit: Shut Down System Immediately if Unable to Log Security Events

Only enable this setting after careful consideration and only on high-value computers, because attackers can use this setting to launch DoS attacks.

Event Log

Maximum Security Log Size

Recommended settings depend on projected event volumes and the settings for retention of security logs. This setting can only use increments of 64 KB and the average event size is 0.5 KB. In high volume environments this setting can be configured as high as 250 MB, but the total size of all event logs combined cannot exceed 300 MB.

Event Log

Prevent Local Guest Groups from Accessing Security Log

Windows Server 2003 enables this setting by default, do not change.

Event Log

Retain Security Log

Only enable this setting if the selected retention method is “Overwrite events by days.” If an event correlation system that polls for events is used, then ensure that the number of days is at least three times the poll frequency to allow for poll cycle failures.

Event Log

Retention Method for Security Log

Enable the Do Not Overwrite Events setting in high security environments. If this is the case, then establish procedures to empty and archive logs regularly, particularly if Shut Down System Immediately if Unable to Log Security Audits is enabled.


Get the Security Monitoring and Attack Detection paper