3. 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
4. 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
5. 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.
6. 2 The Security Monitoring and Attack Detection Planning Guide
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.
7. Chapter 1: Introduction 3
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.
8.
9. 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.
10. 6 The Security Monitoring and Attack Detection Planning Guide
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%System32config 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 Effect
Account logon
events
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.
Account
management
Audits the creation, modification, and deletion of user and group accounts,
in conjunction with password changes and resets.
Directory service
access
Audits access to objects in the Active Directory® directory service.
Logon events Audits attempts to log on to workstations and member servers.
Object access 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).
Policy change Audits any change to user rights assignment, audit, account, or trust
policies.
11. Chapter 2: Approaches to Security Monitoring 7
Category Effect
Privilege use Audits each instance that a user exercises a user right, such as changing
the system time.
Process tracking Audits application behavior such as program starts or terminations.
System events 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 ConfigurationWindows SettingsSecurity
SettingsLocal 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
12. 8 The Security Monitoring and Attack Detection Planning Guide
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=7af2e69c-
91f3-4e63-8629-b999adde0b9e.
The Windows Server 2003 Security Guide is available at
http://www.microsoft.com/downloads/details.aspx?FamilyId=8A2643C1-0685-4D89-
B655-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.
13. Chapter 2: Approaches to Security Monitoring 9
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, user-
defined 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.
14.
15. 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
16. 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.
17. 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.
18. 14 The Security Monitoring and Attack Detection Planning Guide
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.
19. Chapter 3: Issues and Requirements 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, becausethe 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.
20. 16 The Security Monitoring and Attack Detection Planning Guide
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
Solution Requirements
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 Defense-
in-Depth Guide at http://www.microsoft.com/technet/security/guidance/avdind_0.mspx.
21. Chapter 3: Issues and Requirements 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 Storage Limit Comments
Online storage (database) 21 days Provides rapid access to recent events
Offline storage (backup) 180 days Reasonable limit for most organizations
Regulatory environment 7 years
Intelligence agencies Permanent
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.
22. 18 The Security Monitoring and Attack Detection Planning Guide
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.
Solution Requirements
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.
23. 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
24. 20 The Security Monitoring and Attack Detection Planning Guide
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)
25. Chapter 4: Design the Solution 21
● 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)
You can use Appendix B, "Implement Group Policy Settings," as a job aid to identify
which settings you need to record. For more information about security audit settings, see
the Windows Server 2003 Security Guide at
http://www.microsoft.com/downloads/details.aspx?FamilyId=8A2643C1-0685-4D89-
B655-521EA6C7B4DB.
Assess Administrator Roles and User Tasks
A key element to the implementation of effective security monitoring is to ensure that you
know who your administrators are and what roles and responsibilities they hold. For
example, most organizations include administrators in the Domain Admins group.
Domain administrators can create new user accounts in the domain. However,
organizational policies can specify that only the provisioning system can create new
accounts. In this situation, if an administrator creates a user account, this action should
attract immediate attention.
Assessment of user tasks is simpler, because users have significantly less access to
network resources than administrators do. For example, because users do not usually
have access to the file systems of computers in the perimeter network, it is unlikely that
you need to monitor these servers for user activity.
Review Organizational Policies and Procedures
Reviews of organizational procedures correspond with the assessment of administrator
roles and responsibilities. For example, the process of adding users to groups requires
careful review. Departments should establish procedures for change requests and define
methods for implementation of these requests. Adding a user to a group outside of the
approved process requires investigation.
Identify Vulnerable Computers
Vulnerable computers are those that an external attacker is most likely to attempt to
access first in an organization's network. For most attack scenarios, these computers are
part of the perimeter network.
You should perform a comprehensive review of all vulnerable computers to ensure that
you have:
● 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.
26. 22 The Security Monitoring and Attack Detection Planning Guide
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
27. 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.
28. 24 The Security Monitoring and Attack Detection Planning Guide
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 files—any illicit activity
would be lost in the sheer volume of events. However, security audit levels should be set
29. Chapter 4: Design the Solution 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 high-
value 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
Occurrence Comments
560 Access granted
to existing object
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 granted—it does not
mean that the access took place. The acting user is the Client
User (if present); otherwise it is the Primary User.
567 A permission
associated with a
handle used
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.
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.
30. 26 The Security Monitoring and Attack Detection Planning Guide
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
Occurrence Comments
627 Change
Password
Attempt
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.
628 User Account
Password Set or
Reset
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.
698 Change Directory
Services Restore
Mode Password
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.
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.
31. Chapter 4: Design the Solution 27
Table 4.3: User Account Change Events
Event
IDs
Occurrence Comments
624 Creating a user
account
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.
630 Deleting a user
account
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.
642 Changing a user
account
This event records changes made to security-related properties of
user accounts that events 627-630 do not cover.
685 Changing an
account name
Verify that Primary Account Name corresponds to an authorized
person or process.
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.
32. 28 The Security Monitoring and Attack Detection Planning Guide
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
Occurrence Comments
631 to
634
Security Enabled
Global Group
Changes
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.
635 to
638
Security Enabled
Local Group
Changes
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.
639
641
668
Security Enabled
Group Changes
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.
659 to
662
Security Enabled
Universal Group
Changes
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.
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.
33. Chapter 4: Design the Solution 29
Table 4.5: Unauthorized Logon Events
Event
IDs
Occurrence Comments
528/540 Logon success Suspicious where Target Account Name equals the default
administrator account. However, event 528 is a common
event in typical operational usage.
529 Logon failure —
unknown user
name or password
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.
531 Logon failure —
disabled account
Always investigate this event. Check Target Account Name
value and Workstation Name. This event can signal
attempted abuse by former internal users.
532 Logon failure—
expired account
Always investigate this event. Check Target Account Name
value and Workstation Name. This event can signal
attempted abuse by contractors or temporary internal users.
576 Special Privileges
assigned to new
logon
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.
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 AUTHORITYNetworkService. 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
34. 30 The Security Monitoring and Attack Detection Planning Guide
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
Occurrence Comments
528 Logon Success –
console attack or
Terminal Services
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.
534 Logon failure—
logon type not
allowed
Check Target Account Name, Workstation Name, and
logon type. This event indicates a failed attempt to log on
interactively with service account credentials when Group
Policy settings prevent that account from interactive logon.
600 Process was
assigned a primary
token
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.
601 User attempts to
install a service
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.
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.
35. Chapter 4: Design the Solution 31
Table 4.7: Run Unauthorized Programs Events
Event
IDs
Occurrence Comments
592 Creating a new
process
Check Image File Name and User Name for new
processes. All processes should be present on the
authorized programs list.
602 Creating a
scheduled job
Check Target Name for authorization to run scheduled
processes and check Task Time for event correlation with
known task schedules.
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
Occurrence Comments
560 Access refused to
existing object
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.
568 Attempt made to
create a hard link to
an audited file
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.
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.
36. 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.
37. Chapter 4: Design the Solution 33
Table 4.9: Run Unauthorized Platform Events
Event
IDs
Occurrence Comments
529 Logon failure —
unknown user
name or password
Check for attempts where Target Account Name equals
Administrator and Domain Name is unknown or Target
Account Name equals root.
592 Creating a new
process
Check Image File Name and User Name for new
processes. All processes should be authorized programs.
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.
38. 34 The Security Monitoring and Attack Detection Planning Guide
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
Occurrence Comments
512 Windows is starting
up
Usually appears after Event 513. Investigate unexpected
restarts.
513 Windows is
shutting down
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.
516 Audit failure 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.
517 Clearing the
security event logs
Administrators should not clear security event logs without
authorization. Check Client User Name and Client Domain,
then cross-correlate with authorized personnel.
520 Changing the
system time
This action can mislead forensic investigation or provide an
attacker with a false alibi. The process name is %windir
%system32svchost.exe. Check Client User Name and
Client Domain, then cross-correlate with authorized
personnel.
521 Unable to log
events
Windows is unable to write events to the security event log.
You should investigate this event immediately if it occurs on
high value computers.
608 A user account
privilege was
assigned
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.
609 A user account
privilege was
removed
This action removes a user account privilege. The event log
records this action along with the user account SID, not the
user account name.
612 Changing audit
policy
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.
621 System Access
was granted to an
account
A user was granted access to a system. Check User Name
and Account Modified, particularly if access permission is
interactive.
622 System Access
was removed from
an account
This event might indicate that an attacker removed evidence
of event 621, or is attempting to deny service to some other
account(s).
39. Chapter 4: Design the Solution 35
Event
IDs
Occurrence Comments
643 Changing the
domain security
policy
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
Occurrence Comments
610
611
620
Trust relationship
with another
domain was
created, deleted, or
modified
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
40. 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
● Security settings
● User rights assignment
● User account password policy
● Security options
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
Occurrence Comments
612 Changing audit
policy
Identifies any change to audit policy. Correlate this event with
changes that authorized personnel make to system policy.
613
614
615
Changing IPSec
Policy
Monitor these events and investigate any occurrences that are
outside system startups.
618 Encrypted Data
Recovery Policy
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/en-
us/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
41. Chapter 4: Design the Solution 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 well-
known approach subjects a single user account to a dictionary attack. In this case, the
attacker only knows one user account name. Another approach applies the same set of
passwords to every user account contained in the directory service database. In this
second case, the attacker probably has access to the organization's directory service. To
detect this second attack, you need to be able to monitor account lockouts and multiple
logon failures for a series of accounts, even if the total number of logon attempts is below
the account lockout threshold.
Password changes or resets are another way to gain a user's logon information. Because
password change or reset operations generate the same event for both success and
failure, an attacker can avoid detection by circumvention of the account lockout policy. A
security monitoring solution must identify multiple password change or reset attempts,
particularly those that occur outside the organizational framework for password change or
reset.
Password cycling is not an attack, but occurs when a user-initiated script that cycles
through a number of password changes and allows the user to return to a previously
used password. The number of password change attempts equals the password reuse
threshold. This scenario appears as a rapid series of 627 events in which the Primary
Account Name equals the Target Account Name. Implementation of a password
minimum age causes these password change attempts to fail.
The following table lists the events that result from attacks that target user credentials.
However, these events can also occur as part of typical network operations, or when
legitimate users forget their passwords.
