The Security Monitoring and Attack Detection Planning Guide

The Security Monitoring and Attack Detection Planning Guide
The information in this document and any document referenced herein is provided for informational purposes only, is provided AS IS AND WITH ALL FAULTS and cannot be understood as substituting for customized service and information that might be developed by Microsoft Corporation for a particular user based upon that users particular environment. RELIANCE UPON THIS DOCUMENT AND ANY DOCUMENT REFERENCED HEREIN IS AT THE USERS OWN RISK.
MICROSOFT CORPORATION PROVIDES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION CONTAINED IN THIS DOCUMENT AND ANY DOCUMENT REFERENCED HEREIN. Microsoft Corporation provides no warranty and makes no representation that the information provided is in this document or any document referenced herein is suitable or appropriate for any situation, and Microsoft Corporation cannot be held liable for any claim or damage of any kind that users of this document or any document referenced herein may suffer. Your retention of and/or use of this document and/or any document referenced herein constitutes your acceptance of these terms and conditions. If you do not accept these terms and conditions, Microsoft Corporation does not provide you with any right to use any part of this document or any document referenced herein.
Complying with the applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights or other intellectual property rights covering subject matter within this document. Except as provided in any separate written license agreement from Microsoft, the furnishing of this document does not give you, the user, any license to these patents, trademarks, copyrights or other intellectual property.
2005 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, Outlook, Windows, Windows Media, Exchange Server, SQL Server, Systems Management Server, Visual Studio, and Visual Basic are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Table of Contents
Chapter 1: Introduction................................................................................................................. 1 Executive Summary ..................................................................................................................... 1 The Business Challenge .......................................................................................................... 1 The Business Benefits.............................................................................................................. 2 Who Should Read This Paper.................................................................................................. 2 Reader Prerequisites................................................................................................................ 2 Planning Guide Overview ............................................................................................................ 2 Chapter 2: Approaches to Security Monitoring.......................................................................... 5 Introduction .................................................................................................................................. 5 Implement Security Monitoring .................................................................................................... 6 Correlate Security Audit Events ................................................................................................... 7 Event Comb MT ....................................................................................................................... 7 Microsoft Operations Manager 2005 ........................................................................................ 8 Independent Software Vendor Solutions ..................................................................................... 8 Chapter 3: Issues and Requirements ........................................................................................ 11 Introduction ................................................................................................................................ 11 Detect Policy Violations ............................................................................................................. 11 Business Issues ..................................................................................................................... 12 Technical Issues..................................................................................................................... 13 Security Issues ....................................................................................................................... 14 Solution Requirements ........................................................................................................... 14 Identify External Attacks ............................................................................................................ 14 Business Issues ..................................................................................................................... 15 Technical Issues..................................................................................................................... 15 Security Issues ....................................................................................................................... 16 Solution Requirements ........................................................................................................... 16 Implement Forensic Analysis ..................................................................................................... 17 Business Issues ..................................................................................................................... 17 Technical Issues..................................................................................................................... 17 Security Issues ....................................................................................................................... 18 Solution Requirements ........................................................................................................... 18 Summary.................................................................................................................................... 18 Chapter 4: Design the Solution .................................................................................................. 19 Introduction ................................................................................................................................ 19 Solution Elements ...................................................................................................................... 19 Solution Concept .................................................................................................................... 19 Solution Prerequisites ............................................................................................................ 20 Solution Planning ................................................................................................................... 20 Solution Architecture .............................................................................................................. 22 How the Solution Works ......................................................................................................... 23 Enable Selective Auditing....................................................................................................... 23 Detect Policy Violations ............................................................................................................. 24 Access Resources by Changing File Permissions................................................................. 24 Access Resources by Password Resets................................................................................ 25 Create, Change, or Delete User Accounts............................................................................. 26 Place Users into Groups ........................................................................................................ 27 Attempt to Use Unauthorized Accounts ................................................................................. 28 Log on Interactively with Service Account Credentials .......................................................... 29 Run Unauthorized Programs.................................................................................................. 30 Access Unauthorized Resources ........................................................................................... 31
Damage Authorized Files ....................................................................................................... 31 Introduce Unauthorized Operating Systems .......................................................................... 31 Obtain Other Users' Credentials ............................................................................................ 33 Attempt to Circumvent Auditing.............................................................................................. 33 Create or Break Trust Relationships ...................................................................................... 35 Making Unauthorized Changes to Security Policy ................................................................. 35 Identify External Attacks ............................................................................................................ 36 Attempt to Compromise Credentials ...................................................................................... 37 Exploit Vulnerabilities ............................................................................................................. 38 Install a Rootkit or Trojan ....................................................................................................... 39 Trick a User into Running a Malicious Program..................................................................... 40 Access an Unauthorized Computer ....................................................................................... 40 Implement Forensic Analysis ..................................................................................................... 41 Summary.................................................................................................................................... 42 Appendix A: Exclude Unnecessary Events .............................................................................. 43 Appendix B: Implement Group Policy Settings........................................................................ 45
1
Introduction
Executive Summary
Extensive media reporting about the spread of malicious software through the Internet has significantly raised the profile of external threats to organizations' network resources. However, some of the greatest threats to any organization's infrastructure come from attacks that originate from within the internal network. The internal attacks that have the highest potential for damage result from the activities of those people in the most trusted positions, such as network administrators. Analysis of both internal and external threats has led many organizations to investigate systems that monitor networks and detect attacks. For organizations whose operations are constrained by regulations, security monitoring is an operational requirement. Increased prescriptive requirements from numerous institutions around the world places greater demands on organizations to monitor their networks, check resource access requests, and identify users who log on and off the network. Regulatory considerations can also mandate that companies archive monitored security data for certain lengths of time. The security log facilities in Microsoft Windows provide the starting point for a package that can monitor security. However, security logs alone do not provide enough information to plan a response to an incident. Security logs coupled with other technologies that collect and query security logs can form a central part of a security monitoring and attack detection system. This guide describes how to plan a security monitoring system on Windows-based networks. This system can detect attacks that originate from internal and external sources. The main aim of a security monitoring system is to identify unusual events on the network that indicate malicious activity or procedural errors.
The Business Challenge

Businesses face numerous challenges to implement effective security monitoring systems on large networks. Businesses must: Identify the need to protect information. Define authorization levels for administrators and users. Implement a comprehensive monitoring policy. Correlate this policy with detected security events.
These challenges also apply to organizations that have less complex network requirements.
The Business Benefits

Security monitoring provides two primary benefits for organizations of all sizes: the ability to identify attacks as they occur, and the ability to perform forensic analysis on the events that occurred before, during, and after an attack. With the ability to detect attacks as they occur, security departments can react quickly to reduce substantive damage to the network infrastructure. Forensic data also helps investigators identify the extent of the attack. Other benefits of security monitoring include: Reduces the effect of attacks. Provides for security staff to identity unusual patterns of behavior quickly. Creates auditing information to meet regulatory requirements.
For more information about these benefits, see Chapter 2, "Approaches to Security Monitoring."
Who Should Read This Paper

This guide provides useful information for organizations that have strict privacy concerns, particularly those that are constrained by regulations. This guide applies to organizations of all sizes that require identity protection and control of access to data. The intended audience for this guide includes IT managers and IT specialists such as enterprise architects and enterprise security administrators. In addition, consultants who are required to plan, deploy, or operate Windows-based networks and technical decision makers should find this information useful.
Reader Prerequisites
To understand the solutions that this guide presents, readers should understand and be familiar with the security issues and risk profile of their own network. They should also be familiar with the Windows event logging service. This guide uses the Operating and Supporting quadrants of the Microsoft Operations Framework (MOF) Process Model. It also uses the MOF Security Administration and Incident Management service management functions (SMFs). For more information about MOF, see the Microsoft Operations Framework Web site at www.microsoft.com/mof.
Planning Guide Overview

This guide consists of four chapters that focus on the essential issues and concepts to plan a security monitoring and attack detection solution. These chapters are: Chapter 1: Introduction This chapter provides an executive summary, introduces the business challenges and benefits, highlights the recommended audience for the paper, lists the reader prerequisites, and provides an overview of the chapters and solution scenarios included in this guide. Chapter 2: Approaches to Security Monitoring This chapter provides an overview of the various options for the implementation of a security monitoring and attack detection solution that uses Microsoft and third-party technologies.
Chapter 1: Introduction
Chapter 3: Issues and Requirements This chapter describes how to correlate the scope of security monitoring to other business requirements and to the known range of potential threats and attacks to an enterprise network. It discusses the business, technical, and security challenges of how to: Detect policy violations Identify external attacks Implement forensic analysis
This chapter defines a policy violation as any deviation from organizational policies. Finally, this chapter lists the solution requirements for a security monitoring and attack detection system. Chapter 4: Design the Solution This chapter provides detailed information about how to use security monitoring to detect attacks and implement archives of security audits. It describes recommended configuration settings for effective security monitoring and the changes that organizations need to make to security policies. This chapter also provides detailed prescriptive guidance on how to implement advanced security monitoring in large organizations. This prescriptive guidance describes how to address the issues of audit storage for high volumes of security events and how to plan attack detection in distributed networks.
2
Approaches to Security Monitoring
Introduction
No company would contemplate conducting business from premises that did not have adequate physical security, such as locks, alarm systems, cameras, fencing, or even security guards. Yet many companies are only becoming aware of the necessity for equal security measures to protect network assets from both external attack and internal intrusion. Security systems such as cameras and motion detectors are useful ways of detecting attempts to enter a building or a restricted area. However, organizations also need to implement systems that monitor network assets and detect attackers. Hence security monitoring is an important component of a successful network security strategy. In August 2004, the United States Secret Service, in conjunction with Carnegie Mellon University Software Engineering Institute's CERT Coordination Center, released a white paper that documents instances in which institutions have been vulnerable to massive fraud committed by their own internal users. For more information, see the "Insider Threat Study: Illicit Cyber Activity in the Banking and Finance Sector" white paper at http://www.secretservice.gov/ntac/its_report_040820.pdf. This report is in English. The 2004 E-Crime survey documents further evidence of this threat. The respondents to this survey included government and organizations in the information, telecommunications, banking, and financial sectors. The survey revealed that 43 percent of respondents detected an increase in electronic crime and data intrusions and that 70 percent reported at least one electronic crime in the previous year. The total cost of electronic crimes for all respondents exceeded 600 million U.S. dollars. For more information about the 2004 E-Crime survey, see the 2004 E-Crime Watch Survey Shows Significant Increase in Electronic Crimes press release at http://www.csoonline.com/releases/ecrimewatch04.pdf. Continued increases in business regulations and a greater awareness of the threats that external and internal attackers present has resulted in increased demands to implement effective security monitoring. To plan effective security monitoring, you must know what technologies are available to implement your solution. This chapter describes the Microsoft technologies that enable security monitoring and correlate security logs for analysis and archival.
Note: This document distinguishes between internal and external attacks. An internal attack is one that an employee, usually an administrator, carries out. An external attack comes from outside the organization. Although the increasing prevalence of technologies such as wireless networking makes it possible for external attackers to mount attacks that originate inside the network perimeter, these are still considered external attacks.
Implement Security Monitoring

