Security Monitoring and Attack Detection

On This Page

	Introduction
	Definition
	The Midsize Business Challenge
	Solutions
	Summary
	Appendix A: Excluding Unnecessary Events
	Appendix B: Implementing Group Policy Settings

Introduction

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.

Overview

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:

Definition

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.

Solutions

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.

Top of page

Definition

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

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:

To read more about MOF, refer to the Microsoft Operations Framework Web site at www.microsoft.com/mof. More information about the Security Management SMF is available at www.microsoft.com/technet/itsolutions/cits/mo/smf/mofsmsmf.mspx.

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 http://go.microsoft.com/fwlink/?linkid=30794.

Top of page

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:

Top of page

Solutions

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:

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 www.cert.org/archive/pdf/2004eCrimeWatchSummary.pdf, 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 www.cert.org/archive/pdf/insidercross051105.pdf, 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
See full-sized image

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

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 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:

Solution Planning

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

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:

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 http://go.microsoft.com/fwlink/?LinkId=14845.

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:

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 http://go.microsoft.com/fwlink/?LinkId=41311.

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:

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:

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:

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:

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

EventCombMT (multi-threaded) is a component of the Windows Server 2003 Security Guide, which is available at http://go.microsoft.com/fwlink/?LinkId=14845. 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:

Figure 4. EventCombMT
See full-sized image

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:

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 www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx and in the "How Log Parser 2.2 Works" article at www.microsoft.com/technet/community/columns/profwin/pw0505.mspx.

EventQuery.vbs

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 www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/event_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:

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
See full-sized image

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:

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:

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 www.cert.org/archive/pdf/FRGCF_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

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:

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.

Requirements

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

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:

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:

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:

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:

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:

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

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:

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

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:

Table 4. Event 592

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:

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

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

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

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

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

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 http://go.microsoft.com/fwlink/?LinkId=41315.

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

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 http://go.Microsoft.com/fwlink/?LinkId=14841.

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 http://go.Microsoft.com/fwlink/?LinkId=41311.

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

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

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

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:

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 http://go.microsoft.com/fwlink/?LinkId=41307.

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:

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

Create or Break Trust Relationships

Trust relationships enable accounts i