You can record security events using the built-in security event log file that is included in all versions of Microsoft Windows from Microsoft Windows NT version 3.1 and later. This log file provides the basis for security monitoring on Windows-based networks. Additional utilities and programs can correlate these recorded events into a central repository. The security event log file uses a custom database format to record security monitoring data. You can read parts of this file, such as computer names and IP addresses, in a text editor. However, to read all the information in the security logs requires a suitable program, such as the Event Viewer console. The security event log file (SecEvent.evt) resides in the %systemroot%\System32\config directory. Unlike application and system logs, default NTFS file system permissions only allow members of the Administrators group and the system account to access this file. The security event log records two types of event: success audits and failure audits. A success audit event indicates that an operation that a user, service, or program performed completed successfully. A failure audit indicates that a similar operation did not complete successfully. For example, if you enable logon audits for failure events, the security event log records unsuccessful logon attempts. Note: Microsoft Windows Server 2003 with Service Pack 1 provides the ability to configure different security audit levels for different users. For more information about this feature, see Chapter 4, "Design the Solution." The following table lists security event categories and the events that each category logs. Table 2.1: Security Event Auditing Categories Category
Account logon events Account management Directory service access Logon events Object access
Effect
Audits logon attempts to a local account on a computer. If the user account is a domain account, this event also appears on the domain controller. Audits the creation, modification, and deletion of user and group accounts, in conjunction with password changes and resets. Audits access to objects in the Active Directory directory service. Audits attempts to log on to workstations and member servers. Audits attempts to access an object such as a file, folder, registry key, or printer that has defined audit settings within that object's system access control list (SACL). Audits any change to user rights assignment, audit, account, or trust policies.
Policy change
Chapter 2: Approaches to Security Monitoring
Category
Privilege use Process tracking System events
Effect
Audits each instance that a user exercises a user right, such as changing the system time. Audits application behavior such as program starts or terminations. Audits computer system events such as startup and shutdowns and events that affect system security or the security log.
The Audit Policy Group Policy setting controls which events create entries in the security logs. The path to these settings is Computer Configuration\Windows Settings\Security Settings\Local Policies. You can configure the Audit Policy settings through the Local Security Settings console, or at the site, domain, or organizational unit level through Group Policy in conjunction with Active Directory. Security logs provide a good foundation for comprehensive security monitoring. Group Policy settings provide centralized configuration of security log audit levels and the default security settings only allow administrators to access the security logs. However, monitoring of distributed attacks and implementing forensic analysis requires a monitoring system that can correlate audit events centrally.
Correlate Security Audit Events

The correlation of security audit events involves the collection of security events from multiple computers and placement of this information into a central location. Security personnel can then analyze this central repository to identify policy violations or external attacks. The repository can also provide the foundation for forensic analysis. This section introduces the Microsoft products and utilities that can correlate multiple security event logs. Several third-party products can also perform these functions.
Event Comb MT
Event Comb MT (multi-threaded) is a component of the Windows Server 2003 Security Guide that enables you to parse and collect events from multiple event logs on different computers. Event Comb MT runs as a multi-threaded application that enables you to specify numerous 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
Some specific search categories are built in to Event Comb, such as Account Lockouts, which searches 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 DC (incorrect password) 676 authentication ticket request failed 681 logon failure
If you want to search for attacks against the default Administrator account, you can add event 12294 (account lockout threshold exceeded) from the system log. This event is
particularly important, because the account lockout threshold does not apply to the default Administrator account. Hence an attacker can make multiple attempts to compromise the default Administrator account without triggering the account lockout mechanism. Note: Event 12294 appears as a Security Accounts Manager (SAM) event in the system log, not in the security log. Event Comb MT can save events to a table in a Microsoft SQL Server database, which makes it useful for long-term storage and analysis. You can use a range of client programs to access the information in the SQL Server tables, such as SQL Query Analyzer, Microsoft Visual Studio .NET or numerous third-party utilities. Event Comb MT v10.0 also includes command-line options that you can use to create scripts to automate the collection of events from security logs at regular intervals. Because Event Comb MT does not provide any form of client collection agent or automatically forward events to a central repository, it might not be suitable for all threat scenarios. Event Comb MT is available as a free download from the Account Lockout and Management Tools Web site, at http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=7af2e69c91f3-4e63-8629-b999adde0b9e. The Windows Server 2003 Security Guide is available at http://www.microsoft.com/downloads/details.aspx?FamilyId=8A2643C1-0685-4D89B655-521EA6C7B4DB
Microsoft Operations Manager 2005

Microsoft Operations Manager (MOM) monitors multiple servers in an enterprise environment. The MOM agent collects events from the event logs and forwards them to the MOM management server. The MOM management server then places those events into the MOM database. MOM 2005 and later can collect events from computers that do not run MOM agents. MOM uses its management pack rules to identify issues that affect the operational effectiveness of servers. You can define additional rules to look for certain events and, when those events occur, send instant notifications by e-mail, pop-up messages, or to pager devices. Although MOM provides many useful functions for security monitoring and attack detection, MOM was not designed for this purpose. Future releases of MOM are likely to provide greater facilities for collation of security logs.
Independent Software Vendor Solutions

Microsoft products do not provide an end-to-end solution for all aspects of security monitoring. The key gaps in current Microsoft product offerings include: Real-time event log alarms. Secure event log collection systems.
Chapter 2: Approaches to Security Monitoring
Microsoft partners provide the following products (listed in alphabetical order) that fill these gaps: EventReporter from Adiscon. EventReporter enables administrators to combine UNIX and Windows event log report and alert functions into a single environment. It supports the standard UNIX syslog protocol for integration with UNIX-based systems, and Simple Mail Transfer Protocol (SMTP) to forward alerts. EventReporter includes an agent that you can configure to collect security events from multiple computers, filter them, and place them into a database. Depending on the security event, you can then forward these events through e-mail, start applications, create network messages, and so on. For more information about Adiscon EventReporter, see the EventReporter Web site at www.eventreporter.com. GFI LANguard Security Event Log Monitor from GFI. LANguard Security Event Log Monitor performs event log based intrusion detection and network-wide event log management. It archives and analyzes the event logs of all network computers and alerts you in real time to security issues, attacks, and other critical events. The Security Event Log Monitor can archive event logs to a central database, and provides custom rules and reports for forensic analysis. For more information, see the GFI LANguard Security Event Log Monitor Web site at www.gfi.com/lanselm. Systrack 3 from Lakeside Software, Inc. Systrack 3 provides near real-time event log alarms through the Event Log Monitor. The Event Log Monitor periodically inspects all event logs on a computer to determine if anything new has happened since the last inspection. Systrack 3 filters any newly discovered event and takes appropriate action. These filters can use the default settings, userdefined settings, or a combination of default and user-defined settings. Specific character strings in any of the event properties, such as a user or workstation name can trigger event log alarms. An event can also run a script or restart the computer. The filters can also generate Simple Network Management Protocol (SNMP) traps, Windows pop-up messages, or e-mail alerts. For more information about Systrack 3, see the Lakeside Software Web site at www.lakesidesoftware.com.
3
Issues and Requirements
Introduction
An important part of an effective security strategy is to make an accurate assessment of the threats to your network. Just as organizations have different views on what constitutes a risk to their physical security, so companies have differing views on the risks to network data. These views depend on numerous factors, such as the industry sector in which the organization operates, the value of their data, and whether they have experienced previous attacks to their network. For more information about security risk management, see The Security Risk Management Guide at http://www.microsoft.com/technet/security/topics/policiesandprocedures /secrisk/default.mspx. Data from Microsoft partners and customers, coupled with information derived from the Microsoft corporate network, identifies three main concerns that security monitoring and attack detection can address. These areas of concern are to: Detect policy violations Identify external attacks Implement forensic analysis
This chapter describes each scenario, and Chapter 4, "Design the Solution," shows how to configure security monitoring and archiving to address these threats. To identify unusual activity in a network, you need to know what you consider typical for your environment. This guide attempts to distinguish between what is typical behavior and what is unusual. Identifying anomalies also requires you to implement a secure baseline on all your computers. Without this secure baseline, you cannot identify computers that do not meet baseline requirements. For more information about how to implement secure baselines, see the security How-To Articles at http://www.microsoft.com/technet/security/howto/default.mspx.
Detect Policy Violations

Policy violations form the largest category of security issues with which organizations much cope. Policy violations include the following actions: Creation of user accounts outside the proper process Use of administrator privileges without proper authorization Use of service accounts for interactive log ons
12
The Security Monitoring and Attack Detection Planning Guide Attempts to access files to which a user does not have permission Deletion of files that users have permission to access Execution of unapproved programs
The most common type of policy violation is unintentional user access attempts, such as trying to open unauthorized directories. However, access restrictions and limited rights usually prevent users from attempts at significant damage. Policy violations by administrators, whether deliberate or accidental, are of far greater concern. Unreliable network administrators pose a significant threat to an organization. Administrators need high levels of system access rights and privileges to carry out their jobs. Administrators have the ability to create user accounts, reset passwords, and change ownership of files and folders. However, just because administrators can carry out a procedure does not mean they have authorization to do so. Administrator rights also enable administrators to view network resources they should not see, such as financial records.
Business Issues
Most organizations should make the detection of policy violations a priority because of the probability that a violation can occur and the potential for damage. Business issues with the detection and prevention of policy violations include how to: Enforce strict background checks before hiring and at regular intervals during employment. Maintain independent security checks on administrator actions. Perform regular checks of the security monitoring system. Identify security breaches quickly. Confirm the extent of the security breach. Limit the damage that security breaches cause.
Enterprise organizations usually perform adequate security checks before a new employee joins the company. However, many organizations do not continue to monitor internal users for risky behavior. It is essential that your internal users sign explicit terms and conditions that alert them to your network security monitoring requirements. They must understand that if they try to open a file or access a share to which they do not have permission, the security logs will record that failed attempt. Internal users who work with high value files should know that the security logs will track each time they access those files. Note: It is becoming increasingly difficult to prosecute or fire employees without proof that they were fully aware of internal security monitoring and the consequences of deliberate attempts to access or destroy confidential data. Data protection requirements and human rights legislation may also require explicit consent.
Separate Duties
Organizations should implement strict separation of duties, so that different individuals or groups, such as the security or audit department, are responsible for the inspection of the actions of administrators. The inspection group should not have permission to perform administrator actions themselves, to safeguard against inspectors who turn into perpetrators.
Chapter 3: Issues and Requirements
13
Test Monitoring Functions

Organizations should carry out regular tests of the monitoring functions. One approach is to use penetration tests or a test administrator account to ensure that the alerts function correctly. These tests should occur on an irregular schedule each week to prevent an attacker from using the penetration test as a strike opportunity.
Define Security Processes and Responses

To identify security breaches quickly, an organization must have comprehensive processes that define how to perform particular network operations. For example, organizations might use an identity management system such as Microsoft Identity Integration Server (MIIS) 2003 to create (provision) user accounts. Although administrators can create user accounts directly, organizational policy would specify that they should not do so. Hence, if the security monitoring system detects event 624 (creation of a user account), the event should link to the MIIS 2003 provisioning account and not to an individual administrator's account. To limit the damage that security breaches cause, an organization must define suitable responses to anticipated incidents, such as rapid mobilization of onsite security staff. The speed and effectiveness of incident responses can provide significant enhancement of an organization's security profile if users or administrators know that a vigorous investigation follows any security incident, they are less likely to attempt to breach a security policy. Abundant media coverage reports on the threats to networks from external sources. However, experience shows that the probability of data loss or compromise from external attackers is significantly lower than the probability of data loss from incorrect configuration by network administrators. Although you should not become complacent about external threats, keep in mind that many organizations want to sell solutions to keep external intruders out of your network (because that is relatively easy to do). On the other hand, no one can sell you a package that prevents your administrators from making mistakes or from acting dishonestly
Technical Issues
To implement a functional security monitoring and attack detection system based on Windows security event logging, you must address how to: Manage high volumes of security events. To cope with high levels of security events, you must carefully consider which security audit settings to enable. This is particularly applicable to the audit of file and object access, which can generate vast quantities of data. Store and manage large numbers of events in a central repository. Storage of events can involve the management of terabytes of data. Because this technical requirement is of greater concern to forensic analysis, it is covered in more detail in the "Implement Forensic Analysis" section later in this chapter. Identify attack patterns. To identify attack signatures, you must know the patterns of events that indicate an attack. You should always respond in a timely and appropriate manner when an attack signature identifies an intrusion. Restrict administrators so that they cannot circumvent security audit controls. To prevent administrators from circumvention of audit controls, you should compartmentalize administrator responsibilities and create or allocate a group of security specialists to oversee the administrator audits.
14
Security Issues
Identification of security issues is the central focus of a security monitoring and attack detection system. Effective security monitoring should identify the following occurrences: Attempts to access resources through changes to file permissions Attempts to access resources through password resets Creation of new users Placement of users into groups Use of unauthorized administrative accounts Log ons at the console that use service account credentials Execution of unauthorized programs Deliberate damage to files (does not include corruption caused by disk errors) Introduction of unauthorized operating systems Creation or deletion of trust relationships Log ons with an incorrect account, such as a general administrative account Unauthorized changes to security policy
To identify these actions properly, you must be aware of the characteristic event sequences and be able to extract these sequences from other security events.
Solution Requirements
To detect organizational and security policy violations, your solution must contain: Well-defined security procedures that cover all network operations. Comprehensive security audit logs. Reliable centralized collection of security logs with suitable filters for analysis. Adjustable levels of security audits. Investigation of any discrepancies such as omissions, missing records, and so on.
To identify configuration errors, your solution should include: Well-defined change management procedures (that include validation) to cover all network operations. Effective security audit logs. A reliable centralized collection of security logs. Automated analysis of the security logs to identify configuration changes.
For more information about how to implement such a solution, see Chapter 4, "Design the Solution."
Identify External Attacks

External attacks come in two main forms attacks perpetrated by people and attacks carried out by malicious applications. Both types of attack have different characteristics and threat profiles. Human attackers can learn about the target network and modify their attack accordingly, whereas malicious applications can affect multiple computers and leave back doors for attackers to exploit.
15
Malicious applications include a variety of possible threats, such as viruses, worms, and Trojans. Although these applications can be troublesome and cause significant disruption, these attacks are easier to prevent than those perpetrated by people. Note: This guide does not include any information about attacks that involve hardware devices such as inline keystroke loggers, because security monitoring cannot detect these devices.
Business Issues
This guide addresses the business issues that arise from external attacks that attempt to penetrate the network and are detectable at either the application or the presentation layer. Security monitoring is not especially useful to identify a distributed denial of service (DDoS) attack, but other mechanisms such as Microsoft Internet Information Services (IIS) logs can identify the duration, packet type, apparent IP address (possibly spoofed), and other DDoS attack details. Identification of malicious applications is of considerable importance to organizations in all sectors, but particularly for those organizations that operate in the financial sector or are constrained by regulations. For example, such organizations have greater concerns about the presence of spyware applications. Spyware applications can reside on a server or workstation and communicate confidential information to external third parties. A major business issue with malicious applications is the uncertainty that they exist on a network. A particularly worrisome scenario is if the malicious software component is a rootkit or similar program that takes complete control of a computer and then masks the fact that an attacker now controls the computer. It is difficult to be sure that your computers do not have such malicious applications running, because the rootkit might be better at concealment than you are at detecting them.
Technical Issues
The increased numbers of attacks on organizations result from the actions of inexperienced attackers who use preconfigured scripts to exploit vulnerabilities. Far more dangerous are members of the small, dedicated set of highly skilled and experienced attackers (who can cooperate with each other) and can use a range of different attacks to attempt to penetrate a network. Note: This guide defines an attacker as a person who deliberately mounts an attack; a virus, worm, or Trojan that acts on its own is not an attacker. The main way to identify malicious applications is to track processes. If you track processes, you can identify each program that starts or stops on a workstation or server. The downside of this approach is that it generates a large number of events, the majority of which are not of interest. Two particular areas where analyzing tracked processed can be difficult are: Web servers that use Common Gateway Interface (CGI). Each page hit creates a new process. Development workstations. Application builds create numerous processes within a short period.
These factors can cause very high numbers of events in a short time or create numerous events continually. In either case, effective filters are necessary to extract the attack events from legitimate events.
16
Security Issues
The security issues that external attacks raise are considerable, because attackers have great flexibility in choosing their network intrusion method. External attackers can penetrate networks through the following mechanisms: Attempt to crack passwords. Change or reset passwords. Exploit vulnerabilities. Trick a user to run a malicious application. Use privilege escalation to compromise additional computers (called island hopping). Install a rootkit or Trojan. Use an unauthorized workstation. Use a phishing attack, in which a fraudulent e-mail points to a malicious Web site.
The primary method for the detection of attackers and malicious applications is to track processes. You need to apply this method carefully and integrate it with software restriction policies in Group Policy. Be aware that you should define very strict policies that dictate what programs can run on computers within perimeter networks. Note: Software restriction policies can have unintended effects on portable computers or within enterprise environments. Always create new Group Policy Objects (GPOs) to manage software restriction policies and do not apply software restrictions through the default domain policy. For more information about the use of software restriction policies, see Using Software Restriction Policies to Protect Against Unauthorized Software at http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx
The solution requirements to identify external attackers overlap with those required to identify internal threats. These requirements include: A defense-in-depth approach to security implementation. Effective security audit logs. Reliable centralized collection of security logs. Automated analysis of the security logs to identify attack signatures.
The solution requirements to detect malicious applications share some of the requirements to identify internal threats. These solution requirements include: Effective procedures to audit any unauthorized software on the network. Properly configured security audit logs. Reliable centralized collection and filters of security logs. Automated analysis of the security logs to identify suspicious behavior, with use of third-party programs where necessary.
For more information about protection against virus attacks, see The Antivirus Defensein-Depth Guide at http://www.microsoft.com/technet/security/guidance/avdind_0.mspx.
17
Implement Forensic Analysis

You can use forensic analysis to track the timing, severity, and consequences of a security breach and to identify the systems that attackers have compromised. Forensic analysis must record: Time of the attack Duration of the attack Affected computers Changes that the attacker made to the network
Because forensic analysis is a large subject on its own, this guide cannot cover this topic in full. In particular, this guide does not cover the evidence handling requirements of forensic analysis or coverage of forensic data sources other then the security event log.
Business Issues
Forensic analysis differs from other solution scenarios because it investigates incidents after they have occurred instead of in real time. Forensic analysis must provide a detailed list of all events of interest from one or more computers. The analysis system must be able to handle and archive large amounts of data in a suitable database. A key business decision is how long to preserve forensic data. Organizations must identify the maximum age for forensic data, after which the information becomes obsolete. The following table shows typical retention times for forensic data. Table 3.1: Storage Limits for Forensic Analysis Storage Factors
Online storage (database) Offline storage (backup) Regulatory environment Intelligence agencies
Storage Limit
21 days 180 days 7 years Permanent
Comments
Provides rapid access to recent events Reasonable limit for most organizations
Note: Some organizations (such as hospitals and government agencies) specify limits in terms of "do not keep longer than" rather than a set retention time. One option is to use online databases to retain the last three weeks of events, then archive older events into a highly compressible format, such as comma separated variable (CSV) text files for offline storage. If necessary, you can then import these CSV files back into the database for analysis. Whatever system you use, ensure that it matches your requirements for rapid investigation of recent events with the ability to recover older events if necessary. Your experience of security events within your own environment should guide you as to the best combination of data retention times for online and offline storage.
Technical Issues
Implementation of security monitoring for forensic analysis requires reliable collection and storage of very large numbers of events. The security monitoring requirements on the client are similar to those for the other solution scenarios but require far greater database storage and highly efficient data management.
18
The technical challenges include the following factors: Reliable and secure storage for online data Provision of large amounts of high performance disk space for online storage Reliable backup of old events to archive media Management of movement of older backups to a suitable archive store, if required Restoration of information from old backups
These challenges are not specific to security monitoring, because database administrators have similar concerns for applications such as online transaction processing (OLTP) databases. However, unlike OLTP and other traditional database applications, forensic analysis databases must cope with far greater volumes of writes rather than reads.
Security Issues
Typically, the data gathered for forensic analysis grows continuously. Very rarely, someone such as the enterprise security administrator might need to access this information. Nobody else should be able to access the information, interrupt its collection, or modify it. Security on the database must be comprehensive, so that only one or two highly trusted individuals can access the security data.
The solution requirements for implementation of forensic analysis are: Properly configured security logging. Secure checking of security log entries. A secure and centralized collection of security logs. Reliable storage of security monitoring information. Effective archive mechanisms.
Summary
This chapter described the solution requirements for the three scenarios contained within this guide. Chapter 4, "Design the Solution," explains how to incorporate these elements to create your security monitoring and attack detection plan.
4
Design the Solution
Introduction
The final step in the creation of a plan for a security monitoring and attack detection system is to create the solution design that addresses the solution requirements. This solution design must target the issues for the three defined scenarios: Detect policy violations Identify external attacks Implement forensic analysis
Because the main goal of the solution is to identify and profile attacks, the bulk of this chapter discusses the events that can indicate that an attack is in progress. These attack profiles connect to the security issues for each scenario that Chapter 3, "Issues and Requirements," covers. The precise implementation of this solution will vary, based on your organization's network topology.
Solution Elements
The solution design uses the same basic components for all three scenarios. The forensic analysis implementation requires additional resources for online, offline, and archive storage, but otherwise its solution architecture does not differ greatly from the implementation for the other two scenarios.
Solution Concept
The solution concept for security monitoring and attack detection requires you to examine and plan the appropriate levels of security audits for the following areas: Account management actions, such as to create users and add users to groups Access to protected files Changes to security policy Creation and deletion of trusts Use of user rights System restarts and changes to the system time Changes to registry settings Execution of unknown programs
20
The security monitoring and attack detection system collects information from the security event logs and collates this information centrally. The administrator can analyze this data for suspicious activities. Alternatively, the information can be stored and archived for later forensic analysis. A major component of this solution is the ability to configure per-user auditing, which is a feature of Microsoft Windows Server 2003 with Service Pack 1 (SP1) and Microsoft Windows XP with Service Pack 2 (SP2). Per-user audits allow you to specify different audit levels for specific user accounts, with higher audit levels for suspicious individuals or sensitive accounts.
Solution Prerequisites
The solution prerequisites for the configuration of a security monitoring and attack detection system are: Servers must run Windows Server 2003 SP1 or later as part of an Active Directory directory service domain. Client computers must run Windows XP Service Pack 2 or later as members of an Active Directory domain.
Note: Because computers in a perimeter network may be members of a workgroup rather than a domain, you cannot configure these computers with Active Directory Group Policy settings. However, you can use local policies and template files to configure these computers. This guide does not recommend any particular technology for central collation of security events but concentrates instead on the identification of the characteristic signatures of an attack. After you decide on a suitable collection mechanism, you can use the events and event sequences that this chapter describes to create queries that identify attacks.
Solution Planning
Before you implement a security monitoring and attack detection system, you should: Review current security audit settings. Assess administrator roles and user tasks. Review organizational policies and procedures. Identify vulnerable computers. List high-value assets. Identify sensitive or suspicious accounts. List authorized programs.
For more information about storage requirements, see the "Implementing Forensic Analysis" section later in this chapter.
Review Current Security Audit Settings

Organizations should review their current security audit and security event log file settings to provide a baseline for the changes recommended in this chapter. This review should obtain: Current effective security audit settings Level to which these settings apply (local computer, site, domain, or organizational unit)
Chapter 4: Design the Solution Current log file settings (size, behavior when maximum log size reached) Additional security audit settings that apply (for example, audit the use of backup and restore privileges)
21
You can use Appendix B, "Implement Group Policy Settings," as a job aid to identify which settings you need to record. For more information about security audit settings, see the Windows Server 2003 Security Guide at http://www.microsoft.com/downloads/details.aspx?FamilyId=8A2643C1-0685-4D89B655-521EA6C7B4DB.
Assess Administrator Roles and User Tasks

A key element to the implementation of effective security monitoring is to ensure that you know who your administrators are and what roles and responsibilities they hold. For example, most organizations include administrators in the Domain Admins group. Domain administrators can create new user accounts in the domain. However, organizational policies can specify that only the provisioning system can create new accounts. In this situation, if an administrator creates a user account, this action should attract immediate attention. Assessment of user tasks is simpler, because users have significantly less access to network resources than administrators do. For example, because users do not usually have access to the file systems of computers in the perimeter network, it is unlikely that you need to monitor these servers for user activity.
Review Organizational Policies and Procedures

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

Vulnerable computers are those that an external attacker is most likely to attempt to access first in an organization's network. For most attack scenarios, these computers are part of the perimeter network. You should perform a comprehensive review of all vulnerable computers to ensure that you have: Applied all service packs and security updates. Disabled unnecessary services and user accounts. Configured services to run under Local Service or Network Service accounts where possible. Checked services that run with user account credentials (particularly those that have administrative rights) to ensure that these services require user accounts. Applied high-security computer policy templates.
Note: This review process is not exclusive to vulnerable computers. Good security practice recommends that you apply these checks to all computers on the network. For more information about how to run services securely, see The Service and Service Accounts Security Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41311.
22
List High-Value Assets

Although an organization is likely to have already identified its high-value assets, it might need to formalize this as part of an organizational policy by documenting these assets and the protection for each asset. For example, a company might use access control lists (ACLs) and encryption to store financial records securely on NTFS file system partitions. However, organizational policy should identify these records as protected files that unauthorized users or administrators should not attempt to access, and Administrators and users should be aware of this restriction. The organization should then investigate any changes to the ACL on these protected files. Changes in ownership are particularly important, because ownership changes can indicate that an attacker attempted to access a file without proper authorization. Because ownership changes do not happen very often, they should be easy to detect.
Identify Sensitive or Suspicious Accounts

You should review all sensitive accounts to identify those accounts that require higher audit levels. These accounts include the default Administrator account, any members of the Enterprise, Schema, and Domain Admins groups, and any accounts that services use to log on. When you notice suspicious activity by an individual, your security policy requirements should require higher audit levels for that person. For more information about how to change audit levels for user accounts, see the "Enable Selective Auditing" section later in this chapter.
List Authorized Programs

Because attackers must run programs to discover information about the network, restrictions on which programs can run on your network significantly reduces the threat of external attacks. You should perform an audit of all authorized programs, and consider any unknown programs as suspicious. Microsoft Systems Management Server 2003 can carry out software audits for large enterprise environments. Note: You might need to make exceptions for certain computers, such as developer workstations, because the executable files that the developer creates are not on the approved list. A more secure approach is to require developers to use virtual computers that have no connectivity to the corporate network to develop and test programs.
Solution Architecture
The security monitoring and attack detection solution contains several components that coordinate to provide security warnings. These components include: Active Directory domain controllers Event correlation infrastructure Monitoring and analysis workstations Online storage database Backup media Short-term onsite archive storage Long-term offsite archive storage
Chapter 4: Design the Solution
23
Active Directory domain controllers are not a strict requirement, because you can configure security audit levels using local security settings. However, the solution requires Active Directory if you want to use Group Policy to help implement security audits.
How the Solution Works

The solution architecture components work in the following way: 1. The administrator uses Group Policy settings to apply the required changes to audit levels. For a list of recommended Group Policy settings, see Appendix B, "Implement Group Policy Settings." 2. Group Policy propagates these changes to the designated computers. 3. The administrator applies changes to the local security policy for computers that are not part of the domain, such as those in the perimeter network. 4. The security event logs collect events in accordance with the settings in Group Policy. 5. The event correlation system scans the security event logs at regular intervals and saves this information to a suitable database. 6. A security administrator can either analyze the information in the database directly or use utilities such as SysTrack 3 from Lakeside Software to identify suspicious activities. Implementation of security monitoring for forensic analysis requires the following additional actions: 1. The event correlation system extracts the relevant events at regular intervals and places them in the online database. 2. The backup system on the online database archives and removes obsolete records from the online database at predetermined intervals (typically daily). 3. The backup media stays in the short-term onsite storage for the specified time. 4. At regular intervals (typically weekly), a courier takes the old backup media to long-term offsite storage. 5. The administrator responsible for restore operations carries out trial restores on a monthly basis to check that the backups still function.
Enable Selective Auditing

New features in Windows Server 2003 with Service Pack 1 enable selective audit levels on user accounts. For example, you can audit logon and logoff activity for everyone and audit all activity for one specific user. Alternatively, you can audit all activity for everyone except one specific user account. Selective audit levels enable you to reduce the number of routine events that you must filter out or to track suspicious individuals. You can selectively audit user accounts only, not security or distribution groups. You can use the auditusr.exe command-line utility to implement selective audit levels. Both Windows Server 2003 with SP1 and Windows XP with SP2 have this utility. For more information about how to configure per-user audits, run auditusr.exe /? at a command prompt. Note: Per-user audits cannot exclude events for members of the built-in Administrators group.
24
Detect Policy Violations

Chapter 3, "Issues and Requirements," identifies that the greatest threats to a network are from internal users within an organization. Even institutions with the most rigorous recruitment and selection procedures cannot afford to neglect to monitor their most trusted internal users. This chapter includes the majority of internal threat scenarios, along with a discussion on how to detect these occurrences. Unintentional system or network configuration errors usually result from administrator actions. For example, consider an administrator who followed an approval process before implementation of a configuration change, and then used the correct administrator credentials to log on at a workstation that was visible to other users. In this example, the administrator did not attempt to hide his actions. Factors such as whether an administrator attempts to conceal his activity usually distinguish deliberate sabotage from accidental configuration errors. Note: Implementation of security monitoring is much more effective if you have already created and implemented a suitable change management process. Without the change management process in place, it is much more difficult to check that changes were made using the correct procedures, as there is nothing against which to check. Attack profiling for policy violations relies on identification of an event or sequence of events that can indicate a potential attack. You can use this information with your event correlation system to look for attack signatures. Detecting policy violations covers the following activities: Access resources by changing file permissions Access resources by password resets Create, change, or delete user accounts Place users into groups Attempt to use unauthorized accounts Log on interactively with service account credentials Run unauthorized programs Access unauthorized resources Damage authorized files (does not include corruption caused by disk errors) Introduce unauthorized operating systems Obtain other users' credentials Attempt to circumvent auditing Create or break trust relationships Make unauthorized changes to security policy
Access Resources by Changing File Permissions

Administrators can view files to which they have no read permissions by changing ownership of the file and then adding themselves to the read permissions list for the file. In Windows Server 2003 and later, they can disguise this action if they change ownership and permissions back to their original states. It is counterproductive to configure object access auditing on all filesany illicit activity would be lost in the sheer volume of events. However, security audit levels should be set
25
to check all access or changes to high-value files and the folders that contain them. ACL entries alone are not a suitable defense against unauthorized access. To thwart illegal activity effectively, you should identify the following factors for all highvalue files: Which object did the access attempt target? Which user requested the access? Is the user authorized to access that object? What type of access (read, write, list, and so on) did the user attempt? Was the event audited as a success or a failure? From which computer did the user attempt the access?
Because Event Viewer does not provide sufficient filter settings to identify this information, you must use EventComb MT or other third-party utilities to perform this analysis. The following table lists the audit events that changes to file permissions can cause. The audit category is Object Access. Table 4.1: File Permission Change Events Event IDs
560
Occurrence
Access granted to existing object
Comments
These events show where an object has successfully granted access to a request, such as list, read, create, and delete. Check Primary Logon ID, Client User Name, and Primary User Name fields to detect unauthorized attempts to change file permissions. Check Accesses field to identify the operation type. This event only shows that access was requested or grantedit does not mean that the access took place. The acting user is the Client User (if present); otherwise it is the Primary User. This event occurs on the first instance of an access type (list, read, create, and so on) to an object. To correlate with event 560, compare the Handle ID fields of the two events.
567
A permission associated with a handle used
Access Resources by Password Resets

Password resets should occur within an approved framework only. Properly configured security audit levels should record password resets in the security event logs and identify those resets that do not follow the correct procedures.
26
The following table lists the audit events that resets to passwords cause. The audit category is Account Management. Table 4.2: Password Reset Events Event IDs
627
Occurrence
Change Password Attempt
Comments
This event results from a password change request in which the user supplies the original password to the account. Compare Primary Account Name to Target Account Name to determine whether the account owner or someone else attempted to change the password. If Primary Account Name does not equal Target Account Name, someone other than the account owner tried to change the password. On computers that run Microsoft Windows Me or Windows NT, it is common to see Anonymous as the account that requests the change. This is because the user might not have been authenticated. However, the requestor had to supply the old password, so this is not a significant security risk. Records when a user or process resets an account password through an administrative interface such as Active Directory Users and Computers, rather than through a password change process. Only authorized people or processes should carry out this process, such as help desk or user self-service password reset. Records when someone attempts to change the Directory Services Restore Mode password on a domain controller. Check Workstation IP and Account Name and investigate immediately.
628
User Account Password Set or Reset
698
Change Directory Services Restore Mode Password
Create, Change, or Delete User Accounts

You should always follow an established process to create a new user account. In large organizations with automated provisioning systems, this process can involve multistep business logic processes that require managers to log on to a Web site to approve account creations for new hires. Even in small organizations, creation of a user account in Active Directory should result only from an official request. Every event that records creation of a user account should then correspond to account creation requests. An unreliable administrator can easily create a plausible user account for a nonexistent employee and then use that account for unauthorized access and malicious activity. You should also confirm that only a short interval exists between creation of a new user account and when that user logs on and changes her password. If a new user does not log on to the new account within a predetermined timeframe, the provisioning system should disable the account and the security officer should investigate the reason for the delay. To use security monitoring and attack detection to identify user account issues, you should configure queries that: Find irregular or unusual network account activities. Identify administrators who abuse privileges to create or modify accounts. Detect patterns of account activities that breach organizational security policies.
The following table lists the events that identify user account changes. All events belong to the Account Management audit category.
Chapter 4: Design the Solution Table 4.3: User Account Change Events Event IDs
624
27
Occurrence
Creating a user account
Comments
Only authorized people and processes should create network accounts. Examine the Primary User Name field to detect whether an authorized person or process created an account. This event also detects if administrators create accounts outside organizational policy guidelines. Only authorized people and processes should delete network accounts. Search for these events and examine the Primary Account Name field to detect if unauthorized people have deleted accounts. This event records changes made to security-related properties of user accounts that events 627-630 do not cover. Verify that Primary Account Name corresponds to an authorized person or process.
630
Deleting a user account
642 685
Changing a user account Changing an account name
Place Users into Groups

Good security practice advocates the principle of least privilege, which translates into giving users the minimum rights and permissions they need to do their jobs. Most user accounts should be members of the Domain Users group only, together with any organization-specific security groups. Placement of users into security groups, particularly users who have high privileges such as Domain, Schema, or Enterprise Admins, should occur within policy guidelines only, and should make use of established and approved accounts or processes. You should treat any other changes as suspicious and investigate further. Note: Distribution group membership does not provide access to network resources, because distribution groups are not security principals. However, membership of certain distribution groups can create other types of security issues. For example, placement of user accounts into the Vice-Presidents or Directors distribution group by mistake could cause users to receive e-mails that are inappropriate to their position.
28
The following table lists the events that identify group changes. All events belong to the Account Management audit category. Table 4.4: Group Membership Change Events Event IDs
631 to 634
Occurrence
Security Enabled Global Group Changes
Comments
Examine this event for groups that have global or broad access privileges, such as the Domain Admins group, to ensure that no changes occur outside organizational policy constraints. The group name is in the Target Account Name field. Examine this event for groups such as Administrators, Server Operators, and Backup Operators to ensure that no changes take place outside of policy constraints. The group name is in the Target Account Name field. These events indicate other changes to a group besides deletion, creation, or membership changes. You should examine these events for groups that have high privilege levels to make sure that no changes take place outside policy constraints. The group name is in the Target Account Name field. Examine for groups that have high privilege levels, such as Enterprise Admins or Schema Admins, to ensure that no changes take place outside policy constraints. The group name is in the Target Account Name field.
635 to 638
Security Enabled Local Group Changes Security Enabled Group Changes
639 641 668
659 to 662
Security Enabled Universal Group Changes
Attempt to Use Unauthorized Accounts

Promotion of the first Active Directory domain controller in a forest creates an administrator account that is a member of the Domain Admins and Enterprise Admins groups. This account requires particular protection because it is the only account for which the account lockout settings do not apply. Hence, even with an account lockout policy in place, this account is vulnerable to dictionary attacks. Security monitoring should identify any attempt to log on this administrator account, even if you have renamed it. For more information about elevation of security on administrative accounts, see The Administrator Accounts Security Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41315. Attempts to log on with disabled or expired accounts can indicate that a former employee, temporary worker, or contractor has tried to gain access to the network without current authorization. These events require immediate investigation. The following table lists the events that identify unauthorized account usage. The events belong to the Account Logon and Logon audit categories.
29
Table 4.5: Unauthorized Logon Events Event IDs

528/540
Occurrence
Logon success
Comments
Suspicious where Target Account Name equals the default administrator account. However, event 528 is a common event in typical operational usage. Check for attempts where Target Account Name equals Administrator or the renamed default administrator account. Check multiple logon failures that are below the account lockout threshold. Always investigate this event. Check Target Account Name value and Workstation Name. This event can signal attempted abuse by former internal users. Always investigate this event. Check Target Account Name value and Workstation Name. This event can signal attempted abuse by contractors or temporary internal users. This event appears whenever a new logon session gains privileges that could provide administrator access or tamper with the audit trail. Correlate with event 528 or event 540 by comparing the Logon ID field in the two events. Event 576 is a quick way to check if an account obtained administrator equivalence at logon time. This approach is easier than trying to calculate group membership.
529
Logon failure unknown user name or password Logon failure disabled account Logon failure expired account Special Privileges assigned to new logon
531
532
576
Log on Interactively with Service Account Credentials

When a service starts, that service must present logon credentials. In some cases, service accounts can require a domain account to connect and run services on remote computers. Some service accounts must run with administrator credentials or interact with the desktop. In Windows Server 2003 and later you can start some service accounts (such as the Alerter service) with the LocalService switch. Services that need network connectivity can use the Network Service account, NT AUTHORITY\NetworkService. You should check all services that require user accounts to make sure these accounts use strong passwords. Security monitoring should confirm that logon events for those accounts occur only when the relevant service starts. For more information about elevation of security on service accounts, see The Service and Service Accounts Security Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41311. The primary security concern develops when a service account logs on interactively instead of as a service. This event can occur only when an intruder has discovered the password to the service account and logs on with that account. If that service account has administrator privileges, the intruder has substantial power to disrupt usual network services. You should identify all resources that a service account can access. For example, a service account might occasionally have a good reason to require write permissions on a log file directory, but this is generally not the case. Service accounts should not have unexplained permissions to access high value data. You should closely scrutinize service
30
accounts that can interact with the desktop because these accounts provide greater opportunities for attackers. The following table lists the events that identify unauthorized use of service account credentials. The events belong to the Account Logon and Logon audit categories. Table 4.6: Logon with Service Account Credentials Events Event IDs
528
Occurrence
Logon Success console attack or Terminal Services
Comments
If an event log records Event 528 for a service account or for local system with logon type 2, an attack is in progress, the attacker has obtained the password to the service account and has logged on at the console. If an event log records logon type 10, an attacker has used Terminal Services to log on. In either case, you should investigate immediately. 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 that account from interactive logon. This event occurs when a service uses a named account to log on to a computer that runs Windows XP or later. Correlate this event with Events 672, 673, 528, and 592. This event should be a very rare occurrence because installation of services is not an everyday action. You should investigate all successes and failures for this event.
534
Logon failure logon type not allowed Process was assigned a primary token User attempts to install a service
600
601
Run Unauthorized Programs

Because administrators are trusted personnel, they can install and run programs. Organizations should create both a list of approved (and licensed) programs and a process for approval of new programs. In addition to tests on new programs in isolated network segments, administrators should not run any programs that the approved list does not include. Security audits on process tracking can identify unauthorized programs. However, process tracking generates multiple security log entries, so you must ensure that the number of events do not overwhelm the detection mechanism. The following table lists the events that identify the use of unauthorized programs. The events belong to the Process Tracking audit category.
31
Table 4.7: Run Unauthorized Programs Events Event IDs

592
Occurrence
Creating a new process Creating a scheduled job
Comments
Check Image File Name and User Name for new processes. All processes should be present on the authorized programs list. Check Target Name for authorization to run scheduled processes and check Task Time for event correlation with known task schedules.
602
Access Unauthorized Resources

This case requires the identification of audit failures on Event ID 560. The following table lists the events that result from access to unauthorized resources. The audit category is Object Access. Table 4.8: Access Attempts to Unauthorized Resources Events Event IDs
560
Occurrence
Access refused to existing object
Comments
Monitor for audit failures. Look at the Object Name field for the accessed resource. Correlate with Primary User Name and Primary Domain fields or the Client User Name and Client Domain fields. This event occurs when a user or program attempts to create a hard link to a file or object. After a user creates a hard link, the user can manipulate a file within that user's rights without creation of an audit trail.
568
Attempt made to create a hard link to an audited file
Damage Authorized Files

In this case, a user deliberately damages files to which they have access because they do not care about the consequences. This type of behavior is most common in cases where an organization has fired a user, but the administrator has not yet disabled that user's account. To reduce the opportunities for such deliberate sabotage requires well-documented and effective de-provisioning strategies that immediately disable the user's account and forcibly log off the user.
Introduce Unauthorized Operating Systems

Administrators and users can introduce unauthorized operating systems into a network through the following mechanisms: Home computers connected to the network CD-bootable operating systems Reinstallation of Windows XP or other Windows operating system Microsoft Virtual PC images
Unauthorized operating systems can cause significant problems, such as: Reduced protection from vulnerabilities because of unapplied security updates.
32
The Security Monitoring and Attack Detection Planning Guide Duplicated IP addresses, where the unauthorized operating system has the same address as another computer on the network. Increased vulnerability to viruses and other malicious software. Increased probability of file corruption. Increased help desk calls. Reduced productivity.
Organizational policies can specify whether users who work from remote locations can connect to the corporate network through remote access services or virtual private networking. For more information about how to ensure that remote computers comply with organizational security policies before they connect to the network, see Implementing Quarantine Services with Microsoft Virtual Private Network Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41307. Note: Some distributions of open source software are available on startup CDs. To start one of these operating systems, the user can insert the CD and restart the computer. Event log monitoring might not be able to detect this occurrence, because the open source software runs separately from Windows. However, log on attempts from user "root" in a homogenous environment could indicate the presence of unauthorized operating systems. Removal of CD drives from client computers can address this issue but is not always practicable. Users can also obtain a Windows XP installation CD and restart their computers to reinstall Windows XP. In this case, event log monitoring of other computers might detect attempted logon attempts from user "Administrator" that have an unidentified workgroup name or the default name of "Workgroup." Virtual PC images provide a complete emulation of the computer environment on a host computer. This emulation runs its own operating system with its own computer name, accounts, workgroup or domain memberships, and programs. The virtual PC image can start, run, and close down without affecting the host computer. The virtual PC can also request an IP address and access corporate network resources. Virtual PC images are a threat because they are unlikely to be secure, often with blank or easily guessable passwords. A user who runs an unsecured Virtual PC image can map drives to network shares or install components, such as Microsoft Internet Information Services (IIS), that possess inherent vulnerabilities that later service packs or security updates addressed. You should configure security monitoring to detect: Unrecognized user, computer, workgroup, or domain names. Duplicate or out-of-range IP addresses. Attempts to log on with the default Administrator account.
The following table lists the events that identify the use of unauthorized operating systems. The events belong to the Process Tracking audit category.
33
Table 4.9: Run Unauthorized Platform Events Event IDs

529
Occurrence
Logon failure unknown user name or password Creating a new process
Comments
Check for attempts where Target Account Name equals Administrator and Domain Name is unknown or Target Account Name equals root. Check Image File Name and User Name for new processes. All processes should be authorized programs.
592
Note: To ensure more reliable detection of rootkits, evaluate third-party products such as RootkitRevealer from Sysinternals or Blacklight from F-Secure. For more information about RootkitRevealer, see RootKitRevealer, at http://www.sysinternals.com/ntw2k/freeware/rootkitreveal.shtml. For more information about Blacklight, see the Revolutionary F-Secure BlackLight Technology press release at http://www.f-secure.com/news/items/news_2005030701.shtml.
Obtain Other Users' Credentials

One unintended consequence of good password policy (such as the requirement for a certain password length and enforcement of regular password changes) is that users write down their passwords. This situation is particularly noticeable in heterogeneous environments that have multiple identity stores that require users to log on several times. Note: For information about password management in heterogeneous environments, see the Identity and Access Management Series at http://www.microsoft.com/technet/security/topics/identity/idmanage/default.mspx Organizations must guard against users who write down their passwords and leave them out in plain sight, because an unauthorized person can then enter an office and easily find the user's logon credentials. Security monitoring should detect when a user logs on to a computer that the user does not typically use. Detection of this type of attack requires cross-correlation of logon successes with workstation names, and user access or authorization to those workstations. Note: Active Directory enables you to control the workstations onto which a user can log on. This feature requires support for network basic input/output system (NetBIOS) naming, for example through the Windows Internet Naming Service (WINS). Events for these occurrences are identical to those that Table 4.5, "Unauthorized Logon Events," lists.
Attempt to Circumvent Auditing

An attacker can use a variety of methods to elude discovery. For example, an attacker can change the security policy of a computer or domain so that the event logs do not record suspicious activities, or they can deliberately clear the security logs so that audit data is lost. Detection of attempts to cover tracks can be a challenge, because many of these events regularly occur as part of typical network operations.
34
The following table lists the events that identify events likely caused by attackers who are trying to hide evidence of security breaches. The events belong to multiple audit categories. Table 4.10: Circumvent Auditing Events Event IDs
512 513
Occurrence
Windows is starting up Windows is shutting down
Comments
Usually appears after Event 513. Investigate unexpected restarts. Usually appears before Event 512. On high-value computers, authorized personnel should restart computers in accordance with established policies. Investigate immediately when this event occurs on any server. This event can occur when too many security events overwhelm the event log buffer. Limit the number of events that you audit. This event can also occur if you configure the security log not to overwrite. You must monitor computers closely in areas where you must maintain high audit log levels. Security settings can cause some computers to shut down when the security logs fill up. Monitor event 516 on all computers where security is of concern. Administrators should not clear security event logs without authorization. Check Client User Name and Client Domain, then cross-correlate with authorized personnel. This action can mislead forensic investigation or provide an attacker with a false alibi. The process name is %windir %\system32\svchost.exe. Check Client User Name and Client Domain, then cross-correlate with authorized personnel. Windows is unable to write events to the security event log. You should investigate this event immediately if it occurs on high value computers. This action grants a new privilege to a user account. The event log records this action along with the user account Security Identifier (SID), not the user account name. This action removes a user account privilege. The event log records this action along with the user account SID, not the user account name. This event does not necessarily indicate a problem. However, an attacker can change audit policy as part of a computer system attack. You should monitor for this event on high value computers and domain controllers. A user was granted access to a system. Check User Name and Account Modified, particularly if access permission is interactive. This event might indicate that an attacker removed evidence of event 621, or is attempting to deny service to some other account(s).
516
Audit failure
517
Clearing the security event logs Changing the system time
520
521
Unable to log events A user account privilege was assigned A user account privilege was removed Changing audit policy
608
609
612
621
System Access was granted to an account System Access was removed from an account
622
35
Event IDs
643
Occurrence
Changing the domain security policy
Comments
This event indicates an attempt to modify password policy or other domain security policy settings. Check user name of subject and correlate with authorization.
Create or Break Trust Relationships

Trust relationships enable user accounts in one domain to access the network resources of another domain. Automatic two-way transitive trust relationships span all domains within the same Active Directory forest. You might need to manually create trust relationships in other situations, such as: Trusts that include Windows NT 4.0 domains. Shortcut trusts between domains. Trusts between domains in different forests on Windows 2000 Server. Inter-forest trusts on Windows Server 2003.
Creation of trust relationships is not a routine operation that only an enterprise administrator should perform through a clearly defined, approved, and established process. Similarly, an enterprise administrator should only break trust relationships after a careful analysis of the effect on the network and by reference to a clearly defined, approved, and established process. The following table lists the events that identify trust relationship actions. The events belong to the Policy Changes audit category. Table 4.11: Changing Trust Relationships Events Event IDs
610 611 620
Occurrence
Trust relationship with another domain was created, deleted, or modified
Comments
These events appear on the domain controller on which the trusted domain object is created. This event should generate an alert and immediate investigation. Check User Name of subject that carried out the trust operation.
Make Unauthorized Changes to Security Policy

Changes to approved security configurations should occur only within the framework of an agreed process and set of procedures. You should view any changes to security configurations outside of this framework either as an inadvertent administrator error or as intentional sabotage. Security configuration settings that should not change outside a defined framework include: Group Policy settings User account password policy User account lockout policy Audit policy Event log settings that apply to the security event log IPSec policy
36
The Security Monitoring and Attack Detection Planning Guide Wireless network (IEEE 802.11) policies Public key policies, especially those that apply to Encrypting File System (EFS) Software restriction policies User rights assignment User account password policy Security options
Security settings
This list represents minimum requirements, and most organizations will probably add more Group Policy settings. You need to configure security audits to identify both successful and unsuccessful attempts to change these settings, and all successful attempts must correlate to a user account that has the appropriate authorizations. The following table lists the events that identify policy changes (either Group Policy or local system policy). The events belong to the Policy Changes audit category. Table 4.12: Policy Change Events Event IDs
612 613 614 615 618
Occurrence
Changing audit policy Changing IPSec Policy Encrypted Data Recovery Policy
Comments
Identifies any change to audit policy. Correlate this event with changes that authorized personnel make to system policy. Monitor these events and investigate any occurrences that are outside system startups. If encrypted data recovery policy is in use, monitor for this event and investigate any occurrences outside specified policy.
For more information about Group Policy settings, see the Security Policy Settings topic at http://www.microsoft.com/resources/Documentation/windowsserv/2003/all/techref/enus/W2K3TR_sepol_set.asp.
Identify External Attacks

External attacks result from the actions of a person, or from the effects of malicious programs. These attacks can overlap; for example, a Trojan can gain access to a desktop computer that a person can then directly exploit. External attackers often attempt to breach security by privilege elevation until they gain administrative access to one or more computers. This approach generally starts with a successful intrusion through a user account that has limited privileges. The attacker then attempts to escalate privileges by creation of a process or service that runs in the System context. The attacker then uploads and executes software to explore the network further (for example, tools that intercept passwords or scan network packets). An attacker can also attempt to install a rootkit on a server. Rootkits are software components that take complete control of a computer and conceal their existence from standard diagnostic tools. Because rootkits operate at a very low hardware level, they can intercept and modify system calls. You cannot find a rootkit by searching for its executable, because the rootkit removes itself from the list of returned search results. Port scans do not reveal that the ports the rootkit uses are open, because the rootkit
37
prevents the scanner from detecting the open port. Hence, a major difficulty when dealing with rootkits is to ensure that none exist. Trojan applications are usually less difficult to detect than rootkits, although they can be more destructive. Trojans can provide similar remote control functionality as rootkits or can simply destroy data like a virus would. The main distinguishing feature of a Trojan is that, like its classical namesake, it attempts to trick the user to run it because it appears to be useful. Most malicious programs are not as flexible or reactive as a human-driven attack. However, you should pay particular attention to possible virus delivery mechanisms, such as e-mail, that circumvent the perimeter network. Strict e-mail attachment filters can help reduce this kind of attack. External attacks include the following categories: Attempt to compromise credentials Exploit vulnerabilities Install a rootkit or Trojan Trick a user into running a malicious program Access an unauthorized computer
Attempt to Compromise Credentials

Attackers use several approaches to obtain user account credentials. The most wellknown approach subjects a single user account to a dictionary attack. In this case, the attacker only knows one user account name. Another approach applies the same set of passwords to every user account contained in the directory service database. In this second case, the attacker probably has access to the organization's directory service. To detect this second attack, you need to be able to monitor account lockouts and multiple logon failures for a series of accounts, even if the total number of logon attempts is below the account lockout threshold. Password changes or resets are another way to gain a user's logon information. Because password change or reset operations generate the same event for both success and failure, an attacker can avoid detection by circumvention of the account lockout policy. A security monitoring solution must identify multiple password change or reset attempts, particularly those that occur outside the organizational framework for password change or reset. Password cycling is not an attack, but occurs when a user-initiated script that cycles through a number of password changes and allows the user to return to a previously used password. The number of password change attempts equals the password reuse threshold. This scenario appears as a rapid series of 627 events in which the Primary Account Name equals the Target Account Name. Implementation of a password minimum age causes these password change attempts to fail. The following table lists the events that result from attacks that target user credentials. However, these events can also occur as part of typical network operations, or when legitimate users forget their passwords.
38
Table 4.13: Attack Authentication Credentials Events Event IDs

529
Occurrence
Logon failure unknown user name or password
Comments
Check for attempts where Target Account Name equals Administrator or the renamed default administrator account. Check multiple logon failures that are below the account lockout threshold. This event can indicate when an unauthorized individual attempts to guess the local administrator password. Correlate Event 529 with Event 539 to identify a pattern of continuous account lockouts. A user attempted to log on by use of a logon type that is not allowed, such as network, interactive, batch, or service. Check Target Account Name, Workstation Name, and logon type. A user attempted to log on to an account that has already locked out. Correlate with Event 529 to detect a pattern of continued lockouts. This event occurs when the authentication package (usually Kerberos) detects an attempt to log on by replay of a user's credentials. Investigate immediately. Alternatively, this could be a sign of incorrect network configuration. Compare Primary Account Name against Target Account Name to determine if the account owner or someone else attempted an account password change. If Primary Account Name does not equal Target Account Name, this indicates that someone other than the account owner tried to change the password. Only authorized people or processes, such as help desk or user self-service password reset, should perform this task. Investigate this event immediately if this is not the case. A user account has locked out because the number of sequential failed logon attempts is greater than the account lockout limit. Correlate this event with Events 529, 675, 676 (Windows 2000 Server only), and 681. See also the entry in this table for Event 12294. Correlate with event 529 to find the additional reason for the logon failure. Reasons can include time synchronization or computer accounts that have not joined the domain correctly. This event indicates a possible brute force attack against the default Administrator account. Because this account does not lock out, the system event logs records SAM event 12294 instead. Investigate even a single occurrence of this event immediately, because this can also indicate the presence of an unauthorized operating system. Check Domain Name field for unknown domains.
534
Logon failure logon type not allowed Account Locked out Replay attack detected
539
553
627
Change Password Attempt
628
User Account Password Set or Reset User Account Automatically Locked
644
675
Preauthentication failed Account lockout attempt
12294
Exploit Vulnerabilities
Because vulnerabilities can exist on any computer, attackers attempt to exploit these vulnerabilities to penetrate an organization's network. The best protection against attackers who try to exploit vulnerabilities is to define an effective patch management
39
process that uses Microsoft Systems Management Server 2003 or Microsoft Software Update Services. For more information about patch management, see Patch Management Using Systems Management Server 2003 at http://www.microsoft.com/downloads/details.aspx?FamilyID=e9eab1bd-13e7-4e25-85c5ce2d191c3d63 and Patch Management Using Software Update Services at http://www.microsoft.com/downloads/details.aspx?familyid=38d7e99b-e780-43e5-aa84cdf6450d8f99 Security monitoring on the perimeter network is particularly important, because these computers are most readily available to an attacker. Unless a mechanism exists to detect that an attack is under way, an organization might not be aware that anything is amiss until an attacker compromises its network. Security monitoring on computers in the perimeter network must be able to detect a range of events. Typical occurrences for exploits of vulnerabilities include unauthorized access attempts and privileged identity usage. The following table covers some of the events that can identify possible attacks on computers. Note: See Table 4.13, "Attack Authentication Credentials Events," for additional events that might identify these kinds of attacks. Table 4.14: Identifying Events from Exploiting Vulnerabilities by Escalating Privileges Event IDs
528 538 576
Occurrence
Local Logon and Logoff Privileged Logon
Comments
Local logons should be very rare on perimeter computers. Correlate on Logon ID field. Investigate if unexpected values for User Account Name, Time, or Workstation name. In Windows Server 2003 with SP1 or later, this event indicates an administrator logon: a logon with enough privilege to tamper with the Trusted Computing Base (TCB) or take over the computer. For earlier versions of Windows, this event is only of interest if it contains a sensitive privilege such as SeSecurityPrivilege or SeDebugPrivilege.
Note: Versions of Windows earlier than Windows Server 2003 will list event 576 in the Privilege Use category. In Windows Server 2003 and later, the Logon category also lists this event. Hence configuration of audit settings for either category causes this event to appear.
Install a Rootkit or Trojan

Detection of the installation of a rootkit through security monitoring is difficult but not impossible. An unknown program that starts and stops in quick succession can indicate a rootkit. Once a rootkit starts, the operating system can no longer detect it. Hence the program appears to exit and does not generate any more events. Trojans are generally easier to identify than rootkits because they do not possess the stealth characteristics of a rootkit. Keystroke loggers (programs that attempt to record keystrokes) also reside in this category.
40
The following table lists the events that can result from installation of a rootkit. Table 4.15: Rootkit or Trojan Events Event IDs
592
Occurrence
Creating a new process
Comments
Check Image File Name and User Name for new processes. All processes should be authorized programs.
Trick a User into Running a Malicious Program

In this approach, the attacker attempts to circumvent the firewall and perimeter network to deliver an executable attachment to a user. E-mail is the most common delivery mechanism, but other connections, such as to an infected Web site, can achieve the same result. The attacker's first challenge is to get the user to run the program. If the user executes the program, program initiates in the user's security context. The program can then attempt to escalate privileges, for example to gain administrator equivalence or to obtain network access. You can configure process tracking to detect program startup attempts. If software restriction policies are in place to restrict the programs that a user can run, unauthorized program startup attempts create an audit failure event that you should investigate. You should be especially concerned if the following events occur: Processes spawned as LocalSystem. The processes that run as LocalSystem should be well defined, typically service executables such as services.exe. Event 592, where the event shows the presence of some other executable image, warrants further investigation. Processes spawned at unexpected times. If the computer does not use any scheduled batch process activities such as backup, CGI, or scripts, processes created at unusual times (such as at night) require further investigation. Look for occurrences of Event 592.
Table 4.15, "Rootkit or Trojan Events," lists the events that might occur when an attacker tricks a user to start a malicious application.
Access an Unauthorized Computer

Administrators increasingly use remote management facilities such as Terminal Services to connect to particular computers. You should therefore monitor these computers for interactive logon attempts and check the connection attempt for validity. Checks include: Identify logons that use service accounts Record attempts to access servers with unauthorized accounts Check attempts to access servers from unexpected geographical areas List attempts to access servers from an external IP address range
This type of monitoring is particularly important for high value assets, such as financial or customer records. You should place these resources onto a separate server and enable strict policies to govern who accesses these resources. Security monitoring should indicate who attempts to connect to these computers, and you should cross-reference this information to the list of allowed users. The following table lists the events that result from use of an unauthorized computer.
Chapter 4: Design the Solution Table 4.16: Unauthorized Computer Usage Events Event IDs
528
41
Occurrence
Successful Logon
Comments
Check Workstation Name and then check User Account Name. Check that Source Network Address is within the organization's IP address range. This event indicates an attempt to logon outside permitted times. Check User Account Name and Workstation Name.
530
Logon Failure time restrictions
Implement Forensic Analysis

Chapter 3, "Issues and Requirements," identifies how forensic analysis is fundamentally different from detection of policy violations and identification of external attackers. Forensic analysis uses many of the elements that this guide has already covered but focuses on the analysis and long-term storage of the resultant data. Most forensic investigations then proceed as types list all events for user A or list all events from computer B. Security monitoring for forensic analysis requires you to: Select which event types to archive. Calculate the expected numbers of events every day. Determine time limits for online, offline, and archive storage. Scale the online database to cope with the expected event numbers. Specify a backup system that can cope with the expected daily event load. Decide how to manage the archival system.
Three main factors determine the storage requirement: The number of events that you need to record The rate at which the target computers generate these events The time that you need to keep this information available online
Note: A domain controller with all audit categories enabled except for object access can produce in the region of 3,000 security events per hour. Storage of this information as a .CSV file from Event Comb MT results in a 1-MB file. Use of object access audits and process tracking can significantly increase these figures. The result of your analysis can tally up to unrealistic storage requirements. If this is the case, you must make a tradeoff among the number of monitored computers, the events that you monitor, and the duration that these events are stored online before relocation to offline storage. Appendix A, "Exclude Unnecessary Events," of this guide lists events that do not provide useful information. This appendix is intended to help you exclude events do not add any useful security information.
42
Summary
An effective security monitoring and attack detection system is an essential component in the maintenance of network integrity. To plan a monitoring and attack detection solution based on Windows security audits requires a comprehensive knowledge of the system's goals. It also requires a knowledgeable appreciation of the threat risks to which your network is susceptible and the attack signatures connected to each threat type. Windows Server 2003 provides the basic components for a security monitoring and attack detection system that uses security logging. Microsoft provides server-based components such as Microsoft Operations Manager and utilities such as Event Comb MT that can correlate event logs from multiple computers and provide analysis of security events. Microsoft Partners provide additional tools and utilities that enable rapid identification of attack profiles.
Appendix A: Exclude Unnecessary Events

The events that the following table lists are often excluded from security monitoring queries because of their frequency and because they do not provide any useful information. Note: There is some risk to the exclusion of any information from an audit, but you must evaluate this risk against the frequency of the events and the resultant load on the analysis agent. Table A.1: Reducing Storage Load by Removing Events Event Occurrence Comments IDs
538 User logoff This event does not necessarily indicate the time that the user stopped using the computer. For example, if the user turns the computer off without first logging off, or if the network connection to a share breaks, the computer might not record a logoff at all, or might record a logoff only when the computer notices that the connection is broken. Use Event 538, which confirms logoff instead. Always records a success. Normal where Authorization Manager is in use. Typical behavior.
551 562 571 573
User initiates logoff A handle to an object closed Client Context deleted by Authorization Manager. Process generates nonsystem audit event with Authorization Application Programming Interface (AuthZ API) Privilege service called, privileged object operation A handle to an object was duplicated Indirect access to an object was obtained Backup of data protection master key Recovery of data protection master key Event 624 where User equals System, followed by 642 where Target Account Name equals IUSR_machinename or
577 578 594 595 596 597 624 642
These high volume events typically do not contain enough information either to understand what happened or to act upon them. Typical behavior. Typical behavior. Occurs automatically every 90 days with default settings. Typical behavior. This event sequence indicates that an administrator has installed IIS on the computer.
44
Event IDs
Occurrence
IWAM_machinename and Caller User Name equals machinename$ .
Comments
624 630 642
User equals System and all three events have same time-stamp and New/Target Account Name equals HelpAssistant and Caller User Name equals DCname$ User equals ExchangeServername$ and Target Account Name is a Globally Unique Identifier (GUID) Caller User Name is any user and New Account Name is machinename$
This sequence is generated when an administrator installs Active Directory on a computer that runs Windows Server 2003.
624 or 642
This event occurs when an Exchange Server first comes online and automatically generates system mailboxes. A user in the domain has created or connected a new computer account in the domain. This event is acceptable if users have the right to join computers to a domain; otherwise you should investigate this event. These events result from the normal behavior of a computer that runs Terminal Services.
624
627
User equals System and Target Account Name equals TsInternetUser and Caller User Name is usually DCname$ Kerberos AS Ticket request
672
If you collect logon events 528 and 540 from all computers, event 672 might not contain any additional useful information, as it just records that a Kerberos TGT was granted. There must still be a service ticket granted (event 673) for any access to occur. If you collecting logon events 528 and 540 from all computers, event 680 might not contain any additional useful information, because it just records validation of the account credentials. A separate logon event records what the user accessed. Typical behavior. Not security related. These events indicate normal operation of interforest trusts. You should not confuse these with addition, deletion, or modification of the trust itself. No security implications.
680
Account Logon
697 768 769 770 771 832 to 841
Password policy checking API called Forest namespace collision Trusted forest information added, deleted or modified
Various Active Directory replication issues
Appendix B: Implement Group Policy Settings

To configure Group Policy security audit settings properly, apply the settings listed in the following table. This table includes additional settings that affect security monitoring and attack detection. Use this table to check the current settings in your environment. Table B.1: Group Policy Security Audit Settings Policy Path
Local Policies/ Audit Policy
Policy
Audit account logon events
Policy Setting and Comments

Enable audit success for all computers, as this event records who accessed the machine. Enable audit failure with caution as an attacker with network access but with no credentials could cause a denial of service (DoS) attack, as the computer consumes resources to generate these events. Enable audit success with caution as this setting can cause DoS attacks if computers shut down when audit logs are full. Correlate any administrator logons with any other suspicious entries. Enable both success and failure. Correlate all successful audit entries with administrator authorizations. Treat all failures as suspicious. 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. Enable audit success for all computers as this event records who accessed the computer. Enable audit failure with caution as an attacker with network access but with no credentials could still cause your computer to consume resources to generate these events. Use caution when enabling this setting as it can result in very high audit volume. Configure audit settings only on high-value folders through SACLs and audit only the minimum number of types of accesses that you are interested in. Audit writes only (and no read accesses) if your threat model allows this. Enable both success and failure event auditing. Crossreference any successes with administrator authorizations.
Local Policies/ Audit Policy Local Policies/ Audit Policy
Audit account management Audit directory service access
Audit logon events
Audit object access
Audit policy change
46
Policy Path
Local Policies/ Audit Policy Local Policies/ Audit Policy
Policy
Audit privilege use Audit process tracking

Treat all failures as suspicious. Do not enable auditing for privilege use due to the high volume of events that this generates. Do not enable this setting on Common Gateway Interface (CGI) Web servers, test computers, servers that run batch processes, or developer workstations. Enable this setting on vulnerable computers, and immediately act upon unexpected application activity, through physical isolation of the computer if necessary. This setting can cause events to fill up event logs. Enable both success and failure event auditing. This setting is assigned by default to Local System, Local Service, 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. Use this setting to restrict the administrators who can make changes to audit settings on files, folders, and registry settings. Consider creation of a security group for administrators who can change audit settings and remove the administrators group from the Local Security Policy settings. Only members of the new security group should be able to configure auditing. This setting adds SACLs to named system objects such as mutexes (mutually exclusive events), semaphores, and MS-DOS devices. Default settings on Windows Server 2003 do not enable this option. Do not enable this setting as it results in a very high volume of events. Backup and restore operations provide the opportunity to steal data that ACLs protect. Do not enable this setting as it results in a very high volume of events. Enable this setting after careful consideration on very highvalue computers only, as attackers can use this feature for DoS attacks.
Local Policies/ Audit Policy Local Policies/ User Rights Assignment
Audit system events Generate security audits
Local Policies/ User Rights Assignment
Manage auditing and security log
Local Policies/ Security Options
Audit: Audit the access of global system objects
Local Policies/ Security Options Local Policies/ Security Options
Audit: Audit the use of Backup and Restore privilege Audit: Shut down system immediately if unable to log security audits Maximum security log size
Event Log
The maximum security log size must be a multiple of 64 kB. The average event size is 0.5 kB. Recommended settings depend on projected event volumes and settings for retention of security logs. For high event volume environments, set the log file size as large as possible, even up to 250 MB. The total size of all event logs cannot exceed 300 MB, so do not attempt to exceed this figure. Windows Server 2003 enables this setting by default do not change.
Event Log
Prevent local guests group
Appendix B: Implement Group Policy Settings
47
Policy Path
Policy
from accessing security log
Event Log
Retain security log
Enable this setting only if you select the retention method "Overwrite events by days." If you use an event correlation system that polls for events, ensure that the number of days is at least three times the poll frequency to allow for failed poll cycles. For high security environments, enable the Do not overwrite events setting. In this case, establish procedures to empty and archive logs regularly, particularly if the computer shuts down when the security log fills up.
Event Log
Retention method for security log
Acknowledgements
The Microsoft Solutions for Security group (MSS) and the Security Center of Excellence (SCoE) would like to acknowledge and thank the team that produced the Security Monitoring and Attack Detection Planning guide. The following people were either directly responsible or made a substantial contribution to the writing, development, and testing of this solution.
Author
Anthony Steven, Content Master
Release Manager
Flicka Crandell
Testers
Ashish Java, Infosys Technologies Mehul Mediwala, Infosys Technologies Shreepriya Rajagopal, Infosys Technologies
Contributors
Tony Bailey Krishna Bhardwaj, Vidyatech Solutions Prabish Chandran, Vidyatech Solutions Amy Frampton Michael Glass, Volt Karl Grunwald Joanne Kennedy Karina Larson, Volt Chrissy Lewis, Siemens Bivin Pachatt, Vidyatech Solutions Tessa Porterfield Vivek Manohar Prabhu, Vidyatech Solutions Stacey Tsurusaki, Volt David Visintainer, Volt Vikas Walia, Vidyatech Solutions
Editors
Deborah Jay, Content Master Jennifer Kerns, Content Master Frank Manning, Volt
Program Managers
Neil Bufton, Content Master Chase Carpenter Alison Woolford, Content Master
Reviewers
David Anselmi Chase Carpenter Steve Clark Kurt Dillard Christine Duell, Valente Solutions Eric Fitzgerald Ted Hardy Greg Lenti Don McGowan Carrie Peiffer, Lakeside Software, Inc. Jed Pickle Bill Stackpole Angelica Trigona, GFI

The Security Monitoring and Attack Detection Planning Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Security Monitoring and Attack Detection Planning Guide

Uploaded by

Copyright:

Available Formats

The Security Monitoring and Attack Detection Planning Guide

2005 Microsoft Corporation. All rights reserved.

The Business Challenge