Windows 2000 Server Security Solution Microsoft Solutions for Security

Windows 2000 Server Security Solution Microsoft Solutions for Security
Microsoft Solutions for
Security
Windows 2000 Server
Security Solution
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the
example companies, organizations, products, domain names, e – mail addresses, logos, people, places and events depicted herein are fictitious, and
no association with any real company, organization, product, domain name, e – mail address, logo, person, place or event is intended or should be
inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this
document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document.
Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
© 2003 Microsoft Corporation. All rights reserved.
Microsoft and Visual Basic are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Table of Contents
Chapter 1: Introduction to Securing Windows 2000 Server............................................................. 1
Chapter Outlines .......................................................................................................................... 3
Audience....................................................................................................................................... 7
The Securing Windows 2000 Server Solution Scenario .............................................................. 8
Style Conventions ...................................................................................................................... 11
Summary .................................................................................................................................... 12
Chapter 2: Defining the Security Landscape ................................................................................. 13
Security Risk Management Components................................................................................... 14
Summary .................................................................................................................................... 28
Chapter 3: Understanding the Security Risk Management Discipline ........................................... 29
Security Risk Management and Security Framework Practices ................................................ 30
Security Risk Management Framework ..................................................................................... 34
Security Risk Management Discipline........................................................................................ 45
Security Risk Tracking, Planning, Scheduling, and Reporting................................................... 59
Security Risk Remediation Development................................................................................... 65
Security Remediation Testing .................................................................................................... 67
Capturing Security Knowledge ................................................................................................... 68
Summary .................................................................................................................................... 71
Chapter 4: Applying the Security Risk Management Discipline..................................................... 73
Scenario Overview ..................................................................................................................... 74
Identifying Security Risks ........................................................................................................... 78
Analyzing and Prioritizing Security Risks ................................................................................... 98
Summary .................................................................................................................................. 103
Chapter 5: Securing the Domain Infrastructure ........................................................................... 105
Active Directory Design ............................................................................................................ 106
OU Design to Support Security ................................................................................................ 109
Domain Policy .......................................................................................................................... 118
Summary .................................................................................................................................. 132
Chapter 6: Hardening the Base Windows 2000 Server ............................................................... 133
Windows 2000 Server Baseline Policy..................................................................................... 135
Additional Member Server Hardening Procedures .................................................................. 186
Summary .................................................................................................................................. 196
Chapter 7: Hardening Specific Server Roles ............................................................................... 199
Active Directory Domain Controller Role.................................................................................. 201
Infrastructure Server Role ........................................................................................................ 233
File and Print Server Role ........................................................................................................ 241
IIS Server Role ......................................................................................................................... 247
Summary .................................................................................................................................. 272
Chapter 8: Patch Management .................................................................................................... 275
Terminology.............................................................................................................................. 276
Patch Management in Your Organization ................................................................................ 277
Patch Management Process .................................................................................................... 280
Summary .................................................................................................................................. 298
Chapter 9: Auditing and Intrusion Detection ................................................................................ 301
Auditing..................................................................................................................................... 302
Monitoring for Intrusion and Security Events ........................................................................... 322
Summary .................................................................................................................................. 334
Chapter 10: Responding to Incidents .......................................................................................... 335
Minimizing the Number and Severity of Security Incidents...................................................... 336
Defining an Incident Response Plan ........................................................................................ 341
Scenario — Contoso Incident Handling .................................................................................... 348
Summary .................................................................................................................................. 352
Chapter 11: Conclusion ............................................................................................................... 353
Vulnerabilities Identified in the Contoso Environment.............................................................. 354
Summary .................................................................................................................................. 358
Appendix A: Purpose of Windows 2000 Services........................................................................ 359
Appendix B: Registry Access Control Changes........................................................................... 373
Appendix C: Disabling NetBIOS on Servers in Untrusted Networks ........................................... 379
Appendix D: Configuring Digital Certificates on Domain Controllers........................................... 381
Background .............................................................................................................................. 382
Installing and Configuring Infrastructure for Domain Controller Certificates ............................ 384
Testing Digital Certificates for LDAP or SMTP......................................................................... 386
Requirements for a Domain Controller Certificate ................................................................... 389
More Information ...................................................................................................................... 390
1
Introduction to Securing
Windows 2000 Server
Welcome to the Securing Microsoft® Windows® 2000 Server solution guide. This guide
is designed to inform you of the best information and analysis tools available to assess
security risks specific to Windows 2000 Servers in your environment. The guide then
provides detailed guidance on building in enhanced security settings and features
wherever possible in your Windows 2000 Servers to mitigate the risks that you have
identified. Finally, detailed instructions on how to keep your servers secure are provided.
If you are a consultant, designer, or systems engineer involved in a Windows 2000
Server environment, this guide has been designed with you in mind.
The guidance has been reviewed and approved by Microsoft engineering teams,
consultants, and support engineers, and by customers and partners. It is:
●
Proven – Based on field experience
●
Authoritative – Offers the best advice available
●
Accurate – Technically validated and tested
●
Actionable – Provides the steps to success
●
Relevant – Addresses a real-world problem
Rather than discuss all of the different approaches that you could use to secure the
Windows 2000 Servers in your organization, and in order to best illustrate the
considerations, a fictitious company with a very real technical scenario is followed. It
represents a significant percentage of Windows 2000 Server deployments. Working with
consultants and systems engineers who have implemented Windows 2000 Server in a
variety of environments establishes the latest best practices to secure these servers.
Chapters 2 through 10 include step-by-step security procedures to provide you with a list
of tasks to perform to move your Windows 2000 Servers from where they are to where
you want them to be. If you want more in-depth discussion of the concepts behind this
material, refer to resources such as the Microsoft® Windows® 2000 Resource and
Security Resource Kits, or Microsoft® TechNet.
1
Whatever your environment, you are strongly advised to take security seriously. Many
organizations make the mistake of underestimating the value of their information
technology (IT) environment, generally because they exclude substantial indirect costs. If
an attack on the servers in your environment is severe enough, it could greatly damage
the entire organization. For example, an attack in which your corporate Web site is
brought down that causes a major loss of revenue or customer confidence might lead to
the collapse of your corporation’s profitability. When evaluating security costs, you should
include the indirect costs associated with any attack, as well as the costs of lost IT
functionality.
Vulnerability, risk, and exposure analysis with regard to security informs you of the
tradeoffs between security and usability that all computer systems are subject to in a
networked environment. This guide will show you how to identify the risks inherent in a
networked environment, help you to determine the level of security appropriate for your
environment, and provide you with the steps necessary to achieve that level of security.
Although targeted at the enterprise customer, much of this guide is appropriate for
organizations of any size.
The fictional customer and technical implementation may not mirror your own, but by
using the Security Risk Management Discipline (SRMD), you will identify any common
vulnerabilities and risks, as well as the ones unique into your environment. These can
then be assessed and the mitigation steps applied to be successful in securing your
servers.
To get the most value out of this material, you will need to read the entire guide. The
team that produced this guide hopes that you will find the material covered in it useful,
informative, and interesting.
2
Chapter Outlines
The Securing Windows 2000 Server solution guide consists of 11 chapters. Each chapter
builds on the end-to-end solution process required to secure Windows 2000 Servers in
your environment.
The chapters in the solutions guide align with the IT Life Cycle, which contains industry
standard proven practices as indicated in Figure 1.1, below. The Microsoft Solutions
Framework (MSF), Microsoft Operations Framework (MOF), and the Security Solution
Methodology are all discussed in the Securing Windows 2000 Services Delivery Guide
available separately from this one.
Figure 1.1
The high-level security fundamentals mapped to the Solution Guide chapters
3
Chapter 1: Introduction to Securing Windows 2000 Server
This chapter introduces the Securing Windows 2000 Server guide. It includes a brief
overview of each of the other chapters.
Chapter 2: Defining the Security Landscape
This chapter focuses on defining security components that need to be understood to
perform a security analysis of your organization. General guidance on how to perform a
preliminary asset analysis for your organization is offered. The relationship between
threats, exposures, vulnerabilities, and countermeasures is also explained.
Chapter 3: Understanding the Security Risk Management
Discipline
Proven practices are drawn upon in this chapter, from security analysis methodologies in
use today that leverage the MSF and MOF. MSF offers guidance in the planning,
building, stabilizing, and deploying phases of the project life cycle in the areas of
enterprise architecture and infrastructure deployment. MOF provides advice on how to
develop or improve management systems for IT operations. The SRMD also is defined in
detail in this chapter, which provides learning that can be applied to assess and
determine the level of risk in your own environment.
Chapter 4: Applying the Security Risk Management
Discipline
The SRMD is put into practice throughout this chapter to determine which threats and
vulnerabilities have the most potential impact on a particular organization. Because every
company has different business requirements, it is impossible to create one list of
vulnerabilities that will have the same impact on every environment. However, this
chapter will apply this process to a generic scenario in which a fictitious company is used
to illustrate how a set of common implementation decisions, and, therefore, a significant
number of real-world vulnerabilities, should be determined. At the conclusion of this
chapter, the specific risks addressed are fully defined, described, and analyzed.
Chapter 5: Securing the Domain Infrastructure
Determining the criteria on which to base decisions that impact the organization at a
domain level is the focus of this chapter. A high level overview of the Microsoft® Active
Directory® service design, the organizational unit (OU) design, and domain policy is
provided. In addition, specific domain policies that are implemented at Contoso, the
fictional customer scenario used in this guide, are discussed in detail.
Chapter 6: Hardening the Base Windows 2000 Server
The base settings applied to the member servers at Contoso are explained in this
chapter. Group Policy was used to apply as many of the changes to the default Windows
2000 Server configuration as possible. For the member servers in this scenario, the
Group Policy settings described are stored in the security template, MSS Baseline.inf.
This template was imported into the Member Server Baseline Policy group policy, which
is linked to the Member Server OU.
4
Chapter 7: Hardening Specific Server Roles
The domain controllers, file servers, network infrastructure servers, and Web servers in
any organization require different settings to maximize their security. This chapter
focuses on the domain controllers and the other primary member server roles to show the
steps that you should take to ensure that each of these roles is as secure as possible.
Note: This guide assumes that servers perform specific defined roles. If your servers
do not match these roles, or if you have multipurpose servers, you should use the
settings defined here as a guideline for creating your own security templates to give
you the functionality that you require. However, bear in mind that the more functions
that each of your individual servers performs, the more vulnerable your servers are to
attack.
Chapter 8: Patch Management
One of the main ways to guard against attack is to ensure that your environment is kept
up to date with all the necessary security patches. Patches may be required at the server
and client levels. This chapter shows you how to ensure that you find out about new
patches in a timely manner, implement them quickly and reliably throughout your
organization, and monitor to ensure that they are deployed everywhere.
Chapter 9: Auditing and Intrusion Detection
In any secure environment, you should actively monitor for intrusion and attack. It would
be counterproductive to put secure systems in place and then not perform any auditing,
based on the assumption that you will not be attacked. Additionally, not all attacks are
obvious. Sometimes the more subtle attacks are more dangerous, because they go
unnoticed, and it is difficult to tell what changes have been made. This chapter shows
how to audit your environment to give you the best chances of spotting attacks, and it
looks at intrusion detection systems — software specifically designed to detect behavior
that indicates an attack is occurring.
Chapter 10: Responding to Incidents
No matter how secure your environment, the risk of being attacked remains. Any sensible
security strategy must include details on how your organization would respond to different
types of attack. This chapter will cover the best ways to respond to different types of
attack and includes the steps that you should take to report the incidents effectively. It
also includes a case study to illustrate a typical response to an incident.
5
Chapter 11: Conclusion
Chapter 11 closes out the solution guide by providing a brief overview of everything that
has been discussed.
Appendices, Templates, and Other Tools
A collection of security templates, scripts, and additional tools are included with this guide
to make it easier for your organization to evaluate, test, and implement the
countermeasures recommended in this guide. The security templates are text files that
can be imported into domain – based group policies, or applied locally using the Security
Configuration and Analysis snap – in. These procedures are detailed in Chapter 6,
"Hardening the Base Windows 2000 Server." The scripts included with this guide
implement IPSec packet filters using the IPSecPol.exe command line tool and test scripts
used in testing the recommended countermeasures. These tools and templates are
included in the self-extracting WinZip archive that contains this guide. When you
extracted the files from this archive the following folder structure is created in the location
you specified:
●
\Securing Windows 2000 Server — contains the Portable Document Format (PDF)
file document that you are currently reading, as well as the Test Guide, Delivery
Guide, and Support Guide associated with this material.
●
\Securing Windows 2000 Server\Tools and Templates — contains subdirectories for
any items that may accompany this guide.
●
\Securing Windows 2000 Server\Tools and Templates\Security Guide\Security
Templates — contains the security templates and other tools discussed in the
guide.
●
\Securing Windows 2000 Server\Tools and Templates\Security Guide\Sample
Scripts — contains sample IPSec filter scripts and patch management scripts.
●
\Securing Windows 2000 Server\Tools and Templates\Test Guide— contains tools
related to the test guide.
●
\Securing Windows 2000 Server\Tools and Templates\Delivery Guide— contains
tools related to the delivery guide.
Warning: The security templates in this guide are designed to increase security in your
environment. It is quite possible that by installing the templates included with this
guide, some functionality in the environment of your organization may be lost. This
could include the failure of mission critical applications.
It is therefore essential to thoroughly test these templates before deployed them in a
production environment. Back up each domain controller and server in your
environment prior to applying any new security settings. Ensure the system state is
included in the backup to enable registry settings or Active Directory objects to be
restored.
6
Audience
This guide is primarily intended for consultants, security specialists, systems architects,
and IT professionals who are responsible for the planning stages of application or
infrastructure development and deployment across multiple projects. These roles include
the following common job descriptions:
●
Architects and planners who are responsible for driving the architecture efforts for
their organizations
●
IT security specialists who are focused purely on providing security across
platforms within an organization
●
Business analysts and business decision-makers (BDMs) who have critical
business objectives and requirements that need IT support
●
Consultants, both Microsoft Services and partners, who need knowledge transfer
tools for enterprise customers and partners
Of course, other readers involved in planning, designing, and implementing an
infrastructure project will find that this guide contains relevant and useful information.
There are many roles in infrastructure development, and each person involved in the
project requires different types and levels of information.
For information about the roles involved in a software development project within the
MSF Team Model, see: http://www.microsoft.com/business/services/mcsmsf.asp.
7
The Securing Windows 2000 Server Solution
Scenario
In order to provide prescriptive guidance for Securing Windows 2000 Server, this solution
uses a fictitious organization to provide the context around which the solution is
implemented. Using a fictitious company, security trade-offs can be presented in light of
the business requirements and technical possibilities of the scenario.
Contoso, Ltd
The Securing Windows 2000 Server solution revolves around a fictitious marketing
research company named Contoso, Ltd. Contoso has two offices: a headquarters located
in Atlanta, Georgia, and a second office located in Boston, Massachusetts. Contoso is a
fairly large enterprise, with several thousand employees who utilize computing resources.
Contoso reported revenue of $829 million last year.
The company's server platform has been completely upgraded to Windows 2000 Server,
but its client deployment remains in a mixed state. The company currently has a
combination of Microsoft® Windows 98 SR2, Microsoft® Windows NT® Workstation
version 4.0, Microsoft® Windows® 2000 Professional, and Microsoft® Windows® XP
Professional.
Network Design
Contoso has two data centers connected with two T1 lines. Each office has a portion of
the engineering and operations staff providing network infrastructure services. All Web
servers are located at the main data center in Atlanta.
Each location has 100-megabits per second (Mbps) connections to all servers and 10Mbps connections to all client workstations. The servers are segmented on their own
subnet. Client computers are on a separate subnet. All computers have access to the
Internet through a connection in Atlanta.
Active Directory Design
Contoso has deployed a single Windows 2000 Server forest with an empty root and a
single child domain. An empty root domain is a separate domain that houses only the
computer accounts for the domain controllers in that domain and the default user
accounts.
Contoso has also divided its network into two Active Directory sites — Atlanta and Boston.
The flexible single master operations (FSMO) roles are divided between these sites.
Each site has domain controllers that are running Active Directory integrated with Domain
Name System (DNS), Dynamic Host Configuration Protocol (DHCP), and File and Print
servers. Atlanta hosts the Windows Internet Naming Service (WINS) servers for the
entire organization. Most of the organization's server computers running Internet
Information Services (IIS) reside in Atlanta; however, some smaller department Web
servers are located in Boston.
8
Figure 1.2
The service layout for Contoso Ltd.
The figure above shows the server-based distribution of services within Contoso, but it
does not accurately represent the total number of servers within the organization.
Business Requirements
As mentioned, Contoso is a marketing research company. Marketing research is an
industry that focuses on planning and controlling the sum of activities involved in directing
a flow of goods and services from producers to consumers, including such activities as
packaging, pricing, promotion, and physical distribution to meet the needs of a particular
market.
To find out what the market's needs are, market researchers must learn as much as they
can about their customers. To help facilitate this, Contoso provides market researchers
with detailed information about their target markets.
9
The majority of Contoso's marketing information is housed in IIS servers located within
the organization. Contoso's marketing research personnel utilize the internal marketing
research Web servers when gathering detailed information for their customers. Some of
this information is also located on file shares, but the information on these file shares is
only a subset of the information available on the intranet servers.
Contoso wants to ensure that its internal data is secure and stays secure. Marketing
research is a very competitive field, and the company's research data is its primary
competitive advantage over other companies in the same field. Because of this,
maintaining a high level of security for the company's marketing research data is the top
priority of the organization.
A separate project has been started to address the security of Contoso's external
connectivity and its perimeter network. These concerns are out of scope for this project.
10
Style Conventions
This guide uses the following style conventions and terminology.
Element
Meaning
Bold font
Characters that are typed exactly as shown, including commands and
switches. User interface elements in text that is prescriptive are also
bold.
Italic font
Placeholder for variables where specific values are supplied. For
example, Filename.ext could refer to any valid file name for the first
case in question.
Monospace font
Code samples.
%SystemRoot%
The folder in which the Windows 2000 operating system is installed.
Note
Alerts the reader to supplementary information.
Important
Alerts the reader to supplementary information that is essential to the
completion of the task.
11
Summary
This chapter provided an overview of the primary factors involved to secure Windows
2000 Server that are considered in greater depth in the chapters of the guide. It also
introduced a typical enterprise organization that is referred to throughout the chapter
series to illustrate the best practices and procedures used to secure Windows 2000
Servers. Now that you have an understanding of how this guide is organized, you can
decide whether to read it from beginning to end, or to select only those sections of most
interest to you. However, it is important to remember that effective, successful, security
operations require making improvements in all of the areas covered in this guide, not just
a few. For this reason, it is highly recommended to read the entire guide to take
advantage of all of the information on securing Windows 2000 Servers in your
organization that the guide has to offer.
12
2
Defining the Security
Landscape
This chapter focuses on defining security components that need to be understood to
perform a security analysis of your organization. General guidance on how to perform a
preliminary asset analysis for your organization is offered. The relationship between
threats, exposures, vulnerabilities and countermeasures is also explained.
13
Security Risk Management Components
The Need for a Strategic Security Program
Security is a balance between maintaining the ease of use of resources in your
organization and controlling access to those resources. Putting together a security
program that restricts both users and attacks can be time consuming and costly. A
security program that pushes the balance too far toward control may disgruntle users with
policies that limit them from effectively doing their work.
Conversely, a security program that is too lax may create a complacent attitude among
users toward security in the workplace and may give attackers more opportunities.
Communication on the importance of security in the organization is essential to avoiding
other potential political issues. If security charters, policies, and plans are implemented
"half-way" there may be issues in the future. When quality is a key attribute for
information technology (IT) projects in which a "zero-defect" mindset is a fundamental
principle, this same principle should be applied to ensure a high level of security in your
organization.
A critical success factor for the establishment of a secure infrastructure involves
developing an effective security risk management process. Through effective risk
identification, assessment, management, mitigation, and execution, as well as
contingency plans, you can help reduce the probability that a given risk will surface, and
you can minimize the impact or consequence should the security risk be realized.
Performing a security-specific risk analysis activity will flush out critical security issues
that require attention and a course of action. A security risk is realized when a threat
takes advantage of a vulnerability that in turn causes some harm to an asset in your
organization. The creation of mitigation and contingency plans allows you to create
security policies and procedures to provide a proactive and reactive approach to security
risk management.
Implementing, executing, and continually optimizing your organization's security plans is
becoming more critical as technology evolves and new methods to exploit the technology
are found. Security programs must change over time because they require constant
attention to monitor their effectiveness and determine when new policies and procedures
must be put in place. Security programs should also account for potential legal
ramifications through Incident Response Plans tailored to the corporate environment, as
the prospect of getting sued over a security failure could present a serious problem.
Determining the costs involved is more easily accomplished by performing a proper and
well-defined asset valuation. The investment cost of mitigation also must be weighed
against the potential impact of what may happen to the asset if it is harmed or
compromised. Reaching this goal is defined in Chapter 3, "Understanding the Security
Risk Management Discipline," in which this discipline is used to help your organization
strike the appropriate balance between cost and risk.
If the loss of sensitive company data from your organization will seriously impact
productivity or revenue, then the investment required to ensure its protection may be
significant. If the loss of that data will not be detrimental to the organization, then such
data needs minimal protection, and the investment to protect it will be less.
14
The eight basic considerations that need to be addressed in the security risk assessment
process are:
●
Security requirements for assets. Define all the components of your
organization’s infrastructure that require any level of protection, including systems,
networks, applications, and business data. Asset valuation needs to be assessed
both in a quantitative and qualitative fashion to properly plan for countermeasures
or safeguards.
●
Threat analysis. Create a list of known exploits and determine the likelihood of a
potential threat arising from each one. An exploit is a means that may be utilized
by a threat to make use of a vulnerability in your environment. A compiled list of
the top threat agents in your environment is required to perform a proper threat
analysis. A threat is any potential danger to information or the systems in your
environment. A threat agent is the person or process attacking the network through
a vulnerable port on the firewall, or a process used to access data in a way that
violates your security policy.
●
Exposures identification. Analyze the percentage of asset loss caused by each
identified threat. Identifying and defining the potential value loss of each exposure
is a crucial component in security risk analysis.
●
Vulnerability assessment. Develop a comprehensive list of all known
vulnerabilities that can be used against those assets that require some level of
protection. A vulnerability is any weakness in an information system or its
components (for example, system security procedures, hardware design, software
design, and internal controls) that could be exploited.
●
Countermeasure development. Develop an appropriate security risk
countermeasure that makes good business sense, meaning that it is cost-effective
for guarding the assets in your organization.
●
Penetration testing. Use penetration testing to help identify ways that an
unauthorized individual could gain access to the organization. Common
penetration testing methods include:
●
External resource scanning to identify potential targets to compromise.
●
War pinging to identify unsecured IP addresses. War pinging is a tool used by
a hacker to find a range of IP numbers and find out what numbers are in use or
what numbers answer within the set time. These results can be saved as .csv
files and imported into databases.
●
Social engineering to locate individuals who may be tricked into revealing their
passwords or some form of security information that would accidentally provide
classified information.
●
Building penetration to determine whether physical access to the facility can be
easily obtained.
15
These tests are useful for increasing the attention that an organization places on security
policies. One of the largest considerations in performing a penetration test is identifying a
reputable external agent to perform the tests.
●
Incident response. A good incident response plan will outline specific procedures
to follow as you learn more about an attack on your organization. Generally, the
nature of the attack symptoms will determine the order in which to follow the
procedures defined in your security program. Because time is critical, less time
consuming procedures should generally be undertaken before more lengthy ones.
●
Scope of work effort to secure assets. Define the total amount of work, including
time, effort, and money required to provide “good enough” security and to keep the
overall infrastructure usable from the support and end-user perspectives of your
organization. Cost benefit analysis for a given safeguard should be derived from a
proper security risk analysis in conjunction with the asset to the total cost of
ownership (TCO) or return on investment (ROI) of the organization.
Assets
An asset is anything in your organization’s environment that may require some level of
protection. This could include items on the balance sheet like software applications or
hardware and other less tangible items such as data or even people. The purpose of
security is to prevent assets from being compromised and protecting the confidentiality,
integrity, and availability of the data. All corporations are concerned with the many
detrimental risks of getting their data modified, which degrades the integrity of business
data.
A key aspect of IT security risk management is determining the value of each primary
asset in your organization, the value of the information that each asset contains, and how
each asset relates to others in your environment. For example, if critical business data is
compromised from a company's Web server, the company's worth may decrease in
value, or a router that is compromised may connect all branch locations throughout the
company to your primary data center.
The overall associated value of each asset will determine the time, effort, and cost of
securing them based on the level of security that is required to provide each asset with
adequate protection. Keep in mind that assets may have an associated level of
dependency. Consider how these resources are authenticated, or how users are
authorized to gain access to each asset and the data that it exposes. For example, a
weak password on a CIO's portable computer may pose a significant financial risk if it is
compromised.
Assets themselves must also be classified according to the protective measures that
each requires. These measures include:
16
●
Prevention—Measures that prevent assets from being damaged, altered, or
stolen. Preventive measures can range from locking a server room door to setting
up high-level security policies.
●
Detection—Measures that allow for detection when assets have been damaged,
altered, stolen, or otherwise compromised. Detection measures also include
mechanisms for determining how an asset had been compromised, and
specifically who caused the damage. Various tools are available to help detect
intrusions, damage or alterations, and viruses.
●
Reaction—Measures that allow for the recovery of the assets, even if an asset is
lost or damaged.
These protective measure classifications should be integrated with different types of
countermeasures. Countermeasures, or safeguards, help mitigate the potential risk of an
asset being compromised. A countermeasure is designed to eliminate a vulnerability or
reduce the risk of a threat exploiting a vulnerability in a computer environment.
In order to form countermeasures to protect your organization’s assets, you must first
understand how your organization’s assets may be compromised by defining threats and
risks that are relevant to them. The following list includes five principles to consider when
developing a security program to protect your company assets. You must assess each of
these principles according to your company's needs.
●
Confidentiality. Confidentiality is a condition maintained by ensuring that
information is accessible only to those authorized to have access to it.
Confidentiality ensures that the necessary level of secrecy is enforced at each
junction of data processing to prevent unauthorized disclosure. An example of poor
security measures would be allowing anonymous user access to sensitive
information such as a human resources department file share.
●
Integrity. Integrity means safeguarding the accurate and completeness of
information and processing methods. Integrity is upheld when the accuracy and
reliability of information is maintained within the system environment and when
unauthorized modification of data is prevented. Storing incorrect data within the
system can be as bad as losing data.
●
Availability. Availability is the prevention of unauthorized withholding of
information or resources. Availability ensures the reliability and timely access to
data and resources to authorized individuals.
●
Authentication. Authentication is the process of verifying that users are who they
claim to be when logging onto a system. Generally, user names and passwords
accomplish this authentication. More sophisticated authentication methods include
the use of smart cards, or biometrics, including fingerprint or retinal scanning.
The process of authentication does not grant the user access rights to resources.
This is achieved through the authorization process. The loss of authentication
means that there is no means of determining who is accessing the asset.
●
Authorization. Authorization is the right granted to an individual or process to use
the system and the data that is stored on it. Authorization is typically set up by a
system administrator and verified by a computer in your environment based on
some form of user identification, such as a personal identification number (PIN),
code number, or password.
An authorization process uses the appropriate security authority to determine
whether a user should have access to resources. The loss of authorization means
that there is no means of determining who should be allowed to access the asset.
17
Relationship Between Threats, Exposures, Vulnerabilities,
and Countermeasures
If a threat agent gives rise to a threat and exploits a vulnerability, the attack leads to a
potential security compromise. The attack can then damage the asset by degrading its
confidentiality, integrity, or availability. Therefore, the attack causes an exposure to
potential company losses. However, these exposures can be minimized by the use of
countermeasures.
For example, if a company has antivirus software only on its servers, and the virus
signatures are not kept up to date, this creates a vulnerability. The company becomes
vulnerable to virus attacks and the threat of a virus showing up in the environment and
disrupting productivity.
The risk is the likelihood of a virus showing up in the environment and causing damage.
Because there is a possibility of losing or corrupting data from a virus attack, the
company now has an exposure. The countermeasures for this situation are to ensure that
antivirus software is installed on all computers in the environment and that the signatures
on all the computers are up to date.
Security management terms can sometimes be difficult to understand. The following table
provides a consolidated view of the key security components of security management.
Table 2.1: Key Security Components
18
Component
Definition
Threat
A threat is any potential danger to information or systems.
Threat agent
A threat agent is the person or process attacking the network through a
vulnerable port on the firewall, or a process used to access data in a way
that violates your security policy.
Vulnerability
A vulnerability is a software, hardware, or procedural weakness that may
provide an attacker or threat agent with an opportunity to enter a computer
or network and gain unauthorized access to resources within the
environment.
Risk
A risk is the likelihood of a threat agent taking advantage of a vulnerability. It
is the potential for loss or the probability that a threat will exploit a
vulnerability.
Exposure
An exposure occurs when a threat agent exposes a company asset to
potential loss. A vulnerability can cause an organization to be exposed to
possible damages.
Countermeasure
A countermeasure, or safeguard, mitigates a risk. Countermeasures include
software configurations, hardware, or procedures that eliminate a
vulnerability or reduce the risk of a threat agent from being able to exploit a
vulnerability.
The relationship between threats, vulnerabilities, and risk can initially be a tough concept
to grasp. Each threat and vulnerability identified within your organization should be
qualified and ranked according to a standard, such as low, medium, or high. The ranking
will vary among organizations and sometimes even within an organization. For example,
the threat of an earthquake is significantly higher for offices near a major fault line than
elsewhere. Similarly, the vulnerability of physical damage to equipment would be very
high for an organization producing highly sensitive and fragile electronics, but the same
vulnerability level for a construction company may be lower.
The Risk Management Matrix can help you evaluate threats and their impact on your
organization. The level of risk in your organization increases with the level of threat and
vulnerability, as the following figure indicates.
Figure 2.1
Risk Management Matrix
The risk management matrix may be used as a tool in the following way. For example,
your company might have two different types of Web sites; a volunteer not – for – profit
informational site, or a financial services transactional site which provides end to end
sales transactions for your customers.
Each Web site will have different risk levels. For instance, the informational Web site may
have a low threat level because it contains information that is not crucial for business
operations to function if stolen or damaged. Such informational Web sites may also have
a low vulnerability level if current services packs and hotfixes are deployed on these
servers. This places the informational Web site in the Low Risk quadrant.
19
On the other hand, the financial services Web site might be in the Medium or High Risk
quadrants. Attackers may benefit greatly if the financial data is compromised or stolen,
which makes the level of threat high. However, if the Web servers have the appropriate
service packs and hotfixes then this Web site would be somewhat less vulnerable and
may fall in the Medium Risk quadrant. If the Web servers are not current with service
packs and hotfixes then the Web site would be very vulnerable and would fall in the High
Risk quadrant.
The figure below provides a theoretical model that can be used to determine the various
threats, motives and goals, methods, exploits, and vulnerabilities that could be used
against your organization in an attack.
Figure 2.2
The path to compromise an asset
The figure above depicts a simple yet logical path showing how threat agents may
compromise assets. The three types of threat classification are shown on the far left side
of the figure. Threat classification identifies who the attacker is or what threat agents are
initiating the attack. These include non-malicious threats, malicious threats, and
catastrophic incidents.
Threat agents typically have motives and goals to achieve when attempting to
compromise assets, such as financial gain. The threat agents use specific tools,
techniques, and methods to exploit certain vulnerabilities in the security of the assets.
The arrows in the figure depict the path that an attacker may take during an attempt to
compromise an asset and the vulnerabilities that may be exploited.
20
Threat Classifications
A threat is a person, place, or thing that has the potential to access resources and cause
harm. Threats can originate from two primary sources: humans and catastrophic events.
Human threats subsequently can be broken down into two categories: malicious and nonmalicious. Non-malicious “attacks” usually come from users and employees who are not
properly trained on computers and who are not aware of various computer security
threats. Malicious attacks usually come from external people or disgruntled current or exemployees who have a specific goal or objective to achieve.
Table 2.2: Threat Types
Threat
Examples
Catastrophic incidents
Fire, water, wind, earthquake, power failure, terrorist attacks
Non-malicious person
Uninformed employees, uninformed users
Malicious person
Attackers, industrial spies, governments, bribery, and social
engineering
Catastrophic Incidents
Any event relating to extreme weather, naturally occurring phenomena, or a catastrophic
incident may cause severe damage to your organization's infrastructure. Information can
be lost, hardware can be damaged, and a loss of productivity can occur along with the
disruption of other essential services.
Unfortunately few preventative measures can be implemented to mitigate the potential for
catastrophic incidents. The best approach for these types of threats is to have disaster
recovery and contingency plans in place to help minimize the effects of a loss. Having
these plans in place and ready to go will help your organization restore itself to its
“previous state” to resume normal business operations as quickly as possible. In addition
to natural catastrophic events, riots are included because it may be difficult to form
effective contingency plans to protect against informational asset loss in the event of a
riot.
Mechanical Failures
Mechanical threats are often overlooked. These can include power outages, hardware
failures, and network outages. Prevention of vulnerabilities that may arise from these
threats can often be implemented through proper planning.
Hardware clustering, redundant power trunks for data centers, and robust network
designs can help eliminate single points of failure in your organization that may cause
mechanical failures. However, implementing these countermeasures can be extremely
expensive and should be evaluated carefully to ensure that the value of the asset
warrants using such methods.
Mitigating mechanical threats may uncover additional security risks, because mitigation
steps may increase the attack surface. The attack surface is the view of the asset with
regard to the number of potential entry points into the system. Often, by adding features
or functionality to a computing asset, other security vulnerabilities may be exposed.
However, mechanical threats themselves are not traditionally a large concern for a
security project and therefore should also be considered outside the scope of this guide.
21
Human Threats
Human threats can appear in two different varieties: malicious and non-malicious. Nonmalicious threats can cause major issues with data integrity through normal user error.
Software bugs, data entry errors, and administrative mistakes all fall into this category.
Malicious Attacks
Malicious threats consist of attacks by disgruntled or malicious, current and exemployees or people from outside the organization. Insiders are likely to have specific
goals and objectives and usually have some level of legitimate access to systems in the
environment. Employees are the group most familiar with your company's computers and
applications, including having knowledge of what exploits and vulnerabilities may cause
the most damage to your organization. This type of attack can be extremely difficult to
detect or protect against.
Malicious insiders are likely to have specific goals and objectives and usually have
legitimate access to the system. A malicious insider attack can affect all components of
your computer security or applications. Other types of security crimes instigated by
malicious insiders may involve bribery or social engineering.
Social engineering is the process of tricking people into revealing their passwords or
some form of security information. Often these actions go undetected because audit trails
are inadequate, or they fail to be reviewed.
A malicious attacker can also use social engineering to deceive employees and gain
entry to your environment. For example, an attacker could masquerade as an
administrator and ask for passwords and user names. Employees who are not well
trained and are not security conscious can fall for this deception.
Disgruntled employees can create at best inconvenience or at worst sabotage within an
organization. Current employees can actually cause more damage than former
employees.
Non-Malicious Attacks
Attackers are not the only ones who can harm an organization. The primary threat to data
integrity comes from authorized users who are not aware of the actions that they are
performing. Errors and omissions can cause your organization to lose, damage, or alter
valuable data.
Errors and omissions are important threats to data integrity. Errors are caused not only
by data entry clerks processing hundreds of transactions per day, but also by all users
who create and edit data. Many programs, especially those designed by users for
personal computers, are lacking in appropriate quality-control measures. However, even
the most sophisticated programs cannot protect against all types of input errors or
omissions.
Programming and development errors, often called “bugs”, range in severity from
irritating to catastrophic. Improved software quality has reduced but not eliminated this
threat. Installation and maintenance errors can also cause security problems.
Organizations often assume that the information programs that its computer systems
receive are more accurate than they really are. Many organizations address errors and
omissions in their computer security, software quality, and data quality programs by
implementing security policies.
22
Categorizing Threats
There are literally hundreds of ways to categorize threats. Microsoft developed the
STRIDE method of categorizing the following malicious threat types: Spoofing identity,
Tampering with data, Repudiation, Information disclosure, Denial of service, and
Elevation of privilege. Each component of the method is defined below.
Spoofing Identify
Spoofing identity threats include anything done to illegally obtain or access and use
another person's authentication information, such as a user name or password.
Tampering with Data
Tampering with data threats involve the malicious modification of data. Examples include
unauthorized changes made to persistent data, such as the defacing of a Web site,
information held in a database, or the alteration of data as it flows between two
computers over an open network.
Repudiation
Repudiation threats are associated with users who deny performing an action, yet other
parties having no way to prove otherwise. An example would be when a user performs an
illegal operation in a system that lacks the ability to trace the prohibited operation.
Nonrepudiation refers to the ability of a system to counter repudiation threats. For
example, a user who purchases an item might have to sign for the item upon receiving it.
The vendor can then use the signed receipt as evidence that the user did receive the
package.
Information Disclosure
Information disclosure threats involve the exposure of information to individuals who are
not supposed to have access to it. Examples include the ability of users to read files that
they were not granted access to, or the ability of an intruder to read data in transit
between two computers.
Denial of Service
Denial-of-service (DoS) attacks disrupt service to valid users. DoS attack objectives may
include making a Web server temporarily unavailable or unusable. Protection against
certain types of DoS threats can help improve system availability and reliability.
Elevation of Privilege
In this type of threat, an unprivileged user gains privileged access that enables him or her
to compromise or possibly destroy an entire system environment. These threats include
situations in which an attacker has effectively penetrated all system defenses to exploit
and damage the system.
23
Exploits
An asset may be accessed through a threat that leverages a vulnerability in your
organization's environment. The following table provides examples of three key exploit
types.
Table 2.3: Exploit Types
Exploit
Example
Technical vulnerability exploit
Brute force attack
Buffer overflow
Misconfiguration
Replay attack
Session hijacking
Information gathering
Address identification
Document grinding
OS identification
Port scanning
Response analysis
Social engineering
Service and application probing
User enumeration
Vulnerability scanning
Wireless leak
Denial of service (DoS)
Physical damage
Removal of resources
Resource modification
Resource saturation
Buffer overflow
Example: Exploits from Malicious Attackers
Deleting and Altering Information
Malicious attackers who delete or alter information normally want to prove a point or take
revenge for something that has happened. Malicious insiders normally act out of spite
toward the organization because they are disgruntled about something. Outsiders,
however, may attack just to prove that doing so is possible, or they may do so simply for
the satisfaction of saying that they did it.
24
Committing Fraud and Information Theft
Information technology is increasingly both the tool and the target for fraud and theft.
Properly designed and controlled financial systems can support required legislation or
reporting requirements to prevent fraud. Financial system environments are not the only
ones subject to this abuse. Other company targets include those with environments that
control access to personal information, such as credit or identity agencies, time and
attendance systems, inventory systems, school grading systems, or long-distance
telephone billing systems.
Because many computers are relatively small and valuable, physical theft is easy. The
hardware asset itself may be replaceable, but the data that it contains may be far more
valuable if it contains credit card numbers or medical patient histories. You can never
make something impossible to steal, but to better protect the investment in equipment,
such measures as desk locks can be used to secure computers in your organization. If a
computer is stolen, the information that it contains will be at the disposal of the thief who
may erase it or be able to read it, but you can ensure that the stolen information is
virtually useless by encrypting it and making certain that the thief cannot gain access to
the key to decipher it.
Disrupting Normal Business Operations
Attackers may want to disrupt normal business operations. This may be done as an act of
spite, for example, if a disgruntled employee does not want to work because he or she
has been turned down for a promotion.
Alternatively, outside attackers might want to disrupt services to gain a competitive edge
in a world that thrives on competition. It is also possible that the perpetrators may attack
just for the fun of it. In any of these situations, the attacker has a specific goal to achieve
and accomplishing it brings some level of satisfaction and reward to the attacker.
Attackers can use several methods for performing DoS attacks. The section on "Threat
Analysis" in Chapter 3, "Understanding the Security Risk Management Discipline,"
discusses methods, tools, and techniques to carry out DoS attacks.
Attack Methods
Threat Motive + Exploit Method + Asset Vulnerability = Attack
The method in this formula exploits the organization’s vulnerability to defend against
attack as described above in Figure 2.2. Malicious attackers can gain access or deny
services in numerous ways that include the following:
●
Viruses, Trojan horses, and worms
●
Password cracking
●
DoS attacks
●
E-mail hacking
●
Malicious code
●
Packet replay
●
Packet modification
●
Eavesdropping
●
Social engineering
●
Intrusion attacks
●
IP spoofing and session hijacking
25
Vulnerabilities
A vulnerability is a point where an asset is susceptible to a threat. It may also be thought
of as a weakness. Vulnerabilities may originate from technology, people, or processes.
Most often they are viewed as technological flaws in the implementation of software or
hardware, or in how a system is designed or architected. Poorly defined and
communicated organizational policies and procedures are also vulnerabilities.
In addition, vulnerabilities are weak points or loopholes in security that a malicious
attacker exploits to gain access to the network or to resources on the network. The key
point to understand is that the vulnerability is not the attack itself, but rather the weak
point that is exploited.
The following is a list of possible vulnerabilities. These represent just a few of the many
that exist and include examples in the areas of physical, data, and network security.
Table 2.4: Types of Vulnerabilities
Vulnerabilities
Examples
Physical
Unlocked doors
Natural
Corporate building built on a fault line
Hardware and software
Out of date antivirus software and operating system patches
Media
Electrical interference
Communications
Unencrypted protocols
Human
Poorly defined procedures and poorly written applications
Risks
A risk is the likelihood of a threat agent taking advantage of a vulnerability, and the loss
potential, or probability that such a threat will exploit that vulnerability. If a firewall has
several ports open, there is a higher risk that an intruder will use one of the ports to
access the network by an unauthorized method.
If users in your environment are not trained on processes and procedures, there is a
higher risk that an employee will make a mistake and unintentionally destroy data. If an
intrusion detection system is not implemented on a network, there is a higher risk that an
attack will go unnoticed until it is too late. Reducing vulnerabilities or threat agents
reduces risk.
Countermeasures
Countermeasures, or safeguards, mitigate the potential risk. A countermeasure is
anything such as a software configuration, hardware, or procedure that when deployed
counteracts a threat and vulnerability to reduce risk in a computer environment.
Examples of countermeasures include strong password management, a security guard,
access control mechanisms within an operating system, the implementation of basic
input/output system (BIOS) passwords, and security awareness training.
26
If your company has security hotfixes only on your servers, and the hotfixes are not kept
up to date, this creates a vulnerability. The threat is a malicious or nonmalicious user
showing up in the environment and disrupting productivity. Without current hotfixes, a
system is not protected, and there is a possibility of lost or corrupted data from this
exposure. The countermeasures in this situation are to install any service packs that are
prerequisites on all computers in your organization, and then to update them with any
hotfixes not included in the service packs. The relationship between threats,
vulnerabilities, and countermeasures is shown in the following figure.
Figure 2.3
Relationships between security components
The Computer Intrusion Squad survey published by the Computer Security Issues (CSI)
and the San Francisco branch of the Federal Bureau of Investigation (FBI) goes into
great depth on various types of computer crimes. The CSI and FBI survey results should
be taken as raw intelligence. These surveys provide an intelligence resource to keep your
thinking current on emerging trends in cyber crime.
27
Summary
This chapter provides an overview of the most significant components of security analysis
and the major processes required to practice it in a corporate environment.
Understanding the relationship between threats, exposures, vulnerabilities, and
countermeasures is vital to achieving effective security measures in your organization.
More Information
For information on computer crimes, see: http://www.gocsi.com/press/20020407.html.
For information on threat assessment, see: “Threat Assessment of Malicious Code and
Human Threats,” by Lawrence E. Bassham & W. Timothy Polk: National Institute of
Standards and Technology Computer Security Division, at http://csrc.nist.gov/.
For information on best practices in information security, see: http://www.iso-17799.com/.
For information on hacking, see: http://www.hackingexposed.com/.
For information on security threats from Microsoft TechNet, see:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bestprac/
bpent/sec1/secthret.asp.
For information on asset valuation from the National Institute of Standards and
Technology, see: http://csrc.nist.gov/asset/.
28
3
Understanding the Security
Risk Management Discipline
This chapter draws upon proven practices from security analysis methodologies in use
today that leverage the Microsoft Solutions Framework (MSF) and Microsoft Operations
Framework (MOF). MSF offers guidance in the planning, building, stabilizing, and
deploying phases of the project life cycle in the areas of enterprise architecture and
infrastructure deployment. MOF provides advice on how to develop or improve
management systems for information technology (IT) operations. For details on MSF or
MOF, see the "More Information" section at the end of this chapter.
The chapter defines the three primary guidance processes: the Security Risk
Management Discipline (SRMD) and the Security Risk Framework in terms of risk
management activities that occur during the life cycle of a security project.
There are three primary processes that an organization can use to define what it needs to
do to become secure and how to keep secure. The following defines these primary
processes at a high level.
1. Assessment
This phase involves gathering relevant information from the company's
environment to perform a security assessment. Enough data must be captured to
effectively analyze the current state of the environment and then determine how
well protected the organization’s information assets are from potential threats. In
addition to the security assessment, a Security Action Plan will later be created to
execute during the implementation process.
2. Development and Implementation
This phase focuses on executing a Security Action Plan to implement the
recommended changes to the environment defined in the assessment. In addition
to the Security Action Plan, the Security Risk Contingency Plan is developed.
3. Operation
This phase involves making modifications and updates to your environment as
needed to keep it secure. Penetration testing and incident response strategies are
carried out during operational processes, which help solidify the objectives of
implementing a security project in your organization. Auditing and monitoring
activities also are carried out within the operational processes to keep the
infrastructure intact and secure.
29
Security Risk Management and Security Framework
Practices
During the execution of the security plan, two types of risk management activities are
ongoing during the life cycle of the project. The first is managing the risk inherent to the
project itself, and the second is managing the risk associated with security components.
The project risks are assessed during the project life cycle only, while the security risks
must be assessed during the entire life cycle of the solution or system. The MSF Risk
Management Discipline serves as the basis for managing risk for both projects and
security assessments. Prescriptive examples for security risk management will further be
described in Chapter 4, "Applying the Security Risk Management Discipline," of this
guide.
In this solution guide, the Security Risk Management Discipline (SRMD), which is derived
from the MSF Risk Management Discipline (RMD), is defined. To maintain a clear
distinction between the two activities, RMD is mentioned in the context of project risk,
while SRMD refers to the security risk assessment activity. The RMD is used as the
primary tool for the development of the SRMD.
Both the RMD and the SRMD processes advocate a proactive approach, continuous risk
assessment, and integration into decision-making throughout the project and operation of
your environment.
Computer system security should be done proactively and continuously to ensure the
security of information assets and to monitor for new threats and vulnerabilities.
Information security should always be considered whenever you add new functionality to
your organization’s technology infrastructure. In addition, some business process and
procedures may have to be altered to operate in the modified environment and provide
protection to these new information assets.
The nine steps in the Security Risk Management Discipline are:
Assessment
1. Asset assessment and valuation
2. Identifying security risks
3. Analyzing and prioritizing security risks
4. Security risk tracking, planning, and scheduling
Development and Implementation
5. Security remediation development
6. Security remediation testing
7. Capturing security knowledge
Operate
8. Reassessing new and changed assets and security risks
9. Stabilizing and deploying new or changed countermeasures
These steps are embodied within the SRMD as the three primary phases of: assessment,
implementation, and operation.
30
Assessment
The following sections incorporate organizational assessment tasks into a foundation for
the beginning of a security analysis. Asset assessment and validation are the first steps
toward security analysis because it is necessary to know what you are starting with in
order to evaluate risks moving forward. The security analysis process is a set of
strategies aimed at enabling you to determine which assets are worth securing in your
environment and in what order you want to prioritize securing them.
Asset Assessment and Valuation
Asset assessment is the value placed on information relative to the parties involved and
what effort it took to develop this information. Valuation is how much it costs to maintain
an asset, what it would cost if it were lost or destroyed, and what benefit would be gained
if another party obtained this information. The value of an asset should reflect all
identifiable costs that would arise if there were an actual impairment of the asset.
Security Risk Identification
Security risk identification allows for project team members to brainstorm and surface
potential security risks. Information is collected on threats, vulnerabilities, exploits and
countermeasures.
Security Risk Analysis
Security risk analysis is used to analyze the potential attacks, tools, methods, and
techniques that may be used to exploit a potential vulnerability. Security risk analysis is a
method of identifying risks and assessing the possible damage that could be caused to
justify security safeguards.
A security risk analysis has three main goals: Identify risks, quantify the impact of
potential threats, and provide an economic balance between the impact of the risk and
the cost of the countermeasure. Information is collected to estimate the level of risk so
that the team may make educated decisions around which security risks should receive
the most remediation effort.
This analysis is then used to prioritize security risks and enable your organization to
commit resources to address the most critical security issues.
A risk analysis helps integrate the security program objectives with the company’s
business objectives and requirements. The more your business and security objectives
are in alignment, the more successful your organization will be at fully realizing both.
The analysis also helps your company draft a proper budget for a security program and
the security components that make up that program. Once you know how much your
company's assets are worth, and you understand the possible threats they are exposed
to, you can make intelligent decisions on how much money to spend toward protecting
those assets.
31
Security Risk Tracking, Planning, and Scheduling
Security risk tracking, planning, and scheduling takes the information obtained from the
security risk analysis and uses it to formulate mitigation and contingency strategies and
plans that encompass them. Security risk scheduling attempts to define a schedule for
the various remediation strategies constructed during the build phase of a security
project. This scheduling takes into consideration how the security plans are approved and
incorporated into the information architecture, as well as the standard day-to-day
operations procedures that have to be implemented.
Development and Implementation
The work you perform during the assessment process enables you to implement proper
countermeasure development and implementation. The results of your assessment
processes provide an easy transition into implementing effective countermeasure
deployment and security learning strategies.
Security Risk Remediation Development
Security risk remediation development is the process of taking the plans that were
created in the Assessment phase and using them to create a new security strategy
involving configuration management, patch management, system monitoring and
auditing, and operational policies and procedures. As various countermeasures are being
developed, it is important to ensure thorough tracking and reporting on this progress.
Security Risk Remediation Testing
Security risk remediation testing occurs after the development of the remediation
strategies and associated system management changes have taken place and the
policies and procedures to determine their effectiveness have been written. The testing
process enables the team to consider how these changes can be deployed into a
production environment. During the testing process, the countermeasures are evaluated
for effectiveness against how well the security risk is controlled.
Security Risk Learning
Security risk learning formalizes the process for capturing knowledge about how the team
secured the assets and documents the vulnerabilities and the exploits that were
discovered. As the IT department learns, new security information, it must be captured
and redeployed in order to continually optimize the effectiveness of the security
countermeasures protecting company assets. In addition, security education needs to
happen for the business communities via training or security awareness bulletins.
Note: These steps are intended as a logical guide and do not need to be followed in
sequence to address any given security risk. Security teams will often cycle through
the identification, analysis, and planning steps as they develop experience on security
issues, threats, and vulnerabilities for their particular information assets.
Your organization must define a formal risk management process that will define how
security countermeasures are initiated and evaluated, and under what circumstances
transitions between the steps should occur for individual or groups of security risks.
32
Operate
Strong and consistent operating cycles provide your security teams with a mechanism to
deliver reliable and predictable results. By executing assessment process early in the
security project, teams have greater knowledge of how to reassess new and changed
assets throughout your enterprise. Stabilizing and deploying new or changed
countermeasure against the new and changed assets then becomes part of the day to
day operation of your company.
Reassessing New and Changed Assets and Security Risks
These processes are essentially change management processes, but this is also where
security configuration management is executed. This leads to release management when
the new countermeasures and security policies are completed.
Stabilizing and Deploying New or Changed Countermeasures
In the Operate phase, these processes are managed by system administration, security
administration, and network administration teams. Service monitoring, service control,
and job scheduling are additional processes in the operation phase in which security
administrators execute new and improved countermeasures.
Security Service Desk, Incident Management, and Problem
Management Learning
In the support phase operational groups within the IT organization support the secure
environment by strong security management from the security service desk and
controlled incident and problem escalation management.
Service Level, Financial, and Availability Management
MSF and MOF are proven practices designed to help you develop, deploy, and maintain
a strong security management program. Successfully utilizing these proven practices
enables the creation of an environment that provides integrity, confidentiality, and
availability of resources.
Security management is optimized by strong management in service level managements,
financial management, service community management, availability management,
capacity management, and workforce management.
33
Security Risk Management Framework
Overview
The framework leverages the MSF process model and describes a high-level sequence
of activities for building and deploying IT security solutions. Rather than prescribing a
specific series of procedures, the framework is flexible enough to accommodate a broad
range of IT processes. The process model covers the life cycle of a solution from project
inception to live deployment.
Figure 3.1
Security Framework process model milestones by phase
The MSF process model may be used to develop software applications and to deploy
infrastructure technology. The process model follows an iterative cycle designed to
accommodate changing project requirements through short development cycles and
incremental versions of the solution. Continuing risk management and testing cycles
make this possible.
Many key questions about the project are asked and answered or discussed at each
milestone of the process model, such as: Does the team agree on the project scope?
Has the team planned enough to proceed? Has the team built what it said it would build?
Is the solution working properly for the customers and partners of your organization? The
following six major processes of a security project associated with the figure above are
discussed briefly here.
34
1. Initiation of the project definition
The initiation phase of the project addresses one of the most fundamental needs
for the success of the security project:, unifying the project team and security
program. The process of team initiation continues until refinement at the end of the
initiation phase. All team members must have a clear vision of what they want to
accomplish in a security solution and the needs of the business concerning
security. This phase focuses on identifying the business problem or opportunity
around security management. All parties involved in security management must
define goals, assumptions, and constraints during these processes.
2. Security assessment and analyses
The assessment and analyses of security management are processes that take
place within the planning phase of the MSF methodology. These processes include
organization assessment, asset valuation, threat identification, vulnerability
assessment, and security risk assessment. Together they form the planning
involved in a successful countermeasure deployment.
3. Security remediation development
Inputs taken from the security assessment and analyses phases create a means
for security remediation development. During these processes, developers are
constantly working through the development, testing, and validation of
countermeasures to remediate risks identified in earlier phases of the project.
These security remediation development processes are unit tested by the
development team and evaluated against quality criteria.
4. Security remediation testing and resource functionality testing
The security remediation testing and resource functionality testing processes
contain less predictable results. Unforeseen results from the functional testing are
tagged and managed during the stabilizing phase by the testing processes.
Although the building phase builds on known plans and specifications, the number
and severity of bugs that will be found is always unknown. The techniques of bug
convergence and zero bug bounce are used by Microsoft to measure the quality
state of the solution and predict the release date during this phase.
5. Security policies and countermeasure deployment
The security policies and countermeasure deployment processes continue
throughout the deploying phase of the MSF methodology and are continued into
the MOF process cycle. This process of countermeasure deployment organizes
the types of countermeasures and security policies into two types, core and site,
and their respective security components. Core specific security components are
located at a central or key location that involves the entire security solution. Site
specific components are located at individual locations that enable users to access
and use the security solution.
6. Deployment complete
Security risk management knowledge is a process captured near the deployment
complete milestone. Capturing the lessons learned near deployment move the
solution into an operational state and hand the completed project off to the MOF
process cycle.
For further details on security project processes, see the Microsoft Solution for Security
Services Guide.
35
Creating Your Security Program Team
During the assessment process of the MSF process model, a crucial step towards
securing your environment occurs, which is the creation of a security program. The
charter of this security program is to determine the objectives, scope, policies, priorities,
standards, and strategies for total security within your organization. The members of the
security program are senior executives within the company. The Security Administration
Group is then comprised of middle level managers and their reporting teams who
implement and manage the policies governed by the security program.
A security program should be developed using a top – down approach, meaning that the
initiation, support, and direction must come from top management, work down through
middle management, and finally include staff members. Support however, may be a
combination of top – down, bottom – up or middle – out development and championing of
ideas in security management. Many companies today are using a bottom – up approach
for development and support, where the IT department develops a security plan without
proper management support and direction. This can cause the security program to
become out of alignment with the larger business objectives of your organization.
Senior management should begin creating the security program by assigning roles and
responsibilities within the organization that are necessary to get it off the ground. The
involvement of senior management keeps the program strong and evolving as the
business and technical environments change. Creating roles within a security program
validates that the organization recognizes security as a cohesive part of its business
rather than just a concern.
In addition to a security program, management must establish a security administration
group. The security administration group is directly responsible for monitoring the majority
of the facets of a security program. The security program in an organization usually
develops security policies, while the security administration group enforces and monitors
security configurations.
Depending on the organization, its security needs, and the size of the environment,
security administration can consist of one person or a group of individuals working in a
central or decentralized manner.
Assessment
The security framework for threat assessment described in the process model is
designed to help security professionals develop a strategy to protect the availability,
integrity, and confidentiality of data in an organization's IT infrastructure. It may be of
interest to information resource managers, computer security officials, and
administrators, and of particular value to those trying to establish computer security
policies. The framework offers a systematic approach to this important task and, as a
final precaution, also involves establishing contingency plans in case of a disaster.
Confidentiality
The IT infrastructure of your organization may contain information that requires protection
from unauthorized disclosure. Examples include timed dissemination of information, such
as a crop report, personal information, or proprietary business information. Confidentiality
ensures that the ability to provide the necessary level of secrecy is enforced at each
junction of data processing and prevents unauthorized disclosure. A consistent level of
confidentiality should be maintained while data resides on systems and devices within the
network, as it is transmitted, and once it reaches its destination.
36
Integrity
The IT infrastructure contains information that must be protected from unauthorized,
unanticipated, or unintentional modification. Examples include census information,
economic indicators, or financial transactions systems. Integrity is upheld when the
accuracy and reliability of information and systems is assured, and unauthorized
modification of data is prevented.
Availability
The IT infrastructure contains information or provides services that must be available on
a timely basis to meet mission requirements or to avoid substantial losses. Examples
include systems critical to safety, life support, and consistent network connectivity.
Availability ensures the reliability and timely access to data and resources to authorized
individuals.
Security administrators need to decide how much time, money, and effort must be spent
to develop appropriate security policies and controls. Your organization should analyze
its specific needs and then determine its resources, scheduling requirements, and
constraints. Computer systems, environments, and organizational policies are different,
making the strategy for securing groups of computers in your organization difficult.
Although a security strategy can save your organization valuable time and provide
important reminders of what needs to be done, security is not a one-time activity. It is an
integral part of the system life cycle for your environment. The activities described in this
chapter generally require either periodic updating or appropriate revision. Such changes
are made when configurations or other conditions change significantly, or when
organizational regulations and policies require changes. It is an iterative process that is
never finished and should be revised and tested periodically.
Organizational Assessment
Establishing an effective set of security policies and controls requires using a strategy to
determine the vulnerabilities that exist in your computer systems and in the current
security policies and controls that guard them. Your review should make note of areas in
your environment in which policies are lacking, as well as examine policy documents that
exist. In addition to policy reviews, the legal team of your organization should ensure that
all security policies are in compliance with the company's legal policy. The current status
of your computer security policies can be determined by reviewing the following list:
●
Physical computer security policies such as physical access controls
●
Network security policies (for example, e-mail and Internet policies)
●
Data security policies (access control and integrity controls)
●
Contingency and disaster recovery plans and tests
●
Computer security awareness and training
●
Computer security management and coordination policies
Other policy documents that contain sensitive information, including:
●
Computer basic input/output system (BIOS) passwords
●
Router configuration passwords
●
Access control documents
●
Other device management passwords
37
Threat Analysis
Creating a list of threats (most organizations can identify several) helps your security
administrator to identify the various exploits that can be used in an attack. It is important
that administrators update their knowledge of this area on a continual basis, because
new methods, tools, and techniques for circumventing security measures are constantly
being devised.
The threat analysis process is outlined in the planning phase of Figure 3.1 to determine
the attacks that can be expected and then developing ways of defending against these
attacks. It is impossible to prepare against all attacks; therefore, prepare for the most
likely attacks that the organization can expect. It is always better to prevent or minimize
attacks than to repair the damage after an attack has already occurred.
In order to minimize attacks, it is necessary to understand the various threats that cause
risks to systems, the corresponding techniques that can be used to compromise security
controls, and the vulnerabilities that exist in your security policies. Understanding these
three elements of attacks helps you to predict their occurrence, if not their timing or
location. Predicting an attack is a matter of predicting its likelihood, which depends on
understanding its various aspects. The various aspects of an attack can be expressed in
the following equation:
Threat Motives + Exploit Methods + Asset Vulnerabilities = Attack
A malicious attacker can use different methods to launch the same attack. Therefore, the
security strategy must be customized for each method that each type of threat agent may
exploit.
Vulnerability Assessment
Assessing your organization's security needs must include determining its vulnerabilities
in relation to known threats. This assessment entails recognizing the types of assets that
your organization has and what kind of damage could be done to them.
Determining Possible Damage from an Attack
Possible damage to assets in your environment can range from minor computer glitches
to catastrophic data loss. The damage caused to the system will depend on the type of
attack. If possible, use a test or lab environment to clarify damage resulting from different
types of attacks. This will enable security personnel to accurately assess the physical
damage. Not all attacks cause the same type or amount of damage. Tests that could be
run include:
38
●
A simulation of an e-mail virus attack on a lab system followed by an analysis to
determine the damage caused and potential recovery procedures required.
●
A test to determine whether employees are susceptible to social engineering
attacks by attempting to acquire a user name and password from an unsuspecting
employee.
●
A drill or a simulation of a data center disaster. Measure the production time lost
and the time taken to recover.
●
A simulation of a malicious virus attack. Measure the time required to recover one
computer. This time factor can then be multiplied by the number of computers
infected in the system to ascertain the amount of downtime or loss of productivity.
It is also a good idea to involve an incident response team in this process, because a
team is more likely than an individual to spot all of the different types of damage that
have occurred. An incident response team manages the prioritization of security incidents
and the escalations paths to resolve them.
Determining Vulnerabilities or Weaknesses That an Attack Can Exploit
If the vulnerabilities that a specific attack exploits can be discovered, current security
policies and controls can be altered or new ones implemented to minimize the
vulnerabilities. Determining the type of attack, threat, and method makes it easier to
discover existing vulnerabilities. This can be proved by performing a penetration test.
Security Risk Planning and Scheduling
For each exploit method, your organization's security plan should include both proactive
and reactive strategies.
The proactive or pre-attack strategy is a set of steps that helps to minimize existing
security policy vulnerabilities and develop contingency plans. Determining the damage
that an attack will cause on a system and the weaknesses and vulnerabilities exploited
during the attack helps in developing the proactive strategy.
The reactive strategy or post-attack strategy helps security personnel to assess the
damage caused by the attack, repair the damage or implement the contingency plan
developed in the proactive strategy, document and learn from the experience, and get
business functions back up and running as soon as possible.
Proactive Strategy
The proactive strategy is a set of predefined steps that should be taken to prevent attacks
before they occur. The steps include looking at how an attack could possibly affect or
damage your computer system and the vulnerabilities that it exploits (steps 1 and 2). The
knowledge gained in these assessments can help in implementing security policies that
will control or minimize the attacks. The following are the four steps of the proactive
strategy:
1. Determine the damage that the attack will cause.
2. Determine the vulnerabilities and weaknesses that the attack will exploit.
3. Minimize the vulnerabilities and weaknesses determined for this specific attack
defined in the first two steps.
4. Determine the appropriate level of countermeasures to implement.
Following these steps to analyze each type of attack will produce a side benefit: a pattern
will begin to emerge showing overlapping factors of different attacks. This pattern can be
helpful in determining the areas of vulnerability that pose the greatest risk to the
enterprise.
Note: It is also necessary to balance the cost of losing data versus the cost of
implementing security controls. Weighing these risks and costs is part of a system risk
analysis.
39
Reactive Strategy
A reactive strategy is implemented when the proactive strategy for the attack has failed.
The reactive strategy defines the steps that must be taken during or after an attack. It
helps to identify the damage that was caused and the vulnerabilities that were exploited
in the attack. A reactive strategy also determines why the attack took place, how to repair
the damage that was caused by it, and how to implement a contingency plan.
Both the reactive and proactive strategies work together to develop security policies and
controls to minimize attacks and the damage they cause. The incident response team
should be included in the steps taken during or after the attack to help assess, document,
and learn from the event.
The following three steps are involved in the reactive strategy:
1. Limit the damage.
Containing the damage that was caused during the attack enables limiting the
amount of further damage. For example, if you get a virus in your environment, you
try to limit the damage as soon as possible by disconnecting the servers from the
network, even before you figure out how many servers may be affected. This
should be done as swiftly as possible
2. Assess the damage.
Determine the damage that was caused during the attack. This should be done as
swiftly as possible so that restoring your organization's operations can begin as
soon as possible. If it is not possible to assess the damage in a timely manner, a
contingency plan should be implemented so that normal business operations and
productivity can continue.
3. Determine the cause of the damage.
To determine the cause of the damage it is necessary to understand what
resources the attack was aimed at and what vulnerabilities were exploited to gain
access or disrupt services. Review system logs, audit logs, and audit trails. These
reviews often help in discovering where the attack originated in the system and
what other resources were affected.
4. Repair the damage.
It is very important that the damage be repaired as quickly as possible to restore
normal business operations and any data lost during the attack. The organization's
disaster recovery plans and procedures should cover the restore strategy. The
incident response team should also be available to handle the restore and
recovery process, and to provide guidance on the recovery process. During this
process, contingency procedures are executed to limit further spread of the
damage and isolate it.
40
Contingency Plan
A contingency plan is an alternative plan that is developed in case an attack penetrates
your system and damages data or other assets resulting in a disruption of normal
business operations or a slowdown in productivity. The contingency plan is followed if the
system cannot be restored in a timely manner. Ultimately, the goal is to maintain the
availability, integrity, confidentiality, and availability of data — your contingency plan is
equivalent to a "Plan B."
Contingency plans should be created to address each type of attack and threat. Each
plan should contain a set of steps to be taken in the event of an attack. The contingency
plans should consistently:
●
Address who must do what, when, and where in order to keep the organization
running.
●
Be rehearsed periodically to keep staff up to date with current contingency steps.
●
Cover restoring information from backup servers.
●
Entail updating virus software, service packs and hotfixes.
●
Cover procedures to move your production servers to another location. If funding is
available, production server replications should be collected at strategic
contingency locations.
●
Include a post mortem review of current security policies and contingency plans.
The following points outline the various evaluation tasks that should be conducted when
developing your contingency plan:
●
Evaluate your organization's security policies and controls to take advantage of
any opportunities to minimize vulnerabilities. The evaluation should address your
organization's current emergency plan and procedures, and their integration into
the contingency plan.
●
Evaluate current emergency response procedures and their effect on business
operations.
●
Develop planned responses to attacks and integrate them into the contingency
plans, noting the extent to which they are adequate to limit damage and minimize
the impact of an attack on data processing operations.
●
Evaluate backup procedures, including the most recent documentation and
disaster recovery tests, to assess their adequacy and include the results from the
evaluations in the contingency plans.
41
●
Evaluate disaster recovery plans to determine whether the steps they entail are
adequate to provide a temporary or long-term operating environment. Disaster
recovery plans should include testing your organization's required levels of security
so that security personnel can determine whether they can continue to enforce
security throughout the process of recovery, temporary operations, and the move
back to your organization's original processing site or to a new one.
●
Draw up a detailed document outlining the various findings required to carry out
the above tasks. This document should list:
●
Details on user scenarios to test the contingency plans.
●
Details on the impact that dependencies, such as obtaining assistance from
outside the organization and essential resources, will have on the contingency
plans.
●
A list of priorities observed in the recovery operations and the rationale used to
establish them.
●
Details on escalation paths so that when a contingency plan is executed, any
issues that may arise from it will clearly escalate to the most effective IT or
business operations personnel.
Implementation
Be careful not to implement controls that are too stringent, because the availability of
information could then become a problem. There must be a careful balance between
security controls and access to information.
Simulation Attack Testing
The last element of a security strategy, testing and reviewing the test outcomes, is
carried out after the reactive and proactive strategies have been put into place.
Performing simulation attacks on a test or lab system makes it possible to assess where
the various vulnerabilities exist, and then adjust your organization's security policies and
controls accordingly.
These tests should not be performed on a live production system, because the outcome
could be disastrous. Yet, the absence of labs and test computers due to budget
restrictions might preclude simulating attacks. In order to secure the necessary funds for
testing, it is important that management is aware of the risks and consequences of an
attack, as well as the security measures that may need to be taken to protect the system,
including testing procedures. If possible, all attack scenarios should be physically tested
and documented to determine the best possible security policies and controls to be
implemented.
Certain attacks, such as natural disasters, cannot be tested, although a simulation will
help. For example, a fire could be simulated in the server room resulting in all the servers
within it being damaged and lost. This disaster scenario can be useful for testing the
responsiveness of administrators and security personnel, and for ascertaining how long it
will take to get the organization running again.
Adjusting security policies and controls based on the test results is an iterative process.
The process is never finished and should be evaluated and revised periodically so that
improvements can be implemented.
42
Operate
A clearly defined path of escalation and problem management are the essentials of an
Incident Response program. By consistently executing the Incident Response plan early
in the security project, teams have greater effectiveness at resolving problems throughout
your enterprise. Documenting outcomes and learning from your security project are
beneficial for everyone moving forward with new projects. Collecting these types of
lessons learned in the operational processes make the assessment, development, and
implementation tasks for the next security project easier to complete.
Incident Response
If your organization wants to fully implement security planning best practices, this calls for
creating an incident response team. The incident response team should be involved in
the proactive efforts to ensure system security, which include:
●
Developing incident handling guidelines.
●
Preparing paths and procedures of escalation to law enforcement for computer
crimes.
●
Identifying software tools for responding to incidents and events.
●
Researching and developing other computer security tools.
●
Conducting training and awareness activities.
●
Performing research on viruses.
●
Conducting system attack studies.
These efforts will provide knowledge that the organization can use to address issues
before and during incidents.
A security administrator should be in a position to monitor and manage security audits for
the organization as needed. The security administrator should be the authority — a
person or group of people — responsible for implementing the security policy for a
security domain. After the security administrator and incident response team have
completed these proactive functions, the administrator should turn over the responsibility
for handling incidents to the incident response team.
This does not mean that the security administrator should not continue to be involved as
a part of the team. The security administrator may not always be available, though, so the
incident response team should be able to handle incidents on its own. The team will be
responsible for responding to incidents and should also be involved in analyzing any
unusual events that may involve computer or network security.
Document and Learn
It is important that once an attack has taken place, it is documented. Documentation
should cover all aspects of the attack that are known, including the damage the attack
caused (hardware, software, data loss, loss in productivity), the vulnerabilities and
weaknesses that were exploited during the attack, the amount of production time lost, the
procedures taken to repair the damage, and the cost of repair efforts. Documentation will
help to modify proactive strategies to prevent future attacks and minimize damages.
43
Implement Contingency Plans
If contingency plans already exist, they can be implemented to save time and to keep
business operations running smoothly. If no contingency plan exists, develop an
appropriate plan based on the documentation from the previous step.
Review Outcomes and Perform Simulations
After the attack or after defending against it, review the outcome with respect to the
system and the proactive strategy for your organization. The review should include
details on loss in productivity, data or hardware lost, and the time taken to recover from
the attack. You should perform simulations in a test environment, which are similar to the
production environment to produce the best results.
Review and Adjust Policy Effectiveness
If policies exist for defending against an attack that has taken place, they should be
reviewed and checked for effectiveness. If no policies exist, new ones must be drawn up
to minimize or prevent future attacks.
When the effectiveness of existing policies is not up to standard, they should be adjusted
accordingly. Updates to policies must be coordinated by the relevant managerial
personnel, security administrator, IT administrators, and the incident response team. All
policies should comply with the organization's general rules and guidelines. For example,
your organization's standard working times might be from 8 A.M. to 6 P.M. A security
policy could be updated or be created specifying that users may log on to the system only
during this time frame.
44
Security Risk Management Discipline
The following sections draw upon proven practices from security analysis methodologies
in use today that leverage MSF and MOF. MSF offers guidance in the planning, building,
stabilizing, and deploying phases of the project life cycle in the areas of enterprise
architecture and infrastructure deployment. MOF provides advice on how to develop or
improve management systems for information technology (IT) operations. The Security
Risk Management Discipline (SRMD) is defined in detail here which provides learning
that can be applied in your environment. The SRMD is a detailed process that is useful in
determining which threats and vulnerabilities have the most potential impact on a
particular organization
Identifying Security Risks
Security risk identification is the first step in assessing your organization’s security. In
order to effectively manage the security risk, it must be stated clearly so that the project
team can come to consensus and move on to analyzing the consequences and creating
a plan of action to address the risk. Although the scope of security risk is limited to the
technology that your project team is trying to secure, the team focus should be expansive
enough to address all sources of security risks including technology, process,
environment, and people.
Brainstorming is one way to identify security risks, and there are many sources of
information on security issues on the Internet. Your organization may also have an
existing vulnerability assessment or penetration test that can be reviewed to attack
surface security risks.
Goals
The goal of the security risk identification step is for the team to create a list of known
security risks that place your organization’s assets in a vulnerable position. This list
should be as comprehensive as possible, covering all views of the enterprise architecture
including technology, business, people, and strategy.
Risk management is the process of identifying risks, analyzing the risks, and creating a
plan to manage them. A security risk is defined as the expected loss due to, or as an
impact of, anticipated threats in light of system vulnerabilities and the strength and
determination of relevant threat agents.
Inputs
The inputs for the security risk identification step include gathering available knowledge
of threats; creating a list of current exploit methods and techniques; and analyzing
system and policy vulnerabilities that can potentially be exploited to cause harm to your
organization’s assets. Threats include any outside potential dangers to information and
systems. Vulnerabilities are the software, hardware, or procedural weaknesses that
provide the threat a point of attack. These risks often stem from differing views of the
enterprise environment including business practices, applications, data, and
infrastructure architecture.
The experience of your team, your organization's current approach toward security
planning in the form of policies, procedures, guidelines, templates, and information on the
current state of the organization's technology infrastructure, will aid in determining the
inputs for this step.
45
The security team may draw upon inputs obtained from the assets themselves or from
the results of a tool used to conduct a vulnerability analysis or penetration test. Group
brainstorming, facilitated sessions, and even formal security workshops to collect
information on team and stakeholder perceptions of security issues will prove useful to
obtain inputs.
Risk Identification Activities
During the security risk identification step, the team seeks to create an unambiguous
statement or list of security issues by clearly articulating the risks that your organization
faces. It is helpful to organize a series of security team workshops or brainstorming
sessions to identify the risks associated with a new situation.
Due to the rapid change of technology and environments, it is important that security risk
identification is not treated as a one-time activity — the process should be repeated at
periodic intervals during the operations life cycle of your organization.
Structured Approach
The use of a structured approach toward security risk management is essential because
it allows all team members to use a consistent mechanism for treating security issues.
The use of threat classification during this step is a helpful way to provide a consistent,
reproducible, and measurable approach.
Threat Classification
Threat classifications (also known as categories or taxonomies) serve multiple purposes
for a security team. During risk identification, they can be used to stimulate thinking about
security risks arising within different areas. During brainstorming sessions, classifications
can also ease the complexities of working with large numbers of threats by providing a
convenient way for grouping similar threats together. Threat classifications also may be
used to provide a common terminology for the team to use to monitor and report risk
status throughout the project.
Security Risk Statement
A security risk statement is a natural language expression of the causal relationship
between the existing security state of the organization and a potential, unrealized security
result.
The first part of the security risk statement is called "the condition," which provides the
description of an existing state or potential threat that the team feels may cause some
harm. The second part of the risk statement is called the "consequence," which describes
the undesirable loss of confidentiality, integrity, and availability to an asset.
The two statements are linked by a term such as “then” or “may result in” that implies an
uncertain (in other words, less than 100 percent) or causal relationship.
The following introduces the risk statement used in this guide:
IF a Threat Agent uses a tool, technique, or method to exploit a Vulnerability, THEN a
loss of (confidentiality, integrity, or availability) to an Asset may result in an impact.
Security risk statements are developed through risk analysis. There are two types of risk
analysis approaches: qualitative, and quantitative. Neither the qualitative nor quantitative
approach is superior to the other — they each provide a valuable tool for structuring your
risk identification activities. The quantitative approach builds upon information collected in
the quantitative process.
46
Figure 3.2
Security condition and consequence risk statement
The following steps detail each part of the process of the figure above:
1. Define a condition and consequence risk statement for each threat.
If a threat agent gives rise to a threat and exploits a vulnerability, then the attack
leads to a risk. The attack can damage the asset by degrading confidentiality,
integrity, or availability. Therefore, the attack causes an exposure to company
losses. However, these exposures can be counter measured by safeguards.
2. Assign a threat probability (TP) (0% lowest – 100% highest). The threat probability
is the probability of a possible threat agent entering your environment.
3. Assign a criticality factor (CF) (1 lowest – 10 highest). The criticality factor is the
level of potential exploit of the threat to an asset.
4. Rank the effort (E) (1 lowest – 10 highest). The effort represents the skills required
for an attacker to take advantage of the exploit.
5. Determine the risk factor (RF). This is the criticality factor divided by effort.
6. Determine the threat frequency level using the equation (TP × RF).
7. Rank the vulnerability factor (VF) (1 lowest – 10 highest). Decide how big of a risk
the vulnerability will be to an asset.
47
8. Determine the asset priority (AP) (1 lowest – 10 highest). Determine the asset
priority ranking of each company asset based on the following criteria. Asset
valuation is an involved process and can take time to perfect. For more information
about asset valuation, see references on this subject at the end of this chapter.
Prioritizing your organization's assets is crucial to determining how many assets
can be secured with the available budget.
To help you formulate a list of prioritized assets, research answers to the following
questions on each asset based on the environment in your organization:
●
What is the value of the asset to the company?
●
How much does the asset cost to maintain or protect?
●
How much does the asset make in profits for the company?
●
How much would the asset be worth to the competition?
●
How much would the asset cost to recreate or recover?
●
How much did the asset cost to acquire or develop?
9. Determine the impact factor (IF) using the equation (VF × AP).
10. Determine the exposure factor (EF) using the equation (Threat Frequency Level ×
Impact Factor divided by 1,000). The exposure factor is expressed as a percentage
in order to calculate single loss expectancy (SLE) in the steps that continue under
Table 3.2.
The two-part formulation process to produce security risk statements has the advantage
of coupling the potential consequences to an asset with the observable (and potentially
controllable) conditions within your organization that currently exist. Alternative
approaches in which the team focuses only on identifying security risk conditions may
require the team to retrace the risk condition later in the security risk analysis process
when security risk management planning strategies are created.
Note: Security risk statements are not pure “if-then” statements; rather, they are
statements of fact exploring the possible but unrealized consequences of a risk.
It may be helpful to consider hypothetical “if-then” statements to weigh alternatives and
formulate plans using decision trees. However, your goal during the security risk
identification phase is simply to identify as many security risks as possible. Defer how to
analyze and manage them until later on in the process.
The security risk statement that you create must include conditions and consequences.
As part of a thorough security risk analysis, team members should look for similarities
and natural groupings of security issue conditions, and then retrace the relationships of
each to seek a common underlying root cause. It is also valuable to retrace the
relationships downstream from the root cause of the condition once it is known. This will
examine effects on the assets outside the organization to gain a better appreciation for
the total losses or missed opportunities associated with the security threat.
During security risk identification, it is not uncommon for the same condition to have
multiple consequences associated with it. However, the reverse also may be true — there
may be several conditions that all produce the same consequence. Sometimes the
consequence of a security risk identified in one area of the organization may become a
risk condition in another. These situations should be recorded so that appropriate
decisions can be made during security risk analysis and planning to take into account
dependencies and relationships between the security risks.
48
Depending on the relationships of the security risks in your organization, mitigating one
risk may result in mitigating an entire group of dependent risks and in this way change
the overall risk profile for your organization. Documenting these relationships early during
the security risk identification phase can provide useful information for guiding effective
security risk planning that is flexible, comprehensive, and efficient at examining resources
to address root or downstream causes. For the most important security risks, the benefits
of capturing such additional information at the identification step should be balanced
against rapidly moving through the subsequent analysis and prioritization, and then reexamining dependencies and root causes during the planning phase.
Valuing Assets in Your Organization
Determining the monetary value of an asset is an important part of risk management.
Business managers often rely on the value of an asset to guide them in determining how
much money and time should to spend securing it. Many organizations maintain a list of
asset values as part of their disaster recovery plans. Using the following valuation model
will help your organization to determine how to prioritize your assets as detailed in Step 8
of the quantitative analysis.
To assign a value to an asset appropriately, calculate the following three primary factors:
●
The overall value of the asset to your organization. Calculate or estimate the
asset’s value in direct financial terms. For example, if you have an e-commerce
Web site that normally runs seven days a week, 24 hours a day, and it generates
an average of $2,000 per hour in revenue from customer orders, you can state with
confidence that the annual value of the Web site in terms of sales revenue is
$17,520,000.
●
The immediate financial impact of losing the asset. If the same Web site becomes
unavailable for six hours, the calculated exposure is .000685 percent a year. By
multiplying this exposure percentage by the annual value of the asset, you can
predict that the directly attributable losses in this case would be $12,000.
●
The indirect business impact of losing the asset. In this example, the company
estimates that it would spend $10,000 in advertising to counteract the negative
publicity from such an incident. Additionally, the company also estimates a loss of
.01 of 1 percent of annual sales, or $17,520. By combining the extra advertising
expenses and the loss in annual sales revenue, you can predict a total of $27,520
in indirect losses in this case.
Table 3.1: Asset Valuation Example
Asset
Value
Exposure
Factor
Direct
Impact
Indirect
Impact
E-commerce
Web site
$17,520,000
per year
Six hours per
year or .000685
$12,000
$27,520
You should also consider the value of the asset to your competitors. For example, if your
competitors are able to use previously acquired customer information from your Web site
while your site is down, you could lose millions in revenue to your competitors.
There are many methods and equations that could be used to perform a quantitative risk
analysis and many different variables that can be inserted into the process. However, the
following are additional steps that continue from step 10 above to achieve a successful
quantitative security risk analysis:
49
1. Determine the single loss expectancy (SLE). This is the total amount of revenue
that is lost from a single occurrence of the risk. The SLE is a dollar amount that is
assigned to a single event that represents the company’s potential loss amount if a
specific threat took place. Calculate the SLE by multiplying the asset value (AV) by
the exposure factor (EF). The SLE is similar to the impact of a qualitative risk
analysis.
Determine the SLE using the equation (AV × EF).
The exposure factor represents the percentage of loss that a realized threat could
have on a certain asset. If a Web farm has an asset value of $150,000, and a fire
results in damages worth an estimated 25 percent of its value, then the SLE in this
case is $37,500. This figure is derived to be inserted into the ALE equation in step
3.
2. Determine the annual rate of occurrence (ARO). The ARO is the number of times
that you reasonably expect the risk to occur during one year. To estimate the ARO,
draw on your past experience and consult risk management experts, as well as
security and business consultants. The ARO is similar to the probability of a
qualitative risk analysis. The ARO range extends from 0 percent (never) to 100
percent (always).
For example, if a fire at the same company’s Web farm results in $37,500 in
damages, and the likelihood, or ARO, of a fire taking place has a ARO value of 0.1
(indicating once in ten years), then the ALE value in this case is $3,750 ($37,500 x
0.1 = $3,750).
3. Determine the annual loss expectancy (ALE). The ALE is the total amount of
money that your organization will lose in one year if nothing is done to mitigate the
risk. Calculate this value by multiplying the SLE and the ARO. The ALE is similar to
the relative rank of a qualitative risk analysis. Determine the ALE using the
equation (ARO × SLE).
The ALE provides a value that your company can work with to budget what it will
cost to establish controls or safeguards to prevent this type of damage — in this
case, $3,750 or less per year — and provide an adequate level of protection. It is
important to quantify the real possibility of a risk and how much damage, in
monetary terms, that the threat may cause in order to know how much can be
spent to protect against the potential consequence of the threat.
4. Estimate the cost of countermeasures or safeguards using the following equation:
(ALE before countermeasure) – (ALE after countermeasure) – (annual cost of
countermeasure) = value of safeguard to company (VSC)
For example, the ALE of the threat of an attacker bringing down a Web server is
$12,000, and after the suggested safeguard is implemented the ALE is valued at
$3,000. The annual cost of maintenance and operation of the safeguard is $650,
so the value of this safeguard is $8,350 each year as expressed in the following
equation: ($12,000 - $3,000 - $650 = $8,350).
The input items from the quantitative risk analyses provide clearly defined goals and
results. The following short list defines what generally is derived from the results of the
previous steps:
50
●
Assigned monetary values for assets.
●
A comprehensive list of significant threats.
●
The probability of each threat occurring.
●
The loss potential for the company on a per-threat basis over 12 months.
●
Recommended safeguards, countermeasures, and actions.
Outputs
The minimum output from the security risk identification activities is a clear,
unambiguous, consensus statement of the risks being faced by the security team that is
documented as the security issues list. The security issues list, in tabular form, is the
main input for the next phase of the Security Risk management process — analysis.
The security risk identification step frequently generates a large amount of other useful
information, including the identification of root causes and downstream effects, affected
parties, owners, and so forth.
It is considered a good practice to a keep tabular record of the security risk statements
and the root cause and downstream effect information that the security team develops.
Additional information for classifying the security risks by threat may also be helpful when
using security risk information to build or use a security knowledge base if a well – defined
taxonomy exists for your organization.
Other information that the security team may want to record during the risk identification
process includes:
●
Constraints
●
Circumstances
●
Assumptions
●
Contributing factors
●
Dependencies among security risks
●
Related issues
●
Business asset owners
●
Team concerns
Analyzing and Prioritizing Security Risks
Security risk analysis and prioritization is the second large step in the security
assessment process. Security risk analysis involves converting security risk data (threats,
exploits, and vulnerabilities) into a form to facilitate decision – making. Security risk
prioritization ensures that the security team members address the most important
security risks first.
During this step, the security team examines the security issue list items produced in the
security risk identification step to prioritize them and form a Security Action Plan.
In the Security Action Plan, your organization's security team can use the list of security
issues to plan and commit resources to execute a specific strategy aimed at managing
the issues in your environment.
The team can also identify which security issues, if any, are of such low priority for action
that they may be dropped from the list. As this security implementation phase moves
toward completion, and as the environment of your organization changes, security risk
identification and security risk analysis must be repeated to validate the effectiveness of
the Security Action Plan. New security risks may appear, and old security risks that no
longer carry a sufficiently high priority may be removed, discounted, or “deactivated”.
Goal
The primary goal of the security risk analysis step is to prioritize the security issues in the
Security Action Plan to determine which ones warrant committing the organization’s
resources in order to mitigate them.
51
Inputs
During the risk analysis process, the team will draw upon its own experience and
information derived from other relevant sources regarding the security risk statements.
Refer to your organization’s security policies and procedures, industry knowledge
security databases, vulnerability analysis, security simulations, and the individual asset
owners for information on how to transform the raw security risk statements into a
prioritized master risk list.
Security Risk Analysis Activities
Many qualitative and quantitative techniques exist for accomplishing the prioritization in a
Security Action Plan. An easy technique for security risk analysis is to use consensus
team estimates derived from two widely accepted components of risk: probability and
impact. These estimate values can then be multiplied together to calculate a single metric
called risk exposure.
Security Risk Probability
Security risk probability is a measure of the likelihood that the state of affairs described in
the risk condition portion of the security risk statement will actually occur. Your risk
statement may include factors outside of time or money for your company, such as those
described in the following portion of the risk statement:
"IF a Threat Agent uses a tool, technique, or method to exploit a Vulnerability…"
The threat using an exploit to take advantage of a vulnerability is the condition portion of
the risk statement. For certain types of threats, there may not be an exploit or a known
vulnerability, especially when the threat is a natural disaster.
Using a numerical value for risk probability is desirable for ranking risks. If the security
risk probability is not greater than zero, then the threat does not pose an issue to
security. If the probability is 100 percent, then the security risk is a certainty and may be a
known issue.
Probabilities are notoriously difficult to estimate and apply, although industry or enterprise
risk databases may be helpful in providing known probability estimates based on samples
of large numbers of projects. However, because project teams can verbalize their
experiences in natural language terms, it may be useful to map these terms back to
numeric probability ranges as expressed in the following table.
Table 3.2: Risk Probability
Range
52
Calculation Value
Expression
Score
1% through 14%
7%
Extremely unlikely
1
15% though 28%
21%
Low
2
28% through 42%
35%
Unlikely
3
43% through 57%
50%
50 – 50
4
58% through 72%
65%
Probably
5
73% through 86%
79%
Highly likely
6
87% through 99%
93%
Almost certainly
7
The probability value used for calculation represents the midpoint of a range. With the aid
of these mapping tables, an alternative method for quantifying probability is to map the
probability range or natural language expression agreed upon by the team to a numeric
score. When using a numeric score to represent security risk, it is necessary to use the
same numeric score for all security risks for the prioritization process to work effectively.
No matter what technique is used for quantifying uncertainty, the team will also need to
develop an approach for deriving a single value for risk probability that represents its
consensus view regarding each risk.
Security Risk Impact
Risk impact is an estimate of the severity of the loss due to the adverse effects on the
assets, or the magnitude of a loss resulting in an asset losing confidentiality, integrity, or
availability. It should be a direct measure of the security consequence as defined in the
second half of the security risk statement:
"…THEN a loss of (confidentiality, integrity, or availability) to an Asset may result in an
impact."
Loss can either be measured in financial terms or with a subjective measurement scale
with respect to the asset. If all security risk impacts can be expressed in financial terms,
the use of financial value to quantify the magnitude of loss or opportunity cost has the
advantage of being familiar to business sponsors. The financial impact might be longterm costs in operations and support, loss of market share, short-term costs in additional
work, or opportunity cost.
In other situations, a subjective scale from 1 to 5 or 1 to 10 is more appropriate for
measuring security risk impact. An example of when a subjective scale might be used
would be a situation in which the appropriate net worth of the assets cannot be quickly
determined. As long as all security risks within a Security Action Plan use the same units
of measurement, simple prioritization techniques usually are good enough.
Table 3.3: Asset Lost Scoring System Example
Score
1
Monetary Loss
Under $100
2
$100 — $1,000
3
$1,000 — $10,000
4
$10,000 — $100,000
5
$100,000 — $1,000,000
6
$1,000,000 — $10 million
7
$10 million — $100 million
8
$100 million — $1 billion
9
$1 billion — $10 billion
10
Over $10 billion
The scoring system for estimating impact will vary among organizations and should
reflect your organization’s values and policies. For example, a $10,000 monetary loss
that is tolerable for one team or organization may be unacceptable for another. Scoring a
catastrophic impact with an artificially high value such as 100 will ensure that a risk with
even a very low probability will rise to the top of the risk list and remain there.
53
Security Risk Exposure
Risk exposure measures the overall security risk to the assets, combining information
expressing the likelihood of actual loss with information expressing the magnitude of the
potential loss into a single numeric estimate. The security team can then use the
magnitude of risk exposure to rank security issues. In the simplest form of quantitative
risk analysis, risk exposure is calculated by multiplying risk probability and impact.
When scores are used to quantify probability and impact, it is sometimes convenient to
create a matrix that considers the possible combinations of scores and assigns them to
low, medium, and high risk categories. Using a tripartite probability score, where 1 is low
and 3 is high, and a tripartite impact score, where 1 is low and 3 is high, the results can
be expressed in the form of a table where each cell is a possible value for risk exposure.
In this arrangement, it is easy to classify risks as low, medium, and high depending on
their position within the diagonal bands of increasing score.
Table 3.4: Risk Scoring Matrix
Probability Impact
Low = 1
Medium = 2
High = 3
High = 3
3
6
9
Medium = 2
2
4
6
Low = 1
1
2
3
Exposure ranges: Low =1 – 2; Medium =3 – 4; High = 6 – 9
The advantage of this tabular format is that it allows security risk levels to be included
within status reports for sponsors and stakeholders using colors (red for the high risk
zone in the upper right corner, green for low risk in the lower left corner, and yellow for
medium levels of risk along the diagonal). An easy-to-understand, yet well-defined
terminology improves communicating these values in that “high risk” is easier to
comprehend than “high exposure.”
Additional Quantitative Techniques
Since the goals of security risk analysis are to prioritize security risks, drive a Security
Action Plan, and drive decision-making regarding commitment of resources toward
security management, your security team should select a method for prioritizing risks that
is appropriate to the project, team, and stakeholders.
Some organizations benefit from the use of weighted, multi-attribute techniques to factor
in other components that the team wants to consider in the ranking process, such as
required timeframe, magnitude of potential opportunity gain, reliability of probability
estimates, and physical or information asset valuation.
Selecting the “right” security risk analysis method or combination of methods depends on
making the right trade-off between the effort to perform the security risk analysis and
making an incorrect or indefensible (to stakeholders) prioritization choice in the Security
Action Plan. Security risk analysis should be undertaken to support prioritization that
drives decision making and should never become analysis for the sake of analysis.
The results from quantitative or semi-quantitative approaches to security risk prioritization
should be evaluated within the context of business guidelines, policies and procedures,
data, and technology infrastructures. A semi-quantitative approach begins with some sort
of qualitative measures to enable companies to come up with quantifiable security
measures.
54
Outputs
Security risk analysis provides your team with a prioritized security action list to guide you
in security risk planning activities. Detailed security risk information including conditions,
context, root causes, and the metrics used for prioritization (probability, impact, exposure)
are often recorded for each risk in the risk statement form, which is described in detail
later in this chapter.
Master Security Risk List
The list of key security risks for which an action plan must be created is defined in your
Security Action Plan. The Security Action Plan identifies the condition causing the
security risk, the potential adverse effect (consequence), and the criteria or information
used for ranking the risk, such as its probability, impact, and exposure. An example
master risk list using the two-factor (probability and impact) estimate approach is shown
here.
Table 3.5: Master Risk List and Prioritization Example
Priority
Condition
Consequence
Probability
Impact
Exposure
1
Virus infecting
e-commerce Web site
Six hours to
rebuild server.
80%
3
2.4
2
No coding standards for
new programming
language
Ship with
potentially more
security
vulnerabilities.
45%
2
0.9
3
No written specification
Some product
security features
not
implemented
30%
2
0.6
Exposure is calculated as probability x impact. Low impact = 1, medium impact = 2, and
high impact = 3.
The master security risk list is the compilation of all security risk assessment information.
It is a living document that forms the basis for the ongoing security risk management
process and should be kept up to date throughout the IT life cycle that includes
evaluating, planning, building, deploying, and operating.
The security master risk list is the fundamental document for supporting proactive or
reactive risk management. It enables team decision making by providing a basis for:
●
Prioritizing effort.
●
Identifying critical actions.
●
Highlighting dependencies.
The method that is used to calculate the exposure rendered by a risk should be
documented carefully in the risk management plan, and care should be taken to ensure
that the calculations accurately capture the intentions of the team, weighing the
importance of the different factors.
To identify threats to assets, you perform risk analyses. For each threat that you identify,
create a risk statement. Risk statements combine information about a threat with
information about the impact of the threat, should it occur.
55
Table 3.6: Master Security Risk List Contents
Item
Purpose
Status
Security Risk Statement
Clearly articulate risk.
Required
Probability
Quantify likelihood of threat occurrence.
Required
Impact
Quantify severity of loss or magnitude of
opportunity cost.
Required
Ranking criterion
Single measure of importance.
Required
Priority (rank)
Prioritize actions.
Required
Owner
Ensure follow through on risk action plans.
Required
Mitigation Plan
Describe preventative measures.
Required
Contingency Plan and Triggers
Describe corrective measures.
Required
Root Causes
Guide effective intervention planning.
Required
Downstream Effects
Ensure appropriate impact estimates.
Optional
Context
Document background information to capture
intent of team in surfacing risk.
Optional
Time to Implementation
Capture importance that risk controls are
implemented within a certain timeframe.
Optional
Risk Statement Form
When analyzing each individual security risk, or during security planning activities related
to a specific threat, exploit, or vulnerability, it is convenient to view all of the information
on that security risk in a document view, called the security risk statement form. For
further details on the processes of a security project, see the Microsoft Solution for
Security Services Guide.
A list of security risk statements typically contains the fields from the master security risk
list created during the identification and assessment phases and may be augmented with
additional information needed by the team during the security risk management process.
It may be easier to treat the list of security risk statements as a separate document from
the master risk list if the risks will be assigned to the security team for follow-up actions.
Information that the team should consider when developing a risk statement form include:
56
Table 3.7: Risk Statement Form
Item
Purpose
Security Risk Identifier
The name that the team uses to identify risk uniquely for
reporting and tracking purposes.
Security Risk Source
A broad classification of the underlying area from which the
security risk originates. Used to identify areas where recurrent
root causes of the security risk should be sought.
Security Risk Condition
(Threat/Exploit)
A phrase describing the existing condition that might lead to a
loss. This forms the first part of a security risk statement.
Risk Consequences
(Vulnerability/Impact to
Asset)
A phrase describing the loss that would occur if a risk
produces a consequence. This forms the second part of a
security risk statement.
Security Risk Probability
A probability greater than zero and less than 100 percent that
represents the likelihood that a risk condition will actually
occur, resulting in a loss.
Asset Impact Classification
A broad classification of the type of impact that a risk might
produce.
Asset Exposure
The overall threat of the risk, balancing the likelihood of actual
loss with the magnitude of the potential loss. The team uses
risk exposure to rate and rank risks. Exposure is calculated by
multiplying risk probability and impact.
Risk Context
A paragraph containing additional background information that
helps to clarify the security risk situation.
Related Security Risks
A list of risk identifiers that the team uses to track
interdependent risks.
Top Security Risks List
Security risk analysis weighs the threat of each security risk to help the security team
decide which of the issues merit action. Because managing security and the planning
associated with it takes time and effort away from other activities, it is important for the
security team to do what is absolutely necessary to protect the most valuable assets.
A simple but effective technique for monitoring the security risks is to create a top
security risks list of the major security issues. The top security risks list may then be
made externally visible to all stakeholders for use in other active IT projects where
security may be affected.
Your organization has to determine what goes on the top security risks list based on
several factors including time, resources, and assets. Once you have selected a number
of major security risks that must be managed, you must allocate team resources to
develop plans around them.
After ranking the security risks, the team should focus on a security risk management
strategy and how to incorporate the security action plans into the overall security
assessment plan.
57
Deactivating Security Risks
Security risks may be deactivated or classified as inactive so that the team can
concentrate on other issues that require more proactive active management. Classifying
a security risk as inactive means that the assessment team has decided that it is not
worth the effort needed to track that particular threat at this particular time. The decision
to deactivate a security risk is taken during the security risk analysis.
Some security risks are deactivated because their threat probability is effectively zero
and likely to remain so because they have extremely unlikely conditions. Other security
risks are deactivated because their impact to the assets is below the threshold where it is
worth the effort to plan a proactive mitigation or reactive contingency strategy. In these
cases, it is simply more cost-effective to suffer the potential consequences of these
security risks.
It may not be advisable to deactivate security risks above this asset impact threshold
even if their exposure is low, unless the security team is confident that the probability
(and hence the exposure) will remain low in all foreseeable circumstances. Remember
that deactivating a security risk is not the same as resolving one. A deactivated security
risk may reappear under certain conditions, and the security team may choose to
reclassify the risk as active and reinitiate security risk assessment activities.
58
Security Risk Tracking, Planning, Scheduling, and
Reporting
Tracking the security risks that have been identified in the Security Action Plan and then
implementing a plan, a schedule and a reporting process to remediate them are the next
steps in the process. Based on the priorities identified in the previous step, the team will
make changes proactively by modifying the technology infrastructure and implementing
new security procedures and processes.
When a risk exists that cannot be proactively managed, a reactive plan is generated that
is executed when an event is triggered. After the plans are created, an implementation
schedule for the proposed modifications is produced. Finally, team members are
assigned various remediation tasks to address.
Scheduling involves the integration of the tasks required to implement the security action
plans into the assessment project schedule by assigning them to individuals and actively
tracking their status.
Reporting consists of redefining risks that have changed because the project and
processes have changed in scope or definition. This type of reporting is also known as
risk change management. Reporting also consists of closing security risks from the top
number of managed risks within a project. The following figure depicts this entire step
graphically.
Figure 3.3
Risk tracking, planning, scheduling, and reporting
Goals
The main goal of the security risk planning and scheduling step is to develop detailed
action plans for controlling the top security risks identified during the security risk
analysis, and then to integrate them with the standard project management processes to
ensure that they are completed.
59
Inputs
Security risk planning should be tightly integrated into the standard project planning
processes and infrastructure. It is important to note that there are risks associated with
the security assessment project itself, but these risks are different than the actual security
risks themselves. The implementation of security action plans carries risk to the overall
project and should be managed using the methodology of the MSF Risk Management
Discipline. Project risks to implementing the Security Action Plan usually include time,
money, and resources.
Inputs to the security risk planning process include not only the master security risk list,
top security risks list, and information from the security knowledge base, but also the
security action plans and security implementation schedules.
Planning Activities
When developing plans to reduce asset exposure, you should:
●
Focus on high-exposure security risks.
●
Address the threat condition (threat, exploits) to reduce the probability.
●
Look for root causes of the security issue as opposed to symptoms.
●
Address the asset consequences (vulnerability and asset) to minimize the asset
impact.
●
Determine the root cause of the security issue, and then look for similar situations
that may affect the same, or other assets arising from the same cause.
●
Be aware of dependencies and interactions from threats, exploits, and
vulnerabilities among security risks.
There are several planning approaches to reducing different project risk conditions that
include the following:
60
●
For project risks that the team can control, apply the team resources needed to
reduce the probability of the threat condition. This is a proactive security risk
management approach.
●
For project risks outside the control of the team, find a potential workaround or
transfer (escalate) the security risk to individuals who have the authority to
intervene.
●
For project risks outside of the control of the team that cannot be transferred or
proactively managed, the team should develop plans to minimize the impact to or
the loss of the asset. This is a reactive security risk management approach.
Security Action Planning
There are six primary approaches to security action planning, and your team should
consider the questions associated with each listed here in brief when formulating your
security risk action plan. Each approach is defined in greater detail below.
●
Research. Does the security team know enough about this security risk? Do you
need to study the threat, exploit, vulnerability, or assets further to better determine
the characteristics of these components before deciding on an action?
●
Accept. Are you willing to accept the risk and do nothing proactive, with the
exception of making contingency plans? You might consider accepting a risk if the
ALE value for the asset is less than the value of the asset, and if the impact on
business is low. Can your organization live with the consequences if the security
risk actually occurs?
●
Avoid. Is there a way to avoid risk by eliminating the source of the risk or an
asset’s exposure to the risk? This is an extreme reaction to risk and should only be
done when the impact of the risk outweighs the benefit that is gained from the
asset. Can your organization avoid risks by changing the scope of the
implementation project?
●
Transfer. Is it possible for you to transfer risk by partially shifting the responsibility
for the risk to another party, such as an insurance or managed services company?
Transferring risk is becoming an increasingly important strategy for security. Can
your organization avoid the security risk by transferring it to another group, team,
individual, or external organization?
●
Mitigation. Can you mitigate risk by proactively changing the asset’s exposure to
the risk or changing your organization’s reliance on the asset? Consider a risk
mitigation strategy if the ALE is less than the value of the asset and you can take
proactive actions in advance. Mitigation is the primary risk management strategy.
Can you do anything to reduce the threat probability or asset impact of the security
risk?
●
Contingency planning. Can the impact be reduced through a planned incident
response? Properly constructed contingency plans will diminish the impact when a
risk becomes an issue or an incident. After the security incident, a trigger can be
used to properly execute a contingency plan.
Research
Much of the risk in security projects is related to uncertainties surrounding incomplete
information. Security risks that are related to a lack of knowledge may often be resolved
or managed effectively by learning more about the threat, exploit, vulnerabilities, or the
asset itself before proceeding.
For example, a team may choose to pursue a vulnerability assessment or conduct a
security drill to learn more about the environment or the team’s skills in reacting to a
security breach before completing the security implementation plan. If the decision by the
team is to perform research, then the Security Action Plan should include an appropriate
research proposal including the areas to be tested and the issues to be answered,
including staffing and any required equipment.
61
Accept
Some security risks, specifically threats that are related to natural disasters, are such that
it is simply not feasible to intervene with effective preventative or corrective measures.
Therefore, the security team may elect to simply accept the security issue. However,
proactive mitigation or reactive contingency plans should still be developed. An ongoing
commitment to monitoring a security risk should have appropriate resources and tracking
metrics established.
Note: Acceptance is not a “do-nothing” strategy. Your organization's Security Action
Plan should include a documented rationale for why the team has elected to accept the
risk.
Avoid
A security risk may be identified as one that can most easily be controlled by changing
the scope of the assessment. Changing the scope of the assessment in such a fashion to
“eliminate” the security risk all together is called avoidance technique. In these cases, the
Security Action Plan should include documentation of the rationale for such decisions,
and the security implementation plan should be updated with any needed design
changes or scope change processes.
Transfer
Sometimes it is possible for a security risk to be transferred to another entity outside of
the organization for management. Examples in which a security risk is transferred
include:
●
Insurance.
●
Using external consultants with greater expertise.
●
Outsourcing services.
Transferring the security risk does not mean that a risk has been eliminated. In general, a
transfer strategy will generate new security risks that still require proactive management,
but transferring the risk will reduce the threat to a more acceptable level. For instance,
outsourcing the IT infrastructure may transfer security risks outside of the security team
but may introduce new security risks with respect to confidentiality of the assets that your
organization is trying to protect.
Mitigation
Security risk mitigation involves taking proactive action to either prevent a security risk
from occurring or reduce the impact or consequences to an acceptable level. Proactively
managing security risk through mitigation differs from the avoidance approach because
mitigation focuses on prevention and minimization of threats to acceptable levels,
whereas security risk avoidance changes the scope of the assessment to prevent
activities from taking place that involve unacceptable risk.
The main goal of security risk mitigation is to reduce the probability of threat occurrence.
For example, using a strong password policy will reduce the probability of an external
user finding out a password to access the payroll system.
62
Contingency Planning
Security risk contingency planning involves creation of one or more incident response
plans that can be activated in case efforts to prevent an attack fail. It is good practice to
create contingency plans for all security risks, including those that have mitigation plans.
The reason for this is simple — no matter how well the organization develops proactive
security plans, an unknown threat, exploit, or vulnerability may still exist that can harm an
asset.
Security contingency planning must address what to do if the threat occurs, and it must
focus on the consequence and how to minimize the asset impact. Your team should
create incident response plans and business resumption plans to ensure that you can
react effectively during and after an attack.
You can establish trigger values for contingency plans based on the type of threat,
exploit, or vulnerability that may be encountered. For security, a trigger is usually an
event. This means there has to be a way of capturing that event and notifying the
appropriate response team to put the contingency plans into action.
There are two types of contingency plan triggers:
●
Point-in-time triggers. Point-in-time triggers are built around dates, generally the
latest date by which something has to take place. Dates may be set according to
organizational or legal guidelines that proscribe when certain security measures
must occur.
●
Threshold triggers. Threshold triggers rely on things that can be measured or
counted. For example, an audited event that is captured by an intrusion detection
system may warrant some examination and the possible activation of a
contingency plan.
It is important for your security team to agree with other teams in your organization
on contingency plan triggers and their associated metrics so that there is no delay
in executing the contingency plans.
Scheduling Activities
Scheduling security risk management and control activities does not differ from the
standard approach recommended by MSF toward scheduling project activities in general.
It is important that the security team understands that security remediation or control
activities are an expected part of security risk assessment and management.
Outputs
The output from producing the Security Action Plan should include both proactive and
reactive security management plans using one of the six approaches discussed above:
research, acceptance, avoidance, transfer, mitigation, or the development of contingency
plans. The specific tasks to implement these security plans should be integrated into the
standard security implementation schedules. If there are any changes to the technical
environment, these should be documented in a functional specification.
Your Security Action Plan and schedule should account for adjustments in committed
resources and scope, resulting in a set of security action items that specify the individual
tasks to be completed by security team members. The master security risk list should be
updated to reflect the additional information included in the proactive (mitigation) and
reactive contingency plans. It is convenient to summarize the security risk management
plans into a single document view in the security risk action form.
63
Updating the Security Implementation Schedule and Security
Implementation Plan
Your security implementation plans must include both proactive and reactive plans. When
updating your security implementation plan, consider the following:
●
The risk conditions, including the probability of risk occurrence and impact
Changing conditions, such as increased probability of a risk occurring or a
decreased financial impact of a risk, will require the team to update the risk
management plan.
●
The effectiveness of the mitigation effort
The team may find that some of its mitigation efforts are ineffective. Often, this
occurs when a technical policy is implemented that conflicts with business
processes. Employees sometimes subvert the technical policy by working around it
to achieve their business goals.
●
The effectiveness of contingency plans and triggers
Over time, security risks that are identified in the risk management plan will occur.
After the security incident, determine how effective the contingency plans were,
and whether the triggers for initiating responses were effective.
Your team should monitor security risks in the following three time frames:
64
●
Real-time. Use applications such as intrusion detection software to continuously
monitor computers and network devices, and to make predetermined decisions
based on the risk.
●
Periodic. Evaluate risk on a regularly scheduled basis, such as bimonthly or
quarterly.
●
Ad hoc. Evaluate risk at nonscheduled intervals. Ad hoc monitoring is often done
in response to a major security incident or change to the network.
Security Risk Remediation Development
The development of countermeasures and operational procedures are essential to the
security strategy for your organization. Security risks can be proactively managed either
through a technology hardening process or by developing organization-wide policies.
Often a default installation of an operating system, application, or database has security
settings relaxed to simplify matters for the IT administrator or software developer. Prior to
a production deployment of these technologies, the technology being deployed must be a
part of a “hardening process.” For details on hardening member servers and specific
server roles, see Chapter 6, "Hardening the Base Windows 2000 Server," and Chapter 7,
Hardening Specific Server Roles" in this guide.
The server hardening process may involve the removal of default security settings and
unnecessary software components. IT personnel should also stay current on known
technology vulnerabilities and current exploits to install the latest releases of software
and security hotfixes.
The security strategy development process also includes the development of systems,
policies, and procedures for the tracking and reporting of unrealized security risks. This
will help to ensure that the preventative measures in the technology infrastructure are
working, as well as validate the effectiveness of any new policies and procedures.
There also should be a reporting system in place to capture suspicious events or
potential threats that require immediate attention. In addition to an automated system for
security risk tracking, a manual process can also be used. Tracking security risks allows
the project team to make adjustments to plans to accommodate new security risks.
Tracking is the monitoring function of the risk action plan. Tracking is essential to
implementing security action plans effectively. Tracking ensures that preventative
measures or contingency plans are completed in a timely fashion and within project
resource constraints. During risk tracking, the principal activity performed by the team is
monitoring risk metrics and ensuring that events are triggered so that planned risk actions
go into effect.
Goals
The goal of the remediation development process is to document necessary architectural
changes as well as any new processes or changes in procedure.
Inputs
The principal inputs to the security risk remediation development process are the security
risk plans that contain the specific security mitigation and contingency plans that specify
the threats, exploits, and vulnerabilities for your organization's security risks. Remediation
development also requires that systems and processes are developed to monitor the
identified triggers for the contingency plans that may be executed.
65
Development Activities
The development activities in the security risk remediation process are similar to the
development activities in a typical infrastructure deployment project. For example, the
development of methods for change management for system patches. Design changes to
the infrastructure must be documented in a functional specification, and policies and
procedures may have to be modified to accommodate the new security requirements.
During this process, if new systems are implemented to provide monitoring and auditing
functionality, the design and management of those systems should be specified, as well.
Examples of project metrics that might be assigned point-in-time trigger metrics and
continuously tracked include:
●
Unresolved open security bulletins for an application, service, or operating system.
●
Average overtime hours logged per week by infrastructure engineers.
●
The number of requirement revisions or change management requests per week.
Risk status reporting procedures should also be developed at this phase. Risk reporting
should operate on two levels: for the team itself and for external reporting to the project
board.
For the security team, regular risk status reports should consider the following four
possible risk management situations that may apply to each risk:
●
A risk is resolved, completing the risk action plan. All resolved risk should be
documented as closed and archived in the Security Action Plan.
●
Risk actions are consistent and on schedule with the risk management plan.
●
Some risk actions are at variance to the risk management plan, in which case
corrective measures should be defined and implemented.
●
The risk situation has changed significantly with respect to one or more risks, and
therefore the risk action plan should be reformulated.
For external reporting to the project board and other project stakeholders, the team
should report the top risks and then summarize the status of risk management actions. It
is also useful to show the previous ranking of risks, and the number of times that each
risk has been in the top risk list.
As the project team takes actions to manage risks, the total risk exposure for the project
should begin to approach acceptable levels.
Outputs
The output of the remediation phase is the specification of any security changes that
must be updated in the following places:
66
●
Functional specification
●
Operational policies and procedures
●
Updated security implementation plans
●
Updated security implementation schedules
Security Remediation Testing
The security and remediation testing step is designed to ensure that the effectiveness of
the security plans are tested. The team should actively perform activities related to the
testing of both the proactive and reactive strategies (countermeasures and procedures)
to determine the effectiveness of the Security Action Plan.
To measure the effectiveness of newly developed countermeasures, policies, and
procedures, you should examine each risk that they are designed to address, and then
test the associated strategy for each risk with respect to threats, exploits, vulnerabilities,
and assets in your organization.
It may be necessary, based on security risk remediation testing, to modify your security
action plan to improve their effectiveness, validity, and responsiveness to security trigger
events.
The results and lessons learned from the execution of the security test plans are then
incorporated into a testing document to become part of the organization’s security
knowledge base. It is important to capture as much information as possible during testing
to determine the efficacy of these plans.
Goals
The goal of the security remediation testing process is to test the effectiveness of the
various security plans that the project team has created for the top security risks. The
security action plans should evaluate and test the following:
●
Contingency and mitigation plan effectiveness.
●
Security metrics associated with contingency plan triggers or events.
●
Technology countermeasures. This may include a second vulnerability assessment
to determine whether they have been implemented correctly.
Inputs
The inputs to the security risk control process are the security action forms that detail the
activities to be carried out by project team members to help address each security issue.
Testing results should document the effectiveness of the proactive and reactive plans to
determine whether they are appropriate to your organization’s security requirements.
Testing Activities
Security remediation testing activities should measure the effectiveness of each
countermeasure and incident plan developed. It is important to maintain continuous
security risk remediation testing to detect any new secondary security risks that may
appear because of new countermeasures.
Outputs
The output from the security remediation testing step is a result document or “issue
database” that can help document progress toward completing the implementation of the
security action plans for your organization. It is helpful for the testing team to also
summarize which security strategies worked, which did not work, and the effectiveness of
newly created polices and procedures.
67
Capturing Security Knowledge
The knowledge obtained during the security assessment and implementation process
should be captured for future use. This is the sixth and final phase of the security risk
assessment process, and one that adds a strategic, enterprise, or organizational
perspective to the security risk management activities.
Of primary importance is that the countermeasures, policies, and procedures that were
developed during this security assessment are captured for reuse by future project
teams. As your organization embarks on future IT initiatives, those projects can use the
knowledge gained from the assessment to ensure that the new solutions that are
implemented are secure.
The learning from your security risk assessment should be captured in a timely format to
provide the most up to date and current information. Capturing security knowledge
focuses on three key objectives:
●
Capturing lessons learned, especially concerning security risk identification and
successful mitigation strategies, for the benefit of other teams, thus contributing to
the security knowledge base.
●
Increasing the effectiveness of operational readiness in terms of the ability of your
organization to execute incident response plans and reuse them in other areas.
●
Improving the security risk assessment process by capturing feedback from the
team.
Capturing Security Risk Learning
Security risk classification is a powerful means of ensuring that lessons learned from
previous experience are made available to teams performing future security risk
assessments. The following are three key aspects of learning that are often recorded
using the following risk classifications:
1. New risks. If a team encounters an issue that had not been identified previously as
a security risk, it should review whether any signs (threats, exploits, vulnerabilities
or other indicators) may have predicted the security risk. It may be that the existing
security risk lists need to be updated to help with future identification of the security
risk condition. Alternatively, the team may have identified a new security risk that
should be added to the existing security knowledge base.
2. Successful mitigation strategies. Capture the experience of both successful and
unsuccessful strategies to mitigate security risks. The use of a standard security
risk classification provides a meaningful way to group related risks so that teams
can easily find details of security risk management strategies that have been
applied successfully in the past.
3. Successful contingency strategies. If a contingency plan works by protecting
against a specific type of vulnerability for one asset, it may be useful in protecting
another asset.
68
Managing Security Risk Learning
Organizations using security risk management techniques often find that they need to
create a structured approach to managing security risk. To facilitate this successfully, the
following three conditions should be met:
1. Share responsibility with individuals on your security team by giving ownership of
specific security risk classification areas with approval to make changes. The
decision regarding who should be given ownership is related to the type of asset
and the classification of the asset.
2. Balance your security risk classifications and the need for comprehensive
countermeasures against complexity and usability. Sometimes creating different
risk classifications for different project types can improve usability dramatically.
3. Maintain your security knowledge base to account for security risk classifications,
definitions, testing, monitoring effectiveness criteria, and metrics to capture user
and operational experience of the new security measures.
Context-Specific Security Risk Classifications
Security risk identification can be refined by developing risk classifications for specific
solutions implementations. For example, in an application development project there may
be specific security risk classifications for that project versus the security risk
classifications for an infrastructure deployment project. As more experience is gained
within the security context, security policies and procedures can be made more specific
and associated with successful mitigation strategies.
Security Knowledge Base
The security knowledge base is either a formal or informal mechanism used to archive
lessons in order to assist in future security risk assessment. Without some form of a
knowledge base, your organization may have difficulty adopting a proactive approach to
security management.
If there is a known set of threats, exploits, and vulnerabilities captured in this knowledge
base, it will be easier to develop a mitigation plan against them because of the captured
research. The security knowledge base differs from the security risk management
database, which is used to store and track individual security risk items, plans, and
status.
Developing Knowledge Management for Security Risks
The security risk knowledge base is the key driver of continual improvement in security
risk management.
At first, your organization's security project and process teams will likely not have a
knowledge base. Teams must start fresh every time they undertake a security risk
assessment. In this environment, the approach to security risk management is normally
reactive, after a breach or some event that triggers a project. In this situation, the goal is
for your organization to transition to the next higher level of active security risk
management.
69
Later, your organization may have developed an informal security knowledge base, using
the implicit learning gained by more experienced members who are either familiar with or
have subject matter expertise on the security issues with respect to people, process, and
technology. This is often achieved by implementing a security board. This approach
encourages active security risk assessment management and might lead to proactive
management through the introduction of security policies.
Reaching the first development level of the knowledge base comes through providing a
more structured approach to security risk identification. With the formal capturing and
indexing of security issues, your organization will be capable of much more proactive
management as the underlying causes of security risks start to be identified.
Finally, mature organizations record not only the indicators likely to lead to security risks,
but also the strategies adopted to manage those security risks and their success rates.
With this form of knowledge base, the security identification and planning steps of the
security risk process can be based on the shared experience of many teams, and your
organization can start to optimize the costs of security risk management.
When contemplating how to implement a security risk knowledge base for your
organization, experience has shown that:
70
●
The value of the security risk knowledge base increases as more of the work
becomes repetitive (such as focusing on other projects that impact security or ongoing operational processes).
●
When your organization is performing a similar security review, a less complex
knowledge base is easier to maintain.
●
Security risk management should not become an automatic process that obviates
the need for the team to think about security risks. Even in repetitive situations, the
business environment, the skills of attackers, and technology are always changing.
The security team must assess the appropriate security risk management
strategies for its environment based on the people, processes, and technology that
are in place.
Summary
This chapter has explained proven practices derived from security analysis methods and
processes formulated in the MSF and MOF. It detailed the processes used in the SRMD
to determine the cost of protecting the assets in your organization. Finally, it
recommended steps for forming a security team to create and execute security action
plans in order to prevent and react to attacks against your organization's environment.
More Information
For information on MSF, see: http://www.microsoft.com/business/services/mcsmsf.asp.
For information on MOF, see: http://www.microsoft.com/business/services/mcsmof.asp.
For information on computer crimes, see: http://www.gocsi.com/press/20020407.html.
For information on threat assessment, see: “Threat Assessment of Malicious Code and
Human Threats,” by Lawrence E. Bassham & W. Timothy Polk: National Institute of
Standards and Technology Computer Security Division, at http://csrc.nist.gov/.
For information on best practices in information security, see: http://www.iso-17799.com/.
For information on hacking, see: http://www.hackingexposed.com/.
For information on security threats from Microsoft TechNet, see:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bestprac/
bpent/sec1/secthret.asp.
For information on asset valuation from the National Institute of Standards and
Technology, see: http://csrc.nist.gov/asset/
71
4
Applying the Security Risk
Management Discipline
The Security Risk Management Discipline (SRMD) is a detailed process that is useful in
determining which threats and vulnerabilities have the most potential impact on a
particular organization. Because every company has different business requirements, it is
impossible to create one list of vulnerabilities that will have the same impact on every
environment.
The process for this is discussed in detail in Chapter 3, “Understanding the Security Risk
Management Discipline”. This chapter will apply this process to a generic customer. In
order to provide adequate background for this applied example, some high level details
will be provided regarding the target environment. At the conclusion of this chapter, the
specific risks addressed will be fully defined, described, and analyzed.
73
Scenario Overview
The solution revolves around a marketing research company named Contoso, Ltd.
Contoso has two offices: the headquarters located in Atlanta, Georgia, and a second
office located in Boston, Massachusetts. Contoso is a fairly large enterprise, with several
thousand employees who utilize computing resources. Contoso reported revenue of $829
million last year.
The company's infrastructure has been completely upgraded to Microsoft®
Windows® 2000 Server, but its client deployment remains in a mixed state. The company
currently has a combination of Microsoft® Windows 98 SR2, Microsoft® Windows NT®
Workstation version 4.0, Windows 2000, and Windows XP.
Administration Model
Contoso has segmented the administrative groups of the company into divisions that
focus on certain technologies. There is one group of administrators that oversees all
domain-wide administration, including the administration of domain controllers. There is
also a second group that manages the company's infrastructure services, such as
Windows Internet Name Service (WINS), Dynamic Host Configuration Protocol (DHCP),
and Domain Name Systems (DNS), as well as the file and print servers in the
organization.
Additionally, there is a Web services group that handles the administration of all Internet
Information Services (IIS) servers in the environment. IIS is Microsoft Web server
software that utilizes the Hypertext Transfer Protocol (HTTP) and the File Transfer
Protocol (FTP). The administrator groups are detailed in the following table.
Table 4.1: Contoso Administrator Groups
Group Name
Responsibilities
Domain Engineering
Domain administration
Domain controller administration
DNS
Operations
WINS
DHCP
File services
Print services
Web Services
IIS administration
Infrastructure Layout
Network Design
Contoso has two data centers connected with two T1 lines. Each office has a portion of
the engineering and operations staff providing network infrastructure services. All Web
servers are located at the main data center in Atlanta.
Each location has 100-megabits per second (Mbps) connections to all servers and 10Mbps connections to all client workstations. The servers are segmented on their own
subnet. Client computers are on a separate subnet. All computers have access to the
Internet through a connection in Atlanta.
74
Active Directory Design
Contoso has deployed a single Windows 2000 Server forest with an empty root and a
single child domain. An empty root domain is a separate domain that houses only the
computer accounts for the domain controllers in that domain and the default user
accounts.
An empty root domain may be created because of a desire to have multiple child
domains that are divided equally among geographic boundaries and managed by a
central group. An empty root domain does not provide any additional security but may
prevent unintentional errors from affecting the entire forest by separating the Enterprise
Administrators and the regional domain administrators. Contoso created an empty root
because of expectations that it may branch into additional countries in the future.
A diagram of the high level domain is shown in the figure below.
Figure 4.1
The Active Directory design for Contoso, Ltd.
Contoso has also divided its network into two Microsoft® Active Directory® directory
service sites – Atlanta and Boston. The flexible single master operations (FSMO) roles
are divided between these sites.
Each site has domain controllers that are running Active Directory integrated with DNS,
DHCP, and File and Print servers. Atlanta hosts the WINS servers for the entire
organization. Most of the organization's server computers running IIS reside in Atlanta;
however, some smaller department Web servers are located in Boston.
Contoso is currently upgrading its internal network. It is migrating to a switch-based
network topology, but there are still a large number of computers connected by hubs in
some of its buildings.
75
Figure 4.2
The service layout for Contoso Ltd.
The figure above shows the server-based distribution of services within Contoso but does
not accurately represent the total number of servers within the organization.
76
Business Requirements
As mentioned, Contoso is a marketing research company. Marketing research is an
industry that focuses on planning and controlling the sum of activities involved in directing
a flow of goods and services from producers to consumers, including product packaging,
pricing, promotion, and physical distribution to meet the needs of a particular market.
To find out what the market's needs are, market researchers must learn as much as they
can about their customers. To help facilitate this, Contoso provides market researchers
with detailed information about their target markets.
The majority of Contoso's marketing information is housed in IIS servers located within
the organization. Contoso's marketing research personnel utilize the internal marketing
research Web servers when gathering detailed information for their customers. Some of
this information is also located on file shares, but the information on these file shares is
only a subset of the information available on the intranet servers.
Contoso wants to ensure that its internal data is secure and stays secure. Marketing
research is a very competitive field, and the company's research data is its primary
competitive advantage over other companies in the same field. Because of this,
maintaining a high level of security for the company's marketing research data is the top
priority of the organization.
A separate project has been started to address the security of Contoso's external
connectivity and its perimeter network. These concerns are out of scope for this project.
77
Identifying Security Risks
The first step in any security project is to define the security risks that need to be
addressed. Security risks are a combination of assets, the threats that can affect those
assets, and the vulnerabilities of those assets that can be exploited in some manner. A
good analogy of these types of relationships is a house.
The house is an asset. It has value and should be protected. A robber is a threat agent to
the house because he has the potential to damage the house or steal items. The
windows in the house are a required feature; however, any open window becomes a
vulnerability because the robber can exploit this vulnerability to enter the house. This
simple example shows how a threat agent may exploit a vulnerability to gain access to an
asset.
The first step to fully secure an organization's computer environment is to identify the
assets in the environment, the threats that could affect the environment, and the
vulnerabilities of the identified assets. Following this process in an organization will help
establish a set of security risks that can be adequately analyzed and prioritized.
Identifying Assets
Assets can include a wide variety of items. This chapter will only discuss a subset of
computing assets. Identifying these assets can be very simple in some organizations and
very difficult in others depending on the procurement processes and asset tracking
mechanisms in use.
More important than knowing the number of servers deployed in your organization is
knowing the functions that the servers provide. For example, Contoso is a marketing
research company that uses Web servers to provide its employees access to market
data. The company may determine that these computers are more important to it than a
print server. However, Contoso may also determine that different Web servers in its
environment have different levels of importance to the overall organization.
Additionally, assets are not just physical hardware. In a computing environment, potential
assets that should be evaluated include services such as name services provided by a
DNS server. Assets could also include user accounts such as service accounts or
administrator accounts.
Prioritizing Assets
While identifying assets is a qualitative process, the overall benefits to the business goals
of the organization should be kept in mind when determining the potential value of each
server or group of servers. By doing this, an asset priority (AP) can be defined for each
server or server group. Primary factors to consider as part of this process include:
●
The financial value of the asset.
●
The cost to build the asset.
●
The cost to protect the asset.
●
The value of the asset to the competition.
●
The cost to recover the asset.
It can be very difficult to rank all of an organization's assets on the same scale. Because
of this, it may help to break them down into similar technologies and then rate them. By
approaching it this way, it will be much easier to compare the relative value of different
assets using a similar scale in your organization.
78
Establishing Asset Values
When identifying assets, it is also extremely important to determine an Asset Value (AV)
for each resource. The AV is the monetary value of the asset. When determining an
Asset Value, it is important to take a number of items into account, including the physical
value and the business value of the data located on those assets.
Physical value can be calculated quite easily. This amount is generated based on the
following costs:
●
Hardware costs
●
Software costs
●
Support costs
●
Replacement costs
The business value of the data contained on those assets may very difficult to express in
numbers. The value of the data may be based on the data’s contribution to the overall
financial goals of the company, or it could be based on the value of the data to an
external person or organization. Normally, this value is very debatable but should provide
relative impact of the loss of the data compared to data on similar assets. Often, the
value of the data far surpasses the value of the hardware itself.
The indirect value of the asset may be the most difficult to quantify. This number should
be the value that the company stands to lose through negative publicity, lawsuits, or loss
of business if this asset is lost or compromised. Additionally, this value may include the
cost to the business to replace or repair the damage caused by the loss of the asset.
Finally, the value of the data to an external organization should be evaluated. As with the
indirect business value, this can be difficult to calculate. This number should reflect the
monetary value that an external agent would pay for the actual data contained on the
asset.
The Asset Value is a dollar figure that can be used when computing loss expectancies for
the asset. The AV should be calculated by adding the physical value of the asset, the
direct business value that it provides, the indirect business value that it provides, and the
value of the asset to an external organization.
As mentioned above, this number is very difficult to determine. The physical value of a
server is only a fraction of the computer’s total value. The real value that an asset brings
to the organization is provided through its functionality or the data that it contains.
Contoso's Asset List
As part of the Security Risk Analysis process, an organization's assets need to be
identified and rated to provide input to the overall security risk statement and a means to
calculate their relative value to the organization. The Security Risk Analysis process
provides a method of identifying risks and assessing the possible damage that could be
caused to justify security safeguards.
Contoso has identified several groups of assets that it would like to address in the first
phase of the project – one of which is the Windows 2000 infrastructure. This grouping
includes the domain controllers, file and print servers, IIS servers, and infrastructure
servers. Contoso has further defined infrastructure servers to specifically include DNS,
DHCP, and WINS services.
79
These servers were ranked based on the criteria listed above. As part of this process, the
Domain Engineering, Operations, Web Services, and the extended security teams
determined an overall asset priority (AP) rating for each group of servers. To do this, the
teams based their ratings on the following scale of 1 to 10, which can be used to
designate assets that are crucial to the company:
●
1 – The server provides basic functionality but does not have a financial impact on
the business.
●
3 – The server houses important information, but the data could be quickly and
easily recovered.
●
5 – The server contains important data that would take some time to recover.
●
8 – The server contains information that is important to the business goals of the
company. The loss of this equipment would have a major effect on the productivity
of all users.
●
10 – The server has a major impact on company business. The loss of this
equipment would result in a competitive disadvantage.
The asset priority ratings applied to some of Contoso's assets are shown in the following
table. This is not a complete list of assets, but it is a sample of the overall rating
performed in Contoso's environment.
Table 4.2: Contoso Asset Priorities
Server Classification
Asset Priority (AP)
Root domain controllers
8
Enterprise Administrator accounts
10
Child domain controllers
8
Northamerica Domain Admin accounts
10
Northamerica domain user accounts
5
Root DNS services
4
Child DNS services
5
WINS servers
3
DHCP servers
1
File and Print servers
8
Research IIS servers
10
Department IIS servers
6
Human Resources IIS servers
7
Additionally, asset valuation was performed for each of the servers in the following table.
A further breakdown of these values can be viewed in in the Excel workbook,
"JA0401.xls" included with this solution.
80
Table 4.3: Contoso Asset Valuation
Server Classification
Physical
Value
Additional
Value
Asset Value (AV)
Single root domain controller
$18,000
$10,000
$28,000
Enterprise Administrator accounts
$0
$829 million
$829 million
Single child domain controller
$18,000
$50,000
$68,000
Northamerica Domain Admin
accounts
$0
$829 million
$829 million
Northamerica domain user
accounts
$0
$1,000
$1,000
Root DNS services
$18,000
$30,000
$48,000
Child DNS services
$18,000
$30,000
$48,000
WINS server
$18,000
$0
$18,000
DHCP server
$18,000
$0
$18,000
File and Print server
$40,000
$480,000
$520,000
Research IIS server
$46,000
$550,000
$596,000
Department IIS server
$32,000
$50,000
$82,000
Human Resources IIS server
$32,000
$300,000
$332,000
Understanding Asset Priorities and Asset Values
Company assets can be rated in many different ways. The criteria used to make these
decisions for Contoso's assets are detailed in this section. The information below
describes the decisions that were made in this particular scenario. Your scenario may be
different, and different values could be calculated based on business needs and
requirements. These values are extremely subjective and are provided to give an
overview of the process that was performed in Contoso's unique environment.
Root Domain Controllers
Root domain controllers are important pieces of the infrastructure; however, they contain
little data that could not be easily recreated. Contoso has several domain controllers in its
root domain, providing redundancy for the services that it provides. They provide little
direct financial benefit for the company but hold an enormous amount of power. For these
reasons, these computers were assigned an asset priority of 8.
The root domain controllers have little data on them that has financial value outside of the
company, but a compromise of these servers could limit users’ information. Because of
that, their business data was valued at approximately $10,000. Along with the hardware
costs, the total AV for the root domain controllers is estimated at $28,000.
These numbers account for a single domain controller and not the priority of the overall
domain services. The domain and enterprise administrator accounts were evaluated as
their own resources to calculate their associated risks.
Contoso could have additionally evaluated the priority and value of the overall domain
services to account for any risks that may eliminate all domain functionality. This was
deemed out of scope for the current project.
81
Enterprise Administrator Accounts
The accounts in the Enterprise Admins group are the most important accounts in the
organization. An enterprise administrator can obtain control of any computer in the forest.
These accounts should be used only as necessary and should have the tightest security
in the organization.
Because the power of the Enterprise Admins group is so great, the priority of these
assets is rated at 10. The loss of control of these accounts could result in disaster for the
organization.
The value of the accounts that are in the Enterprise Admins group is enormous. The
value is equivalent to that of all data stored in or secured by the Windows 2000 forest.
Because of this, the value of the Enterprise Admins account was valued to be equivalent
to the revenue of the organization over the past year – $829 million. The Enterprise
Admins group should be protected as if the entire business depends on its security.
Child Domain Controllers
Child domain controllers contain critical information about users in the organization,
including their passwords. Loss or compromise of this information could have a very large
impact on the company. Contoso has provided multiple domain controllers in all
locations, reducing the impact of a single failure. Because of this, it would be easy to
recover the loss of a single domain controller. The combination of these factors helped
Contoso rate the child domain controllers with an asset priority of 8.
The child domain controller data was valued at $50,000. This is an estimate that is based
on the amount that an external organization would pay for the user phone numbers and
e-mail addresses. In combination with the hardware value, the AV of the child domain
controllers was estimated at $68,000.
As with the root domain controllers, these numbers do not take into account the
compromise of the domain account or the loss of all domain services. Instead, the
estimate focuses purely on the data and functions provided by a single domain controller.
Northamerica Domain Admin Accounts
Contoso has a child domain called "Northamerica". This domain contains a majority of
the company assets, including servers, data, and accounts. While fewer in number than
the accounts in the Enterprise Admins group, the accounts in the Northamerica Domain
Admins group have a large amount of power.
Because the domain administrators have full control of all resources in the domain, the
priority of the Northamerica domain administrator accounts was rated a 10. While the
compromise of one of these accounts is only slightly worse than that of an account in the
Enterprise Admins group, both could result in the compromise of all computers in the
organization.
As mentioned before, the value of the accounts in the Domain Admins group is
enormous. Because of this, the value of the accounts in the Northamerica Domain
Admins group was again valued to be equivalent to the revenue of the organization over
the past year.
82
Northamerica Domain User Accounts
The Domain Administrators are not the only accounts of interest in an organization. While
a user account may not provide as much immediate power as that of a Domain
Administrator, it is another foothold that an attacker could use to overtake the
organization. The stability and integrity of user accounts is one of the primary concerns of
Active Directory. Because of this, the priority of the user accounts is rated a 5.
The physical value of a single user account is minimal. There is some administrative work
that would be required to restore the account and there would be some amount of lost
functionality. But of all the assets, this is one of the most difficult to put a price on. The
cost to recreate the account and make up for lost productivity helps estimate the AV of a
user account at approximately $1,000.
Root DNS Services
Root DNS servers provide a large amount of functionality but can be very easily
recreated. The data in these servers would provide little information to outside parties,
and the overall impact of such a data loss would be minimal. However, by poisoning the
DNS servers, users could be redirected to other locations and lose access to necessary
resources. For these reasons, the root DNS servers were assigned an asset priority of 4.
A pure DNS server contains no business data. However, there could be a loss of
functionality and productivity if these services were tampered with in any way. Based on
an estimate of the time that it would take to restore the functionality and correct any
issues, along with an estimate of the productivity losses, the additional value of the root
DNS services was estimated to be approximately $30,000. Combined with the hardware
value, the AV of the DNS servers is estimated at $48,000.
Note that the Contoso DNS servers are running as part of the domain controllers, but the
decision was made to treat these services separately.
Child DNS Servers
Child DNS servers contain information about all servers, client workstations, and some
network services in the child domain that could be valuable to interested parties. The
servers do not directly affect the company's profits, even though their value in
maintaining the smooth functioning of Contoso's network is very high. Because the data
housed in these servers can be easily recreated on DNS servers, they were assigned an
asset priority of 5.
As with the root, a pure DNS server contains no business data. However, there could be
a loss of functionality and productivity if these services were tampered with in any way.
Based on an estimate of the time that it would take to restore the functionality and correct
any issues, along with an estimate of the productivity losses, the additional value of the
DNS services in the Northamerica domain was estimated to be approximately $30,000.
Combined with the hardware value, the AV of the DNS servers is estimated at $48,000.
Again, note that the Contoso DNS servers are running as part of the domain controllers,
but the decision was made to treat these services separately.
83
WINS Servers
WINS servers contain information similar to that in DNS servers. However, the use of
WINS servers is limited primarily to the older client workstations in Contoso's
environment that are still running Windows 98 and Windows NT Workstation 4.0. Again,
in this case, because the server data can be easily recreated, they were assigned an
asset priority of 3.
A WINS server contains no business data. The information that WINS servers contain is
only the network basic input/output system (NetBIOS) name information for hosts in the
environment. A loss in productivity could impact the loss of all WINS services in the
environment, but because of redundancy, this risk is mitigated. The total AV for a WINS
server is estimated at $18,000.
Note that this does not include the value of the WINS services in the entire organization,
just the value of a single WINS server.
DHCP Servers
DHCP servers contain little information that would provide value to another organization.
These servers are easily recreated and do not provide any direct profit for the company.
For these reasons, they were assigned an asset priority of 1.
The DHCP server contains only information about computers and their IP addresses, as
well as some DHCP scope information. These servers contain no information that could
provide business value, although they do provide business functionality. Contoso has
implemented multiple DHCP servers in its environment and has utilized the 80/20 rule
when creating their DHCP scopes to allow for the loss of a DHCP server. Because of
this, the impact of the loss of a single server is greatly reduced. This being the case, the
AV of a single DHCP server is estimated at $18,000.
Note that this does not include the value of the DHCP services in the entire organization,
just the value of a single DHCP server.
File and Print Servers
File and print servers contain a large amount of the intellectual property of the company.
The loss of these computers could be worth a large amount of money to both the
company and its competitors. It would be extremely costly to recreate the data in these
servers. Because of these factors, Contoso's file and print servers were assigned an
asset priority of 8.
The data that is kept on each of the file and print servers has been averaged at $200,000
per server. This is based on the value that the data currently brings to the organization,
as well as the cost to generate the data.
Research IIS Servers
Research IIS servers at Contoso publish the majority of marketing research data for the
company's internal users. These servers contain the data that give the company its
primary competitive advantage. For these reasons, the research IIS servers are critical
and were assigned an asset priority of 10.
Each of the research IIS servers contains data that has been valued at $450,000. Again,
this is based on the value that the data currently brings to the organization, as well as the
cost to generate the data. Additionally, the value of this data was estimated to have a
worth of approximately $80,000 to an external organization. This combined with the cost
of the hardware provides an AV of $596,000 for each of the IIS servers dedicated to
marketing research data.
84
Department IIS Servers
The department IIS servers also contain valuable data on current and future projects for
Contoso but do not contain a large amount of information with pure business value.
These servers are primarily used as a means of communication. For these reasons, the
department IIS servers were assigned an asset priority of 6.
The data contained by department IIS servers was averaged at $50,000 for each server.
As mentioned above, this is based on the value that the data currently brings to the
organization, as well as the cost to generate the data. Combined with the hardware costs,
the AV for the department IIS servers is $82,000.
Human Resources IIS Servers
The human resources IIS servers are the front-end severs to another back-end HR
system. These servers can be easily recreated and do not house a large amount of
critical business data. However, these servers are costly to develop, so they were
assigned an asset priority of 7.
The value of the business data on the IIS servers has been determined to be $100,000.
This information contains a large amount of personal data and internal company
information that was estimated for this value to an external organization. Additionally, a
value of $200,000 was estimated to address any potential lawsuits or negative publicity
with the release of this information. Combined with the hardware value of the IIS server,
the AV for these assets is estimated at $332,000.
Identifying Threats
After identifying and valuing the assets that must be accounted for in Contoso's security
project, the next step is to determine which threats need to be addressed to protect the
assets. Threats come in many forms, and each poses different risks to company assets.
There are an unlimited number of threats for the assets within an organization. These are
discussed in detail in Chapter 2, "Defining the Security Landscape." In short, threats can
be divided into three main categories – natural, mechanical, and human.
Threats Identified in Contoso's Environment
As part of its Securing Windows 2000 project, Contoso decided that it would consider
only potential malicious attacks. The company's operational procedures and training
policies are in place to help reduce the threat of accidental misuse of the system
environment. Contoso's physical network design and system requirements also help
reduce mechanical threats. Additionally, Contoso has developed some well defined
contingency plans in case a natural disaster should strike.
By reducing the number of threats that will be addressed in the security project, you can
make can it much easier to gain a full understanding of the attack surface and the project
boundaries needed to establish your security policies and procedures. However, setting
these boundaries may also mean that additional projects become necessary to fully
address all threats to your organization's environment.
85
Security Risk Analysis – Determining Threat Probability
Determining the probabilities of specific threats is very important to the overall process of
security risk analysis. When creating security risk statements for your organization, these
numbers will help determine the criticality of each risk.
Contoso defined threat probability (TP) as the probability of a potential threat occurring. It
developed a scale for all high level threats and then ranked them from 0 to 1.0. Based on
this scale, a threat with a ranking of .1 has a very low probability of occurrence, while
another ranked 1.0 will definitely occur, as detailed in the following table.
Table 4.4: Contoso Threat Probabilities
Threat
Probability
Fire
.05
Water
.025
Wind
.025
Earthquake
.001
Power failure
.0002
Hardware failure
.1
Network failure
.3
Uninformed users
.2
Malicious code (viruses)
.6
Industrial spies
.1
Internal attackers
.6
External attackers
.4
The probability rated for internal attackers and external attackers is based a combination
of the results of the 2002 "Computer Crime and Security Survey" and Contoso's previous
experiences over the last year.
This is only a subset of the threats that could be identified, but it shows how a list may be
developed based on past experience, environmental conditions, geography, and an
organization's industry.
Security Assessments
As with most information system projects, the best way to plan a security project is to
survey the existing landscape. You should review policies and procedures and
investigate the use of technology at the physical, perimeter, network, host, application,
and data levels. There are many goals of security assessments, so there are several
categories of things that you can perform to achieve them. These include:
●
Operational assessments.
●
Penetration testing.
●
Vulnerability assessments.
●
Intrusion detection auditing.
There are a number of Microsoft partners that provide these services. For a listing of
Microsoft certified partners, see: http://mcspreferral.microsoft.com/default.asp. The three
security assessment categories are described in greater detail here.
86
Operational Assessments
Security starts with a well defined policy. The first step to securing an organization should
be a thorough review of the organization’s documented policies. An operational
assessment normally results in a detailed investigation of a company's policies and
procedures. Some operational assessments may extend into the high level use of
technology.
The goal of an operational assessment is to help your organization identify its current state of security and
operations management readiness. Additionally, it should help identify both general and specific
recommendations that can improve security readiness and reduce the total cost of ownership (TCO) for your
organization.
Penetration Testing
Penetration testing can help identify ways that an unauthorized individual can get into an
organization. This can include:
●
External resource scanning to identify potential targets for compromise.
●
War dialing to identify unsecured access by phone. A war dialer is tool that a
hacker uses to gain unauthorized access to a modem telephone number.
●
War pinging to identify any externally available hosts. These machines can be
leveraged for further testing.
●
War driving, a relatively new concept, which is the process of attempting to locate
any unsecured wireless access points in an organization.
●
Social engineering to locate individuals who may be tricked into revealing their
passwords or some form of security information that would accidentally provide
classified information.
●
Building penetration to determine whether physical access to the facility can be
easily obtained.
These tests are useful to increase the attention that an organization places on security
policies. One of the largest considerations in performing a penetration test is identifying a
reputable external organization to perform the tests. Any penetration testing should have
written approval prior to beginning. In most companies, unauthorized actions such as
these may be grounds for termination.
Vulnerability Assessments
A vulnerability assessment takes the penetration testing a step further. Instead of
identifying some of the potential access routes, a vulnerability assessment defines all
possible entry points into the organization. Inside the organization, the security project
team continues the vulnerability assessment by identifying other internal asset
weaknesses. This testing is usually performed by internal resources that have
administrative privileges on all computers.
A vulnerability is a weakness in an information system or its components (for example,
system security procedures, hardware design, and internal controls) that could be
exploited to produce an information-related misfortune. Usually a vulnerability exists
because of the current configuration of an asset. As the configuration of the assets
change, you should repeat vulnerability assessments to validate the updated system and
ensure that it remains secure.
87
Vulnerabilities can arise from weaknesses at any point in the defense in depth model.
This model provides a strategy to protect resources from external and internal threats.
Defense in depth (sometimes referred to as security in depth or multilayered security) is
taken from a military term used to describe the layering of security countermeasures to
form a cohesive security environment without a single point of failure. This model
includes addressing problems with people, processes, or technology, and can be
identified using this assessment strategy.
Vulnerability scanning can be performed with tools or by manual processes. An
automated scan can be used to identify each computer or component of the network.
After it has identified potential targets, the scan will run a series of tests to determine
potential vulnerabilities in the asset.
Manual scans may leverage the information that an assessment tool provides to obtain
more detailed information about the target environment. By going a step further, the
manual process may identify areas of weakness that were not apparent in the automated
process.
Intrusion Detection Audit
An intrusion detection audit usually combines the results of several of the other tests and
validates that an organization’s intrusion detection tools are working as expected. The
agency performing the intrusion detection audit will utilize information from the
operational assessment to understand the policies and processes that are currently in
place within the organization. The penetration testing results will give the person or group
performing the test an overview of the different areas in which the organization is
exposed. The vulnerability assessment will let the group understand what problems
currently exist in the organization.
A third party hired to perform an intrusion detection audit can utilize all of this knowledge
and attempt an intrusion from outside the organization. One major difference from the
vulnerability assessment is that this testing is usually performed by an external agency
with no administrative rights. If this process can be completed successfully, the target
company must re-evaluate their intrusion detection system implementation. If a
successful penetration occurs, the group performing the testing will repeat the process
inside the organization to continue to determine what further information it can gain
without alerting the intrusion detection system or administrators.
The intrusion detection audit is the most comprehensive test and should only be
completed by reputable organizations. Such testing requires the permission from
executives at the highest levels, and the full impact of such testing should be fully
evaluated prior to its initiation.
Vulnerability Assessment Tools
Some companies may want to purchase a vulnerability assessment tool rather than rely
on a third party to perform scans. Both approaches have advantages and disadvantages.
There is a great deal of value in having a third party review a company's infrastructure.
However, the cost of this process may be a limiting factor.
If an organization wants to use a vulnerability assessment tool on its own, the
organization should consider the following issues in order to ensure that the assessment
tool includes as many of the capabilities described below as possible.
88
Vulnerability Database Listings
The vulnerability assessment tool should be able to use multiple sources of vulnerability
listings. For example, these may include Microsoft Security Bulletins, the Common
Vulnerabilities and Exposures (CVE) database, the CERT Coordination Center, or
BugTraq.
Update Capability
The tool should automatically update its test results. The list of vulnerabilities that a tool
scans for and the tests that it runs are only as good as the latest update that it provides.
Scanning with a tool that requires manual updates increases the chances that the
administrator may not be checking for all possibilities.
Customizing Capability
The tool should have customizing capability. Every environment is different. There are
vulnerabilities that some organizations are willing to live with due to how their
environments are configured. Such organizations may not want to be alerted every time a
known issue is identified. Additionally, these organizations may have other specific items
to investigate that are not common in other environments.
Network Security
The vulnerability scanning tool should check for network security. As part of these tests, it
should scan for open ports that may identify services that have not been properly
secured.
Host Security
The tool should check for security on the host operating system. This includes scanning
for unnecessary services that may be running and analyzing groups and accounts on the
computer and unnecessary utilities on the server. It should ensure that proper access
control lists (ACLs) are applied on the event logs, that registry permissions have been
appropriately tightened, and that only the necessary user rights assignments have been
granted.
Application Security
Application security should be included in the testing, as well. This includes baseline
operating system settings, domain controller and domain setting scans, and Web server
scanning. Specifically, if IIS is used in the organization, the tool should monitor the IIS
metabase settings, which contain configuration information about the IIS server; the tool
should also verify that the inetpub directory has been moved to another volume and that
the IIS Lockdown Tool and URLScan have been run.
Data Security
The vulnerability scanner should check data security. Items to consider include security
on core operating system files, service pack levels, hotfixes installed, ACLs, and file
share permissions. Hotfixes are cumulative packages composed of one or more files
used to address a defect in a product. They address specific customer situations and
may not be distributed outside the customer organization without written legal consent
from Microsoft.
Security hotfixes are somewhat different, as they should be immediately applied to any
server that meets the specified criteria. Security hotfixes do not require legal consent and
can be distributed as necessary.
89
Prioritization
Finally, the tool should help define the high priority issues that are identified. For
example, the Microsoft Security Response Center identifies patches based on the
vulnerabilities that they address and then assigns each a rating. The center is a Microsoft
business unit responsible for the investigation and remediation of all security
vulnerabilities involving Microsoft products.
These ratings include critical, important, moderate, and low vulnerabilities. While these
ratings may be very general, they can help an organization prioritize which patches
should be applied immediately, and how they should be addressed with different groups
of equipment.
Security Risk Analysis Process Inputs
As part of the Security Risk Analysis process, each vulnerability will need to be evaluated
using several criteria. These inputs will help determine the overall risk that the
organization is exposed to by each threat. This can be done by creating a concise risk
statement for each attacker, exploit, vulnerability, and asset combination. While this may
seem to require a lot of work, it will help fully define the issues that need to be addressed
as part of the overall security project for your organization.
Risk Statements
When making security risk statements, each possibility should be addressed separately,
and the specific consequence of each risk should be described. If there are multiple
consequences, the risk statement may be too broad and should be further defined.
Every risk statement should have a condition that leads to a consequence. As seen in
Chapter 2, "Defining the Security Landscape,” the security risk statement that you
develop should be based on the following form:
IF threat agent uses a tool, technique, or method to exploit a vulnerability, THEN a loss of
confidentiality, integrity, or availability to an asset may result in an impact.
Determining Criticality Factors
The criticality factor (CF) is a measure of the damage that a particular exploit can cause
to an asset by utilizing the vulnerability in question. A particular vulnerability may have
several different exploits that could be used to attack the asset. Each exploit may have
different effects on the target computer. Because of this, some research may need to be
done to evaluate the potential exploits for each vulnerability.
The criticality factor should be measured on a scale of 1 to 10, where 1 indicates very
little impact from the exploit and 10 indicates that a huge amount of irrevocable damage
could occur.
Determining Effort to Exploit Identified Vulnerabilities
The effort (E) is the amount of work, knowledge, or experience that an attacker would
need to utilize a particular exploit. The level of effort to utilize the specific exploit should
be measured by the simplicity of the attack. There is a wide variety of malicious
attackers. They may range from “script kiddies” who have little knowledge about how or
why attacks work (but know what tools can help them gain information), to a true
“cracker” who has a deep technical knowledge on security. A cracker is a person who
overcomes the security measures of a computer system to gain unauthorized access.
The effort of a specific exploit should be measured on the same scale as the criticality
factor: 1 to 10, where 1 indicates very little skill required to utilize a particular exploit, and
10 indicates that the skills of a seasoned security programmer would be required.
90
Determining Vulnerability Factors
The vulnerability factor (VF) is the measure of susceptibility to a particular form of attack.
The vulnerability factor of an asset should also be measured on the 1 to 10 scale, where
1 indicates that the particular asset is not readily susceptible to the vulnerability, and 10
indicates that the asset is extremely open to the particular issue.
Top Vulnerabilities Identified in Contoso's Environment
Contoso used a vulnerability scanning tool on its network to identify some of the major
issues with its configuration. The tool returned a large list of items, prioritized as either
High, Medium, or Low risk vulnerabilities. Contoso has decided to immediately try to
address the High and Medium risk vulnerabilities during this phase of the security project.
Several of the vulnerabilities can be grouped into larger categories. These vulnerability
groupings are discussed along with the specific ones identified. Additionally, each
vulnerability is rated for effort, as well as criticality and vulnerability factors.
Buffer Overflows
The vulnerability scanner used in Contoso's environment identified that a number of the
servers were susceptible to IIS related buffer overflows. A buffer overflow is a type of
exploit that attackers employ to gain access to a system. Specifically, the tool identified
the unpatched ida/idq buffer overflow that is exploited by the Code Red worm. A worm is
a stand-alone, self-replicating program that usually consumes memory, thus causing
computers to crash.
Risk Statement
IF attackers use Code Red to exploit ida/idq vulnerabilities, THEN a loss of integrity and
availability of the research IIS servers may result in increased traffic on the network.
Because risk statements would need to be created for each vulnerable asset, similar risk
statements should be built for the departmental and the human resource IIS servers.
Criticality Factor
The Code Red worm was first discovered on July 17, 2001. The worm propagated itself
throughout the Internet at an amazing speed, infecting almost 360,000 servers in 14
hours. Along the way, it defaced Web servers and caused a large amount of extra traffic,
flooding many corporate networks.
Because of its potential impact to the corporate environment, the Contoso security team
gave Code Red a criticality factor of 9 for all of the organization's IIS servers.
Effort
Code Red was extremely difficult to create. The ida/idq overflow was a particularly
complex vulnerability and was initially very difficult to exploit. However, because of the
nature of Code Red, it was extremely spreadable. The Code Red worm propagates itself,
so there is little or no skill required to utilize this exploit. Because of this, the effort
required to utilize this exploit is assigned a rating of 1.
91
Vulnerability Factor
Contoso continues to see infections of Code Red in both of its server domain locations. It
is common for the company's servers to become infected during the build process, even
before the computers can be fully patched. Because of this, addressing the known IIS
buffer overflows is one of Contoso’s biggest concerns.
Since Code Red is continuing to infect servers inside of the organization, the current
server build process is extremely vulnerable to the worm. But security team personnel
are patching for this particular issue. The vulnerability factor for Contoso's Web servers is
assigned a rating of 8.
NetBIOS Enumeration
The scanner identified that all boxes were vulnerable to NetBIOS enumeration. NetBIOS
utilizes a default share for interposes communications (IPC). By default, anyone can
connect to this share – no user name or password is required. While simply connecting to
the share will not give someone rights to view files or control processes, it is possible to
view a large amount of system information.
By creating a null connection (a connection with no user name or password) to the IPC$
share on a computer, potential attackers can use commonly found utilities to view, for
example:
●
Account names.
●
Groups.
●
Shares.
●
Account comment fields.
●
Account last logon times.
●
Account last password changes.
These are only a few of the easily viewed items, but they represent the type of
information that can be obtained without a user name or password.
Risk Statement
IF an attacker uses a NetBIOS enumeration tool to exploit null sessions, THEN a loss of
confidentiality of the Northamerica domain controller may result in an unauthorized user
gaining account information.
A similar statement should be created for the root domain controller, as well.
Criticality Factor
NetBIOS enumeration using null sessions can result in a large security breach. By failing
to prevent an unauthorized user from viewing all user account names, account
comments, groups, and shares, the organization faces a large risk; it could present an
attacker with a number of account names, which is half of a user name/password
combination.
Because of the potential impact of compromised user names, Contoso rated the CF of
NetBIOS enumeration a 6 for all of the company's domain controllers. Contoso does not
create specific user accounts on member servers, but a separate risk statement could be
created because member servers do contain shares that can be enumerated. Contoso
did not see this as a major threat but would have rated the CF of member servers a 3.
92
Effort
The effort required to enumerate the NetBIOS information on a specified host is quite
low. There are a number of tools freely available on the Internet that automate this
functionality after a null session is established on a target computer.
Contoso rated the effort for exploiting this vulnerability a 2.
Vulnerability Factor
The Contoso environment currently does not implement any countermeasures to prevent
NetBIOS enumeration on any of its member servers or domain controllers. Because of
this, the VF for all servers is rated a 10.
SNMP Enumeration
The scanning tool found that the Simple Network Management Protocol (SNMP) was
enabled on the computers and was using the default "public" string.
Contoso uses SNMP services on Windows 2000 servers for reporting events. The
company has always used the public string and so was interested to discover that in
addition to generic hardware monitoring, SNMP can also be used to return information on
other aspects of the computer, including:
●
Account names.
●
Share names.
●
Share paths and comments.
●
Running services.
●
Open ports.
Risk Statement
IF an attacker uses an SNMP enumeration tool to exploit public community strings, THEN
a loss of confidentiality of the Northamerica domain controller may result in an
unauthorized user gaining access to account information.
A similar statement should be created for the root domain controller, as well.
Criticality Factor
SNMP enumeration can provide a large amount of information and can potentially be
dangerous, especially if the specified community string is given the ability to write to the
target server. Because of its configuration, Contoso assigned a CF rating of 6 for all
servers.
If Contoso also had any writable SNMP community strings, a separate risk statement
would have needed to be generated.
Effort
SNMP enumeration can be easily exploited with several freeware or shareware tools
available on the Internet. Contoso rated the effort to use these tools a 2.
Vulnerability Factor
Contoso has SNMP enabled on most of its servers for monitoring, and the company has
a default community string name of public. Because of this, the organization is quite
vulnerable. Contoso assigned SNMP enumeration a VF of 10.
93
DNS Enumeration
The vulnerability assessment identified that the DNS servers did not restrict zone
transfers. Without securing this feature of DNS, an attacker can easily obtain data from
an organization’s DNS server.
Contoso utilizes Active Directory integrated with DNS in Windows 2000. DNS holds a
large amount of information about a domain, including server names and Internet
Protocol (IP) addresses, services running on the network, and the servers hosting
specific services, such as global catalogs and DCs.
Risk Statement
IF an attacker uses nslookup to exploit unlocked zone transfers, THEN a loss of
confidentiality of the Northamerica DNS may result in computer and service identification.
A similar statement should be created for the root DNS servers, as well.
Criticality Factor
DNS enumeration can provide a large amount of information on the hosts and services in
the environment, but it does not contain information on specific users or company critical
data. Because of this, Contoso assigned a CF factor of 2 for domain controllers.
Effort
DNS enumeration can be performed with tools included on most any operating system.
Contoso rated the effort to use these tools a 1.
Vulnerability Factor
Because Contoso has not secured DNS zone transfers in its environment, it has rated the
VF of DNS enumeration a 7.
Weak Passwords
The assessment tool chosen by Contoso has additional functionality that allows it to
perform basic dictionary attacks against user accounts to identify weak passwords.
Additionally, it examines the password hashes in the Security Accounts Manager (SAM)
database to determine whether there were any blank or duplicate passwords. If a large
number of duplicate passwords are identified, an attacker may determine that these are
default passwords used when a new account is set up in the organization.
The information in the SAM is encrypted, but even without trying to crack the passwords,
it is easy to identify blank or duplicate passwords based on the hash. Because Contoso
does not have an account lockout policy defined, an unlimited number of attempts can be
made to guess passwords. The scanning tool found a number of passwords consisting
purely of common words found in any dictionary which were it was able to break in only a
matter of moments.
Risk Statement
IF an attacker uses a brute force password attack to exploit a lack of password policies,
THEN a loss of integrity and confidentiality of the Enterprise Admin accounts may result
in an attacker gaining unauthorized access to the organization.
Similar risk statements should be generated for the Domain Admins group, as well as
general user accounts.
Criticality Factor
Weak passwords are the bane of any system administrator. They can allow an attacker to
quickly obtain a user account and password combination. Because of this, Contoso
assigned this issue a CF of 10.
94
Effort
Weak passwords can be easily guessed with dictionary attack tools available on the
Internet. Contoso rated the effort to use these tools a 2.
Vulnerability Factor
Because Contoso does not have a password policy in place and is not auditing for any
logon failures, it rated the VF of weak passwords as a 10.
Unencrypted Server Message Block Traffic
The vulnerability scanner detected that servers at Contoso were using the default setting
for server message block (SMB) communications.
By default, the Windows NT LAN Manager (NTLM) challenge/response does not ever
pass the LanManager (LM) authentication or NTLM hash across the network. However,
tools exist that can monitor the traffic of this exchange and use a brute force method to
derive the original LM hash value.
After the hashes have been obtained, several different utilities can be used to crack the
hashes into a clear text password.
Risk Statement
IF an attacker uses a SMB sniffer to exploit unencrypted SMB traffic, THEN a loss of
integrity and confidentiality of the Enterprise Admin accounts may result in an attacker
gaining unauthorized access to the organization.
Similar risk statements should be generated for the Domain Admins group, as well as
general user accounts.
Criticality Factor
By cracking passwords, an attacker can gain unauthorized access to files and services
that could not be obtained from a null session. Because of this, Contoso assigned this
issue a CF of 10.
Effort
A publicly available tool can be purchased to provide this functionality. However, the tool
must be able to promiscuously view all traffic. Being on a switched network greatly
reduces this possibility. Because Contoso is currently upgrading its network
infrastructure, it rated the effort to use this tool a 5.
Vulnerability Factor
Because Contoso does not have a password policy in place, there are a number of short
passwords that can be quickly obtained using SMB capture techniques. This situation
caused the security team to assign the VF for this issue a 10.
Ineffective Auditing
Many of the servers scanned did not have audit settings enabled to a sufficient level to
identify potential attacks. For example, the Audit Account Logon setting was not enabled,
which could help to identify brute force attacks against passwords.
Risk Statement
IF an attacker uses a tool that can disable auditing to exploit ineffective auditing, THEN a
loss of integrity of the Northamerica domain controller may result in an attacker gaining
undetected access to the remote system.
Similar risk statements should be generated for the Northamerica domain controllers, all
IIS servers, the DHCP servers, WINS servers, and the File/Print servers.
95
Criticality Factor
An attacker can leverage poor auditing configuration with the use of a resource kit utility
such as auditpol. Auditpol can enable the attacker to disable auditing altogether. Contoso
assigned the CF of this exploit a rating of 3 because no data is actually compromised, but
the situation can hamper the investigations of unexpected attacks.
Effort
The effort to use auditpol requires that the attacker gets the tool on the system and
obtains administrative access. The tool is simple to execute, but because administrator
access is required, the effort for this exploit is assigned a rating of 4.
Vulnerability Factor
Because Contoso does not have an audit policy in place and is not currently auditing for
any security events, the security project team assigned the VF for this exploit a 9.
Unchecked DoS Attacks
A Denial of Service (DoS) attack is any attack that prevents users from accessing
resources. There are many different variations of DoS attacks, but some of the most
common affect either IIS or the Transmission Control Protocol/Internet Protocol (TCP/IP)
stacks of individual computers.
The scanning tool identified several changes that could be made on computers to secure
them from TCP/IP-based DoS attacks.
Risk Statement
IF an attacker uses a DoS attack to exploit TCP/IP DoS vulnerabilities, THEN a loss of
availability of the root domain controller may result in a loss of productivity.
Similar risk statements should be generated for the Northamerica domain controllers, all
IIS servers, the DHCP servers, WINS servers, and the File/Print servers.
Criticality Factor
A TCP/IP DoS attack would result in a completely unusable system. Because of this,
Contoso assigned such an attack a CF of 8.
Effort
There are a number of easy to use, graphical utilities to provide this functionality to an
attacker. Because of this, the effort required to exploit this specific vulnerability is
assigned a 1.
Vulnerability Factor
Because Contoso does not currently have any countermeasures for TCP/IP DoS attacks
in place, it rated the vulnerability factor for this exploit a 9.
96
IIS Directory Traversal
A scan of the IIS servers identified a common directory traversal issue. The exploit of this
vulnerability would allow an attacker not only to view information such as directory
layouts and the contents of files on the target computer, but in many cases it would also
allow the attacker to write files and execute commands on the servers.
Risk Statement
IF an attacker uses a double decode attack to exploit URL cannonicalization issues,
THEN a loss of integrity and confidentiality of the research IIS servers may result in an
attacker gaining the ability to view the file system and run commands on the server.
Similar risk statements should be built for the departmental and the human resource IIS
servers, as well.
Criticality Factor
The IIS directory traversal exploits can be quite dangerous because they can allow a
remote user to launch some system commands from a Web server. However IIS version
5.0 limits the context of these commands to run as the IUSR account. Nonetheless, there
is a large risk presented by such an attack, prompting Contoso to assign it a CF of 7.
Effort
The effort to exploit IIS directory traversal is quite minimal. IIS directory traversal can be
exploited using several different tools, but the easiest of these is simply a Web browser.
Because of this, the effort assigned to this exploit is a 2.
Vulnerability Factor
Because Contoso has a number of IIS servers that do not have the latest patches and
were not built according to IIS best practices, the company assigned the VF for this
exploit on IIS servers a rating of 9.
97
Analyzing and Prioritizing Security Risks
Analysis
After a variety of assessments, enough information has been gathered to begin analyzing
the security risks and prioritizing them based on their impact and exposure in Contoso's
environment. Before building risk statements, it may be useful to consolidate the
information in one table. Part of Contoso's risk analysis for this appears in the following
table.
Table 4.5: Contoso Risk Assessment Summary
Threat
TP
Malicious
code
.6
Malicious
code
.6
Malicious
code
.6
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
98
.6
.6
.6
.6
Exploit
CF
E
Vulnerability
VF
Asset
AP
Code Red
9
1
ida/idq
vulnerabilities
8
Research IIS
servers
10
Code Red
9
1
ida/idq
vulnerabilities
8
Department IIS
servers
6
8
Human
resources IIS
servers
7
Code Red
9
1
ida/idq
vulnerabilities
A NetBIOS
enumeration
tool
6
2
null sessions
10
Root domain
controller
8
A NetBIOS
enumeration
tool
6
2
null sessions
10
Northamerica
domain controller
8
An SNMP
enumeration
tool
6
2
Public community
strings
10
Root domain
controller
8
2
Public community
strings
10
Northamerica
domain controller
8
7
Root DNS
4
An SNMP
enumeration
tool
6
.6
Nslookup
2
1
Unlocked zone
transfers
Nslookup
2
1
Unlocked zone
transfers
7
Northamerica
DNS
5
A brute force
password
attack
10
2
Lack of password
policies
10
Enterprise Admin
accounts
10
2
Lack of password
policies
10
Northamerica
Domain Admin
accounts
10
2
Lack of password
policies
10
Northamerica
user accounts
5
5
Unencrypted SMB
traffic
10
Enterprise Admin
accounts
10
.6
.6
.6
.6
.6
A brute force
password
attack
A brute force
password
attack
An SMB
sniffer
10
10
10
(continued)
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
Attacker
.6
.6
.6
.6
.6
.6
.6
.6
.6
.6
10
Unencrypted SMB
traffic
10
Northamerica
user accounts
5
Ineffective auditing
9
Root domain
controller
8
9
Northamerica
domain controller
8
10
5
10
5
3
4
10
An SMB
sniffer
A tool that
can disable
auditing
A tool that
can disable
auditing
10
Northamerica
Domain Admin
accounts
Unencrypted SMB
traffic
An SMB
sniffer
3
4
Ineffective auditing
A tool that
can disable
auditing
3
4
Ineffective auditing
9
Research IIS
servers
A tool that
can disable
auditing
3
4
Ineffective auditing
9
Department IIS
servers
6
7
A tool that
can disable
auditing
3
4
Ineffective auditing
9
Human
resources IIS
servers
A tool that
can disable
auditing
3
4
Ineffective auditing
9
File/Print servers
8
A tool that
can disable
auditing
3
4
Ineffective auditing
9
WINS server
3
A tool that
can disable
auditing
3
4
Ineffective auditing
9
DHCP server
1
DoS attack
8
1
TCP/IP DoS
vulnerabilities
9
Root domain
controller
8
DoS attack
8
1
TCP/IP DoS
vulnerabilities
9
Northamerica
domain controller
8
DoS attack
8
1
TCP/IP DoS
vulnerabilities
9
Research IIS
servers
10
DoS attack
8
1
TCP/IP DoS
vulnerabilities
9
Department IIS
servers
6
7
.6
.6
.6
.6
.6
DoS attack
8
1
TCP/IP DoS
vulnerabilities
9
Human
resources IIS
servers
DoS attack
8
1
TCP/IP DoS
vulnerabilities
9
File/Print servers
8
1
TCP/IP DoS
vulnerabilities
9
WINS server
3
.6
.6
DoS attack
8
99
(continued)
Attacker
.6
DoS attack
Attacker
Attacker
Attacker
.6
.6
.6
A double
decode
attack
A double
decode
attack
A double
decode
attack
8
7
7
7
1
TCP/IP DoS
vulnerabilities
9
DHCP server
1
2
URL
cannonicalization
issues
9
Research IIS
servers
10
2
URL
cannonicalization
issues
9
Department IIS
servers
6
2
URL
cannonicalization
issues
9
Human
resources IIS
servers
7
Threat Frequency Level
The threat frequency level (TL) is a measure of the expected frequency of attack, the
potential for damage, and the effort required to perform the attack. This measurement
can be found by multiplying the threat probability (TP) by the risk factor (RF). The RF is
the criticality factor (CF) of the attack divided by the effort (E) required to perform the
exploit.
Impact Factor
The impact factor (IF) also describes the potential loss. This number can be calculated by
multiplying the vulnerability factor (VF) with the asset priority (AP).
Exposure Factor
Finally, the exposure factor (EF) to the risk can be calculated by multiplying the TL with
the IF. The exposure factor of all risks can be compared to determine which risks should
be addressed first in the organization.
Contoso Risk Analysis
Top Risks Identified
The top risks identified through the overall Security Risk Analysis process are
summarized in the table below. The exposure factor was calculated by using the
following formula:
EF = ((TF × IF) / 1000)
EF = (((TP × RF) × IF) / 1000)
EF = (((TP × (C / E)) × IF) / 1000)
Which at the most basic form becomes:
EF = (((TP × (C / E)) × (VF × AP)) / 1000)
100
Table 4.6: Top Risks Identified in Contoso's Environment
Vulnerability
Asset
EF
A brute force
password attack
Enterprise Admin
accounts
0.6
A brute force
password attack
Northamerica Domain
Admin accounts
DoS attack
Research IIS servers
0.6
0.432
0.432
0.3456
Code Red
Research IIS servers
DoS attack
Root domain controller
DoS attack
Northamerica domain
controller
DoS attack
File/Print servers
0.3456
0.3456
Code Red
Human resources IIS
servers
0.3024
DoS attack
Human resources IIS
servers
0.3024
A brute force
password attack
Northamerica user
accounts
Code Red
Department IIS servers
DoS attack
Department IIS servers
0.3
0.2592
0.2592
A double decode
attack
Research IIS servers
0.189
A NetBIOS
enumeration tool
Root domain controller
0.144
A NetBIOS
enumeration tool
Northamerica domain
controller
0.144
Additional Quantitative Analysis Tools
Often identifying and prioritizing the top risks in an organization is only the start of the risk
analysis process. The next step is to determine either the remediation or mitigation steps
required to address each risk identified in the organization. While determining this may be
fairly easy, implementing the required remediation steps may prove to be very difficult.
To justify the cost of the safeguards, additional information may be required. The
following procedures can help determine the value of implementing certain remediation
steps as part of the security project for the organization.
Single Loss Expectancy
Single loss expectancy (SLE) is a way to put a price tag on a particular system. The SLE
represents only one element of risk: the expected impact, monetary or otherwise, of a
specific threat event. The SLE can be computed by multiplying the exposure factor of a
given threat by the financial value of the asset (AV).
For example, the SLE for the impact of Code Red infecting the research IIS servers can
be calculated by taking the Exposure Factor of 0.432 identified above and multiplying it
by the research IIS server's AV of $596,000.
SLE = .432 X $596,000 = $257,472.
101
Annualized Rate of Occurrence
The annualized rate of occurrence (ARO) is the probability of a threat occurring during a
one-year time frame. For example, a threat occurring once in 10 years has an ARO of
1/10 or 0.1; a threat occurring 50 times in a given year has an ARO of 50.0. The possible
range of frequency values is from 0.0 (the threat is not expected to occur) to some whole
number that is completely dependant on the type and number of threat sources. In a
large organization, some risks could occur thousands of times, resulting in a very high
ARO.
In Contoso's environment, Code Red has been consistently infecting servers, so Contoso
has seen that 25 out of 50 of its servers have been infected in the last year, providing an
ARO of 1/2 or 0.5.
Annual Loss Expectancy
The annual loss expectancy (ALE) is calculated by multiplying the single loss expectancy
(SLE) by the annualized rate of occurrence (ARO).
To effectively identify risk and to plan for budgetary cycles, it may be helpful to compute
loss expectancy in annualized terms. For example, the ALE for Code Red as mentioned
above with an ARO of .5 times a year that affects one of Contoso's IIS servers with a SLE
of $257,472 is $128,736. When the expected threat frequency (ARO) is factored into the
equation, the financial impact of the risk is accurately portrayed.
Value of Safeguards
If the estimated cost of safeguards can be established, and the annual recurring cost to
maintain the countermeasure can be estimated, the overall value of implementing each
safeguard can be determined. This process is the basis for meaningful cost-benefit
analyses of risk reduction measures.
The value of a safeguard can be computed by taking the ALE and subtracting the initial
cost of the countermeasure and the annual recurring cost of the countermeasure. Based
on the risk analysis example of the equation above, if a cost of $20,000 is estimated in
order to implement a countermeasure to address the identified threat, and the annual
cost of maintaining this countermeasure is $1,000, the value of the safeguard would be
$128,736 - ($20,000 + $1,000) or $107,736.
102
Summary
This chapter applies the Security Risk Management Discipline (SRMD) to a common
customer scenario. All information provided for this applied example is based on actual
data; however, this information represents only a fragment of the overall information
required for an organization to perform a through security risk assessment. Including the
entire risk analysis table or every security risk statement would have made the
information provided in this chapter difficult to readily understand. Because of this,
relevant examples are highlighted for quick reference and easy comprehension.
The SRMD is one of hundreds of ways to categorize and rate risks within an
organization. This information can be used to augment existing policies and processes or
to help an organization establish such standards for the first time.
The guidelines in this chapter were applied to develop a list of risks that are addressed
with specific remediation steps. Now that that list has been generated, the next step is to
identify the processes required to secure the listed vulnerabilities.
More Information
The security risk analysis is based on the Microsoft Solutions Framework (MSF) risk
analysis process. For more information about MSF, see:
http://www.microsoft.com/business/services/mcsmsf.asp.
Related Topics
The following work is a great reference to learn more about specific vulnerabilities within
Windows 2000:
Hacking Exposed Windows 2000: Network Security Secrets & Solutions by Joel
Scambray and Stuart McClure (McGraw-Hill Professional Publishing, ISBN: 0072192623)
103
5
Securing the Domain
Infrastructure
In Chapter 4, "Applying the Security Risk Management Discipline", the security risks
specific to the scenario at Contoso, Ltd, were identified using the Security Risk
Management Discipline (SRMD). The risks identified will be either mitigated or addressed
through remedial action in the remaining chapters of this guide.
This chapter focuses on domain level vulnerabilities. Included is a high level description
of the Microsoft® Active Directory® service design, the Organizational Unit (OU) design,
and domain policy. In addition, the specific domain policies implemented at Contoso. Ltd.
are discussed in detail.
105
Active Directory Design
Detailed information on designing an Active Directory structure could fill an entire book by
itself. Active Directory is a Microsoft technology that is part of the Active Platform. It is
designed to enable applications to find, use, and manage directory resources in a
distributed computing environment. The information provided in this section will touch on
a few of these concepts to ensure that a common level of understanding is established
for the other related information in this chapter.
One of the most important aspects to consider when creating an Active Directory
architecture is the security boundaries that will be imposed on your organization. By
taking the time to adequately plan how security will be delegated and implemented in
your organization, the final Active Directory design will be much more secure. Doing this
should not require restructuring your environment unless there are major changes to the
business, such as an acquisition or organizational restructuring.
If an Active Directory design has already been implemented in your organization, this
chapter may help provide insight into some of the benefits or potential issues with the
particular design in your environment from a security perspective.
Establishing Active Directory Boundaries
There are several different types of boundaries within Active Directory. These boundaries
can include the forest, the domain, the site topology, and permission delegation.
Many of these boundaries are established when Active Directory is installed. Designing
the delegation of permissions in the environment must incorporate organizational
requirements and policies to ensure the proper balance of security and administrative
functionality. Delegation of administrative permissions can be quite flexible depending on
your organization's requirements. The delegation boundaries can be further broken into
security boundaries and administrative boundaries.
Security Boundaries
Security boundaries help define the autonomy of different groups within an organization.
It is difficult to balance the tradeoffs between ensuring adequate security, based on how
these boundaries are established, with the need to continue providing a solid level of
base functionality.
This balance between security boundaries and functionality can be achieved successfully
by fully understanding the threats that create risks to your organization, and then
comparing this assessment with the security implications of delegating administration or
creating other particular choices in the network architecture of your environment.
Forest as a Security Boundary
When Microsoft® Windows® 2000 Server was introduced, a large amount of supporting
documentation defined a domain as a security boundary. However, a more recent
definition defines the forest as the true security boundary. The truth lies somewhere in
between.
A domain is definitely a management boundary of Active Directory. With an organization
of well meaning individuals, the domain boundary will provide autonomous management
of services and data within each domain of the organization.
Unfortunately, when discussing security this is not so simple to achieve. A domain, for
example, will not provide complete isolation of a possible attack by a rogue domain
administrator. This level of separation can only be achieved at the forest level.
106
Because of this, your organization may need to consider dividing the administrative
control of services and data within the current design. By fully understanding the needs of
your organization for service autonomy and service isolation, as well as data autonomy
and data isolation, the Active Directory design for your environment will begin to solidify.
Administration Boundaries
Because of the potential need to segment services and data, the different levels of
administration must be defined.
Service Administrators
Active Directory service administrators are responsible for the configuration and delivery
of the directory service. For example, service administrators maintain domain controller
(DC) servers, control directory – wide configuration settings, and are responsible for
ensuring service availability.
In many cases, the service configuration of Active Directory is determined by attribute
values that correspond to settings for their respective objects, which are stored in the
directory. Consequently, service administrators in Active Directory are also data
administrators. Service administrators may include:
●
Groups of administrators responsible for forest management.
●
Groups of administrators responsible for domain management.
●
Groups of administrators responsible for Domain Name System (DNS)
management.
●
Groups of administrators responsible for OU management.
●
Groups of administrators responsible for infrastructure server management.
Groups that are in charge of forest administration are responsible for the delivery of the
directory service to the network. The group providing forest management should always
be very highly trusted. The forest administration team controls the forest through the
forest root Domain Admins group, the Enterprise Admins group, and the Schema Admins
group.
A group providing domain administration is primarily responsible for directory services.
The forest administrator is responsible for choosing the group to administer each domain.
Because of the high – level access granted to the domain administrator, this person
should be a highly trusted individual. The group performing domain administration
controls the domain through the Domain Admins group and other built – in groups.
The DNS administrator group is responsible for completing the DNS design and
managing the DNS infrastructure. The DNS administrator manages the DNS
infrastructure through the DNSAdmins group.
The OU administrator designates a group or individual as a manager for each OU. Each
OU administrator is responsible for the management of the data stored within the
assigned Active Directory OU. These groups can control how administration is delegated,
and how policy is applied to objects within their OUs. In addition, OU administrators can
also create new subtrees and delegate administration of the OUs for which they are
responsible.
The group responsible for infrastructure server administration is responsible for managing
the Windows Internet Name Service (WINS), Dynamic Host Configuration Protocol
(DHCP), and potentially the DNS infrastructure. In some cases the group handling
domain management will manage the DNS infrastructure because Active Directory is
integrated with DNS and is stored and managed on the domain controllers.
107
Data Administrators
Active Directory data administrators are responsible for managing data stored in Active
Directory or on computers joined to Active Directory. These administrators have no
control over the configuration or delivery of the directory service. Data administrators
include:
●
Administrators who control a subset of objects in the directory. Through inheritable,
attribute – level access control, data administrators can be granted control of very
specific sections of the directory, but have no control over the configuration of the
service itself.
●
Administrators who manage member computers that are joined to the directory and
data that is stored on those computers.
Note: In many cases, the service configuration of the directory is determined by
the attribute values for objects stored in the directory.
To summarize, the potential consequences of Active Directory service structures, and
directory structure owners, for an organization to join a forest or domain infrastructure
create a situation in which the organization must choose to trust all service administrators
in both the forest and all domains. In this context, to trust service administrators means
to:
●
Reasonably believe that service administrators will look out for the organization's
best interests. Organizations should not elect to join a forest or domain if the
owners of the forest or domain might have legitimate reasons to act maliciously
against the organization.
●
Reasonably believe that service administrators will follow best practices and
restrict physical access to the domain controllers.
●
Understand and accept the risks to the organization associated with rogue
administrators and coerced administrators.
● Rogue administrators — It is always possible for a trusted administrator to
become a rogue administrator, and thus abuse the power they have with the
system.
●
Coerced administrators — A trusted administrator might be coerced or
compelled to perform operations that breach the security of the system.
Some organizations might accept the risk of a security breach by a rogue or a coerced
service administrator from another part of the organization. Such organizations might
determine that the collaborative and cost – saving benefit of participating in a shared
infrastructure outweighs this risk. However, other organizations might not accept the risk
because the potential consequences of a security breach are too severe.
108
OU Design to Support Security
While this guide is not focused on Active Directory design, there is some design
information that is required to provide insight into the use of Group Policy for secure
administration of the domain, domain controllers, and specific server roles.
While OUs offer an easy way to group users and other security principals, they also
provide an effective mechanism to segment administrative boundaries.
Additionally, using OUs to provide different Group Policy objects (GPOs) based on server
role is an integral piece of the overall security architecture for the organization.
Delegation of Administration
An OU is simply a container within a domain. Control over an OU can be delegated to a
group or individual by setting specific access control lists (ACLs) on each container.
Often, an OU can be used to provide similar administrative capabilities found in
Microsoft® Windows NT® 4.0 resource domains. An OU also can be created to contain a
group of resource servers to be administered by other users. While this group of other
users may have autonomous control over this particular OU, they are not isolated from
the remainder of the domain.
Administrators that delegate control over specific OUs are likely to be service
administrators. At a lower level of authority, users that control the OUs are usually data
administrators.
Administration Groups
The creation of administration groups provides administrators a way to segment groups
of users, groups, or servers into containers for autonomous administration.
For example, consider the infrastructure servers that reside in a domain. Infrastructure
servers include all of the nondomain controllers that are running basic network services,
including servers running DNS, WINS, or DHCP services.
Often, these servers are maintained by an operations group or an infrastructure
administration group. An OU can be used to easily provide administrative capabilities to
these servers.
To do this, the first step is to create an OU called Infrastructure Servers. All DNS, WINS,
or DHCP servers can be moved into this OU. A global security group called Infrastructure
Admins can be created with the appropriate domain accounts added to it. Finally, the
Delegation of Control Wizard should be run to give the Infrastructure Admins group the
setting Full Control of the OU. The following figure provides a high – level view of such an
OU.
109
Figure 5.1
OU delegation of administration
This is only one of many ways that organizational units can be used to provide
administrative segmentation. If your organization is more complex, refer to additional
guidance referenced at the end of this chapter.
After following this procedure, the Infrastructure Admin group should have full control
over the Infrastructure Servers OU and all servers and objects within this OU. This
prepares them for the next phase: securing the sever roles with Group Policy.
110
Group Policy Application
Group Policy can be used in conjunction with the delegation of administration to ensure
that specific settings, rights, and behavior are applied to all servers within an OU. By
using Group Policy rather than manual steps, it is simple to update a number of servers
with any additional changes required in the future.
Group policies are accumulated and applied in the order shown in the figure below
Figure 5.2
GPO application hierarchy
As seen above, policies are applied first from the local policy of the machine. After that,
any GPOs are applied at the site level, and then at the domain level. If the server is
nested in several OUs, any GPOs that exist at the highest level OU are applied first. The
process of applying GPOs continues down the OU hierarchy. The final GPO to be applied
will be the one at the local OU where the server object is located.
A few considerations need to be kept in mind with this model.
●
If multiple GPOs are defined at any of the group policy levels seen above, an
administrator will set the order in which they are applied. If the same option is
specified in multiple policies, the last one applied will have precedence.
●
A Group Policy can be configured with the No Override option. By selecting this
option, other GPOs can not override settings configured as part of this policy.
111
Security Templates
Group Policy templates are text based files. Changes to these files can be made using
the Security Templates snap – in to the Microsoft Management Console (MMC) or by
using a text editor such as Notepad. Some sections of the template files contain specific
ACLs which are defined by the Security Descriptor Definition Language (SDDL). More
information on editing security templates and SDDL can be found on Microsoft® MSDN®.
Template Centralization
It is very important that the security templates used for production are stored in a secure
location in your environment that can only be accessed by the administrators responsible
for implementing Group Policy. By default, security templates are stored in the
%SystemRoot%\security\templates folder on all Windows 2000 machines.
This folder is not replicated across multiple DCs. Therefore, you will need to select a DC
to hold the master copy of the security templates so that you do not encounter version
control problems with the templates. This ensures that you always are modifying the
same copy of the templates.
Time Configuration
It is very important that system time is accurate and that all servers are using the same
time source. The Windows 2000 W32Time service provides time synchronization for
Microsoft® Windows® 2000 and Microsoft® Windows® XP–based computers running in
an Active Directory domain.
The W32Time service ensures that the client clocks of Windows 2000–based machines
are synchronized with the DCs in a domain. This is necessary for the Kerberos version 5
authentication protocol to work properly. Time synchronization also assists in event log
analysis.
Kerberos is a network authentication protocol developed by MIT. Kerberos authenticates
the identity of users attempting to log on to a network and encrypts their communications
through secret – key cryptography.
The W32Time service synchronizes clocks using the Simple Network Time Protocol
(SNTP) as described in RFC 1769. In a Windows 2000 Server forest, time is
synchronized in the following manner:
112
●
The primary domain controller (PDC) emulator operations master in the forest root
domain is the authoritative time source for the organization.
●
All PDC operation masters in other domains in the forest follow the hierarchy of
domains when selecting a PDC emulator with which to synchronize their time.
●
All DCs in a domain synchronize their time with the PDC emulator operations
master in their domain as their in – bound time partner.
●
All member servers and client desktop computers use the authenticating DC as
their in – bound time partner.
To ensure that the time is accurate, the PDC emulator in the forest root domain can be
synchronized to an external SNTP time server. However, doing so may result in a
requirement to open ports on the firewall. Before doing this, the benefits should be
weighed against the potential security risk of making these configuration changes.
In many cases, it may not be a necessity to have all servers synchronized with an outside
time source, as long as they are synchronized with the same time source inside the
organizations network.
If your network runs Microsoft® Windows® 95 or Microsoft® Windows® 98 operating
systems on its computers, the clocks on those machines should be synchronized using
the following command in a logon script where <timecomputer> is a domain controller on
the network:
net time \\<timecomputer> /set /yes
By running this command, you can prevent these machines from having any time
difference in their clocks from others in the rest of the domain.
Note: Network computers running operating systems other than Windows should also
synchronize their clocks to the PDC emulator of the Windows 2000 domain to allow
logging events to be analyzed, based on the same time.
Server Role Organizational Units
The example used previously for the management of the infrastructure servers in your
organization can be extended to the scenario for Contoso as well. The goal is to create a
seamless Group Policy that covers all servers, while ensuring that the servers residing
within Active Directory meet the security standards for your environment.
Domain Policy
The first step in this process is to create a new domain level policy. This is because the
Windows 2000 default domain policy should be further secured. The administrator should
create a new policy and link it to the domain GPO. To ensure that this new policy has
precedence over the default policy, it should be moved to provide it with the highest
priority of the GPO links.
The default policy could be modified directly to create a new security configuration, but
the advantage of creating a new policy is that if there are problems with it, the new policy
can be easily disabled, leaving the default domain policy in place to resume control.
Baseline Policy
The second step is to create a baseline policy. To do this, a baseline security template
should be created and imported into the policy. The MSS Baseline.inf is included with this
solution to provide this functionality. This GPO security template should be linked to the
Member Servers OU. The MSS Baseline.inf security template will apply the settings of
the baseline policy to any servers in the Member Servers OU, as well as any servers in
child OUs.
The baseline policy should set the desired settings for all servers across your
organization. The baseline policy also should be as restrictive as possible, and any
servers that need to differ from this policy should be segmented into separate server
specific OUs, such as the Infrastructure Servers OU.
113
Server Role Organizational Units
Continuing the example above, a separate policy for the incremental changes to the
infrastructure server policies should be created. A security template called MSS
Infrastructure Role.inf could contain the settings necessary to ensure that the
infrastructure services function and are accessible over the network.
This GPO infrastructure template should be linked to the Infrastructure OU. Finally, the
Restricted Groups setting should be used to add the following three groups to the Local
Administrators group in the Infrastructure Policy GPO: Domain Administrators, Enterprise
Administrators, and Infrastructure Administrators.
This process is shown in the figure below.
Figure 5.3
Configuring incremental group policies
As mentioned before, this is only one of many possible ways to create an organizational
unit structure for the deployment of GPOs. For more information on the creation of OUs
for the implementation of Group Policy, see the Microsoft® TechNet article, "Best
Practice Active Directory Design for Managing Windows Networks" at:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ad/
windows2000/deploy/depovg/bpaddply.asp.
114
In this guide, several server roles are defined. The security templates in the following
table have been created in accordance with the process described above to increase
security for these roles.
Table 5.1: Windows 2000 Server Roles
Server Role
Description
Security Template
Windows 2000 Domain
Controller
A group containing Active Directory
domain controllers.
MSS DCBaseline.inf
Windows 2000 Member
Servers
All servers that are members of the
domain and reside in or below the
member server OU.
MSS Baseline.inf
Windows 2000 File and
Print Server
A group containing locked down file
and print servers.
MSS FilePrint Role.inf
Windows 2000
Infrastructure Server
A group containing locked down
DNS, WINS, and DHCP servers.
MSS Infrastructure Role.inf
Windows 2000 IIS Server
A group containing locked down IIS
Servers.
MSS IIS Role.inf
All incremental template files are expected to be applied to OUs below the member
servers OU. For this reason, each of these lower – level OUs require both the MSS
Baseline.inf and the specific incremental file to be applied to them to define the role each
will fulfill in the organization.
The security requirements for each of these roles are different. Appropriate security
settings for each role are discussed in detail in Chapter 7, "Hardening Specific Server
Roles."
Important: This guide assumes that Windows 2000 servers will perform specifically
defined roles. If the servers in your organization do not match these roles, or you have
multipurpose servers, use the settings defined here as guidelines for creating your own
security templates. However, bear in mind that the more functions each of your servers
perform, the more vulnerable they are to attack.
115
The final OU design to support these defined server roles is shown in the figure below.
Figure 5.4
Example of OU design
Contoso OU, GPO, and Administrative Group Design
The recommendations above are applied to Contoso to restructure the company's
existing OU structure for Windows 2000 servers. Additionally, the Contoso administrators
use their predefined administration boundaries to create their administrative groups. The
correlation of these groups to the OUs they manage is shown in the following table.
Table 5.2: Contoso OUs and Administrative Groups
OU Name
Administrative Group
Domain Controllers
Domain Engineering
Member Servers
Domain Engineering
Infrastructure
Operations
File and Print
Operations
Web
Web Services
Each administrative group has been created at Contoso as a Global Group within the
child domain of Northamerica.
116
Contoso has added each of these administrative groups to the appropriate restricted
group by using the corresponding GPO for each restricted group. The administrative
groups that were created above will only be members of the Local Administrators group
for the computers located in the OUs that specifically contain machines related to their
job functions.
Finally, Contoso set permissions on each GPO so that only administrators in the domain
engineering group are able to edit them.
By default, the new OU structure inherits many security settings from its parent container.
The check box for Allow inheritable permissions from parent to propagate to this
object should be cleared for each OU. Any unnecessary groups that may have been
previously added by administrators should be removed, and the domain group that
corresponds to each server role OU should be added. The Domain Administrators group
should retain the setting Full Control.
The tasks required to establish these OUs do not have to be performed in a particular
order, but there are some obvious dependencies, for example: the domain groups must
exist before you can delegate control of different OUs to them. The following list defines a
suggested order for implementing these tasks:
1. Create the OU structure.
2. Move the computers to the appropriate OUs.
3. Create the administrative groups.
4. Add the appropriate domain accounts to the administrative groups.
5. Delegate administration for each OU to the appropriate domain groups.
6. Create the group policies in the OU where they will be applied.
7. Link each Group Policy to any additional OUs as necessary.
8. Import the appropriate security template to each GPO.
9. Set permissions on each GPO so that the appropriate domain groups have control
over them.
10. Add the appropriate domain groups to Restricted Groups for each GPO.
11. Test and refine the group policies.
117
Domain Policy
Group Policy security settings may be applied at several different levels in your
organization. Contoso decided to use Group Policy to apply settings at the following three
levels:
●
Domain Level — To address common security requirements, such as account
policies that must be enforced for all servers.
●
Baseline Level — To address specific server security requirements that are
common to all servers in the network.
●
Role Specific — To address role specific security requirements. For example, the
security requirements for infrastructure servers differ from those for servers
running Microsoft® Internet Information Services (IIS).
In terms of security auditing, IIS creates log files that track connection attempts to Web,
File Transfer Protocol (FTP), network news time protocol (NNTP), and Simple Mail
Transfer Protocol (SMTP) services.
Domain Policy Overview
Group Policy is extremely powerful because it allows machines throughout the network to
undergo standard configuration. By providing administrators with the means to make
security changes at the same time on all machines in the domain, or subsets of the
domain, GPOs provide a significant portion of a configuration management solution for
any enterprise.
The types of security changes that can be simultaneously applied via Group Policy
include:
118
●
Modifying permissions on the file system.
●
Modifying permissions on registry objects.
●
Changing settings in the registry.
●
Changing user rights assignments.
●
Configuring system services.
●
Configuring auditing and event logs.
●
Setting account and password policies.
The Group Policy settings that affect these security changes are divided into multiple
sections of the Windows 2000 Server computer policy.
Table 5.3: Windows 2000 Server Computer Policy Sections
Policy Section Name in UI
Description
Account Policy\Password Policy
Configures password age, length, and complexity.
Account Policy\Account Lockout Policy
Configures lockout duration, threshold, and reset counter.
Account Policy\Kerberos Policy
Configures ticket lifetimes.
Local Policies\Audit Policy
Enables or disables recording specific events.
Local Policies\User Rights Assignment
Defines rights such as log on locally and network access.
Local Policies\Security Options
Modifies specific security related registry values.
Event Log
Enables success and failure monitoring.
Restricted Groups
Administrators control who belongs to specific groups.
System Services
Controls Startup Mode for each service.
Registry
Configures permissions and auditing on registry keys.
File System
Configures permissions and auditing on folders,
subfolders, and files.
All computers have a predefined local policy. When an Active Directory domain is initially
created, default domain and domain controller policies are also created. Instead of
modifying the default policies, you should create a new policy and link it to the domain.
This will enable a quick rollback of any settings that may cause unidentified problems in
your environment. If the default policies are ever modified, it is important to document the
settings they contain, so that you can easily return to the previous state in the event of a
problem.
119
Figure 5.5
Applying domain policies
The following section discusses the settings that should be considered and documented
at the domain level.
Account Policies
Account policies are implemented at the domain level. A Windows 2000 Server domain
must have a single password policy, an account lockout policy, and Kerberos version 5
policy for the domain. Setting these policies at any other level in Active Directory will only
affect local accounts on member servers. If there are groups that require separate
password policies, they should be segmented into another domain or forest based on any
additional requirements.
Password Policy
In Windows 2000 Server, the most common method to authenticate a user’s identity is to
use a secret user password. Once a user has been identified and authenticated, the user
may perform any tasks or access any resource that he or she is authorized to perform.
Securing Active Directory in your environment requires that strong passwords be used by
all users. This helps avoid the threat of an unauthorized user guessing a weak password
through either manual methods or tools to acquire the credentials of a compromised user
account. This is especially true for administrative accounts.
A complex password that changes regularly reduces the likelihood of a successful
password attack. Password policy settings control the complexity and lifetime for
passwords. Each specific password policy account setting is discussed in this section.
120
The following values can be configured in the Domain Group Policy settings at the
following location:
Computer Configuration\Windows Settings\Security Settings\Account Policies\
Password Policy
Enforce Password History
Vulnerability
Password reuse is a large concern in any organization. There are at least three kinds of
password reuse issues that underscore this vulnerability:
●
Reuse of passwords for multiple accounts within an organization. This is commonly
seen when users or administrators have multiple accounts in different domains, or
for different functions within one domain, and the accounts share the same
password.
●
Use or reuse of the same password for any account over a long period of time. If
users are required to change their password, but nothing prevents them from using
the old password or allows them to continually reuse a small number of passwords,
the effectiveness of a good password policy is greatly reduced.
●
Reuse of the same password for multiple service accounts. If an organization must
use service accounts, each one should have a unique password that exceeds the
basic password requirements to ensure that each password is extremely difficult to
crack.
The Enforce Password History setting determines the number of unique new passwords
that must be associated with a user account before an old password can be reused.
Specifying a low number for this setting will provide users the ability to continually utilize
the same small number of passwords repeatedly. If the Minimum Password Age setting is
not configured as well, users can change their password as many times as necessary in
a row to reuse their original password.
For the Enforce Password History setting to be effective in your organization, do not allow
passwords to be changed immediately when configuring the Minimum Password Age
setting.
Countermeasure
Set Enforce Password History to a value of 24. The value for the Enforce Password
History setting can be set between 0 and 24 passwords. This setting is defined in the
Default Domain GPO, and in the local security policy of workstations and servers with a
value of 1. Configuring this value to the maximum setting helps ensure that vulnerabilities
caused by password reuse are kept to a minimum.
Potential Impact
The major impact of this setting is that users will have to come up with a new password
every time they are required to change their old one. By requiring users to change their
passwords to new unique values, there is an increased risk of encountering users that
write down their passwords so that they do not forget them.
This value should be set at a level to combine a reasonable maximum password age with
a reasonable password change interval requirement for all users in your organization.
Contoso Scenario
In the Contoso scenario, Enforce Password History was set to 24.
121
Maximum Password Age
Vulnerability
Any password can be cracked. With current computing power, breaking even the most
complex password is only a matter of time and effort. Some of the following settings can
increase the level of difficulty to break passwords in a reasonable amount of time.
However, frequently changing user passwords in your environment may help reduce the
risk of a valid password being cracked, as well as potentially mitigate the risk of a
password that has been wrongfully acquired from being used.
The Maximum Password Age setting determines the number of days that a password can
be used before the system requires the user to change it. The maximum password age
can be configured so that users are never required to change their passwords, but doing
so will result in a major security risk.
Countermeasure
Set Maximum Password Age to a value between 30 and 60 days. The value for the
Maximum Password Age setting can be configured to expire after 1 to 999 days, or to
never expire by setting the number of days to 0. This setting is defined in the Default
Domain GPO, and in the local security policy of workstations and servers with a value of
42 days.
Potential Impact
Setting the maximum password age value at too low a number of days will require users
to change their passwords very often. This may actually reduce the security in the
organization because it may increase the possibility of users writing their passwords
down to avoid forgetting them.
Setting the value too high will reduce the level of security within an organization because
it will allow a potential attacker a much larger window in which to crack a user passwords.
Contoso Scenario
In the Contoso scenario, Maximum Password Age was set to the default value of 42
days. This provides security for Contoso by requiring users to frequently change their
passwords, but minimizes the inconvenience for users by not requiring them to change
their passwords too often.
Minimum Password Age
Vulnerability
Users that want to reuse a password may be forced to change their password on a
regular basis. If a policy is set to ensure that they do not reuse any of their last 12
passwords, they could change their password 13 times in a row to return to the password
they were originally using.
The Minimum Password Age setting determines the number of days that a password
must be used before the user is allowed to change it. The minimum password age value
must be less than the maximum password age value.
As mentioned before, the Minimum Password Age setting must be configured to more
than 0 for the Enforce Password History setting to be effective. Without a minimum
password age, the user can repeatedly change passwords, cycling through them until
they get to an old favorite.
122
Countermeasure
Set Minimum Password Age to a value of 2 days. The value can be set between 1 and
998 days, or password changes can be allowed immediately by setting the number of
days to 0, which is not recommended. This setting is undefined in the Default Domain
GPO, and in the local security policy of workstations and servers, which allows
passwords to be changed immediately.
Potential Impact
There is one minor issue with setting Minimum Password Age to a number greater than
0. If an administrator sets a password for a user, and then would like for that user to
change the administrator – defined password, the administrator must select the "User
must change password at next logon" check box. Otherwise, the user will not be able to
change the password until the next day.
Contoso Scenario
In the Contoso scenario, Minimum Password Age was set to 2 days to discourage
users from cycling through passwords to reuse old ones.
Minimum Password Length
Vulnerability
There are several types of password attacks that can be performed to obtain the
password for a particular user account. These include dictionary attacks which attempt to
use common words and phrases, and brute force attacks that try every possible
combination of numbers and letters. In addition, an attack could be performed by
obtaining the LM password hash and using utilities to crash the hashes and obtain
passwords.
The Minimum Password Length determines the least number of characters that may
make up a password for a user account. There are many different theories on
determining the best password length for an organization.
Countermeasure
Set Minimum Password Length to at least a value of 8. Values between 1 and 14
characters can be specified for this setting. No password will be required if the number of
characters is set to 0. This setting is defined in the Default Domain GPO, and in the local
security policy of workstations and servers with a value of 0.
In most environments, an 8 character password is recommended as it is long enough to
provide adequate security and still short enough for users to more easily remember. This
setting will provide adequate defense against a brute force attack. Adding complexity
requirements will help reduce the possibility of a dictionary attack. Complexity
requirements will be discussed in the next section.
The attack against the password hash is discussed in detail in Chapter 6, "Hardening the
Base Windows 2000 Server."
123
Potential Impact
Requiring too short of a password will reduce security because short passwords may
easily be broken with tools that perform either dictionary or brute force attacks against the
passwords. Requiring too long of a password may result in mistyped passwords that
could result in an account lockout and subsequently additional help desk call volume.
Requiring extremely long passwords can actually decrease the security of an
organization because users may be more likely to write their passwords down in fear of
forgetting them.
Contoso Scenario
In the Contoso scenario, the value for Minimum Password Length was specified at 8
characters.
Passwords Must Meet Complexity Requirements
Vulnerability
Passwords that contain only alphanumeric characters are extremely easy to crack using
several publicly available utilities. To prevent this, passwords should contain additional
characters and requirements.
The Passwords Must Meet Complexity Requirements setting determines whether
passwords must meet a series of guidelines that are considered important for a strong
password.
If this policy setting is enabled, then passwords must meet the following requirements:
●
The password does not contain all or part of the user's account name.
●
The password Is at least six characters long.
●
The password contains characters from three of the following four categories:
●
English upper case characters (A – Z).
●
English lower case characters (a – z).
●
Base 10 digits (0 – 9).
●
Nonalphanumeric (For example, !, $, #, or %).
These complexity requirements are enforced upon password change or creation of new
passwords.
The rules that are included in the Windows 2000 Server policy cannot be directly
modified. However, a new version of passfilt.dll can be created to apply a different set of
rules. The source code for passfilt.dll can be found in the Microsoft Knowledge Base
article 151082: "HOW TO: Password Change Filtering & Notification in Windows NT."
Countermeasure
Set Passwords must meet complexity requirements to the value Enabled. This
setting is disabled in the Default Domain GPO, and in the local security policy of
workstations and servers.
This setting combined with the 8 character minimum password length, ensures that there
are at least 218,340,105,584,896 different possibilities for a single password. This makes
the use of a brute force attack very difficult if not impossible.
124
Potential Impact
Enabling the default passfilt.dll may cause some additional help desk calls for locked out
accounts because users may not be used to having passwords that contain characters
other than ones found in the alphabet. However, this setting is liberal enough that all
users should be able to abide by the requirements with a minor learning curve.
Additional settings that could be included in a custom passfilt.dll could include the use of
non – upper row characters. Upper row characters are those which are typed by holding
down the SHIFT key and typing any of the digits 1 – 10.
Also, the use of ALT key character combinations may greatly enhance the complexity of
a password. However, requiring all users in an organization to adhere to such stringent
password requirements can result in unhappy users and an extremely busy help desk.
Consider implementing a requirement in your organization to use ALT characters in the
0128 – 0159 range as part of all administrator passwords. ALT characters outside of this
range may represent standard alphanumeric characters that would not add additional
complexity to the password.
Contoso Scenario
In the Contoso scenario, Password must meet complexity requirements was set to
Enabled.
Store Password Using Reversible Encryption for All Users in the
Domain
Vulnerability
Some applications may require access to user passwords to provide additional
functionality. This is often done by allowing the password to be stored in a "reversibly
encrypted format" that is not secure.
The setting for Store password using reversible encryption for all users in the domain
determines whether Windows 2000 Server will store passwords in a much weaker format
that is comparable to using cleartext. Using this setting weakens passwords in your
environment. A message in cleartext is not encrypted. Cleartext messages are also
referred to as plaintext messages.
Potential Impact
This policy is required when using the CHAP authentication protocol through remote
access or Internet Authentication Service (IAS) services. It is also required when using
Digest Authentication in IIS. This is an extremely dangerous setting to apply using Group
Policy on a user – by – user basis, because it requires opening the appropriate user
account object in the Active Directory Users and Computers management console.
Warning: This policy should never be enabled unless application requirements
outweigh the need to protect password information.
Countermeasure
Ensure that the value for Store password using reversible encryption for all users in
the domain to set to Disabled. This setting is disabled in the Default Domain GPO, and
in the local security policy of workstations and servers.
Contoso Scenario
In the Contoso scenario, Store password using reversible encryption for all users in
the domain was left set to Disabled.
125
Password Policy Summary
Regardless of which domain policies are set, the settings for User must change password
at next logon, User cannot change password, Password never expires, and Store
password using reversible encryption policies can be configured for any individual user.
This may be done by accessing the Account tab of the user's Properties dialog box.
These individual – user password policy settings override domain policies.
The password policy settings for Contoso are summarized in the following table.
Table 5.4: Contoso Password Policies
Password Policy Name in UI
Setting
Enforce Password History
24 passwords remembered
Maximum Password Age
42 days
Minimum Password Age
2 days
Minimum Password Length
8 characters
Password must meet complexity requirements
Enabled
Store password using reversible encryption for all users in
domain
Disabled
Account Lockout Policy
More than a few unsuccessful password tries during an attempt to log on to your system
might represent an attacker trying to determine an account password by trial and error.
Windows 2000 Server keeps track of logon attempts, and the operating system can be
configured to respond to this type of potential attack by disabling the account for a preset
period of time.
Account lockout policy settings control the threshold for this response and the actions to
be taken once the threshold is reached.
Account Lockout Duration
Vulnerability
A denial of service (DoS) may be created if an attacker abuses the account lockout
threshold and repeatedly attempts to log in to an account. If the account lockout threshold
is set, after a specified number of failed attempts, the account will be locked out.
The Account Lockout Duration setting determines the number of minutes a locked out
account remains unavailable.
Countermeasure
Set Account Lockout Duration to the value of 30 minutes. The Account Lockout
Duration can be set to a value between 1 and 99,999 minutes. To specify that the
account will never be locked out, the value may be set to 0. This setting is not defined in
the Default Domain GPO, and in the local security policy of workstations and servers.
Potential Impact
While configuring the value for this setting to never automatically unlock may seem like a
good idea, doing so may increase the number of calls the help desk in your organization
receives to unlock accounts that were locked by mistake.
126
Contoso Scenario
In the Contoso scenario, Account Lockout Duration was set to 30 minutes to help
reduce the number of support calls resulting from users locked out of their accounts.
Account Lockout Threshold
Vulnerability
Password attacks may utilize automated methods to try thousands of password
combinations for any or all user accounts. By limiting the number of failed logons that can
be performed, the effectiveness of such attacks is nearly eliminated.
However, it is important to note that a DoS attack could be performed on a domain that
has an account lockout threshold configured. A malicious attacker could
programmatically attempt a series of password attacks against all users in the
organization. If the number of attempts is greater than the account lockout threshold, the
attacker will have the potential of locking out every account.
The Account Lockout Threshold determines the number of failed logon attempts that will
cause a user account to be locked out. If an Account Lockout Threshold is defined,
then the Account Lockout Duration must be greater than or equal to the reset time.
Countermeasure
By default, this policy is set to 0 in the Default Domain GPO, and the local security policy
of workstations and servers. The maximum value for Account Lockout Threshold is 999.
Because vulnerabilities can exist both when this value is configured, as well as when it is
not, two distinct countermeasures are defined. Any organization should weigh the choice
between the two based on their identified threats and the risks that they are trying to
mitigate. There are two options that should be considered for this setting.
●
●
Set Account Lockout Threshold to 0, which ensures that accounts will not be
locked out. This setting will prevent a DoS attack that intentionally locks out all
(or some specific) accounts. In addition, this setting helps reduce help desk calls
because users can not accidentally lock themselves out of their accounts. Because
it will not prevent a brute force attack, this setting should only be chosen if both of
the following criteria are explicitly met:
●
The password policy forces all users to have complex passwords made up of 8
or more characters.
●
A robust auditing mechanism is in place to alert administrators when a series
of account lockouts are occurring in the environment.
If these criteria can not be met, set Account Lockout Threshold to a high enough
value to provide users the ability to accidentally mistype their password several
times without locking their account, but ensure that a brute force password attack
would still lock out the account. In this case, setting the value to a very large
number such as 50 invalid logon attempts is a good recommendation. This setting
will prevent accidental account lockouts, reducing the number of help desk calls,
but will not prevent a DoS attack as mentioned above.
127
Potential Impact
If the account lockout threshold is set, a locked out account can not be used until it is
reset by an administrator or the account lockout duration has expired. This setting will
likely generate a number of additional help desk calls.
If the account lockout threshold is set to 0, there is a possibility that an attacker's attempt
to crack passwords using a brute force password attack may go undetected.
Contoso Scenario
In the Contoso scenario, Account Lockout Threshold was set to 50 invalid logon
attempts. This number ensures that users can not accidentally lock themselves out and
that automated vulnerability scanning tools will not lock users out, but continues to
prevent a brute force password attack.
Reset Account Lockout Counter After
Vulnerability
Users can accidentally lock themselves out of their account if they mistype their
password multiple times. To reduce the chance of this, the Reset Account Lockout
Counter After setting determines the number of minutes that must elapse after a failed
logon attempt before the invalid logon attempt counter is reset to 0.
If an Account Lockout Threshold is defined, then this reset time must be less than or
equal to the Account Lockout Duration.
Countermeasure
Set the Reset Account Lockout Counter After value to 30 minutes. The range for this
setting is 1 to 99,999 minutes. This policy is not defined in the Default Domain GPO or
the local security policy of workstations and servers.
Potential Impact
Not setting this value or setting the value to too long of an interval could result in a DoS
attack. An attacker could maliciously perform a number of failed logon attempts on all
users in the organization, locking out their accounts as mentioned above. With no policy
set to reset the account lockout, administrators would have to manually unlock all
accounts. With a reasonable value set, the users would be locked out for some period,
but at the end of that time period, the accounts will be unlocked automatically.
Contoso Scenario
In the Contoso scenario, Reset Account Lockout Counter After was set to 30 minutes
to increase the level of security against brute force password attacks.
Account Lockout Policy Summary
In general, to increase security within your organization, the Account Lockout Duration
setting should be increased while the Account Lockout Threshold is decreased. The
Account Lockout Policy setting for Contoso are summarized in the table below.
128
Table 5.5: Contoso Account Lockout Policy Settings
Account Lockout Policy Name in UI
Setting
Account Lockout Duration
30 minutes
Account Lockout Threshold
50 invalid logon attempts
Reset Account Lockout Counter After
30 minutes
Contoso's settings create a situation in which a user who makes 50 invalid logons in 30
minutes will be locked out of his or her account. The account will be automatically reset
after 30 minutes. If the account needs to be reset during this 30 minute period, the action
must be performed manually by an account administrator.
Kerberos Policy
In Windows 2000 Server, the Kerberos version 5 authentication protocol provides the
default mechanism for authentication services, as well as the authorization data
necessary for a user to access a resource and perform a task on that resource. By
reducing the lifetime of Kerberos tickets, the risk of a legitimate user’s credentials being
stolen and successfully used by an attacker decreases. However, authorization overhead
increases.
In most environments, these settings should not need to be changed.
Kerberos Policy Summary
Contoso has decided to maintain the default settings for the company's Kerberos version
5 policy. These settings are summarized in the table below.
Table 5.6: Kerberos Policy Settings
Kerberos Policy Name in UI
Setting
Enforce user logon restrictions
Enabled
Maximum lifetime for service ticket
600 minutes
Maximum lifetime for user ticket
10 hours
Maximum lifetime for user ticket renewal
7 days
Maximum tolerance for computer clock synchronization
5 minutes
The Kerberos policy settings are left at their default values. Because of this, they are not
specifically defined in Contoso's environment or the MSS Domain.inf file included in the
security templates associated with this solution.
Other Policies
There are a number of additional policies that will be configured as the baseline policy for
all member servers in Contoso, as well as additional settings for many of the specific
server roles. These will be discussed in Chapter 6, "Hardening the Base Windows 2000
Server," and Chapter 7, "Hardening Specific Server Roles."
129
Managing Policy
Importing the Security Templates
The following procedure imports the security templates included with this guide into the
OU structure suggested in this chapter. Before implementing the following procedure on
a domain controller, the specific policy (.inf) files must be located on a Windows 2000
Server in your environment.
Warning: The security templates in this guide are designed to increase security in your
environment. It is quite possible that by installing the templates included with this
guide, some functionality in the environment of your organization may be lost. This
could include the failure of mission critical applications.
It is therefore essential to thoroughly test these templates before deployed them in a
production environment. Back up each DC and server in your environment prior to
applying any new security settings. Ensure the system state is included in the backup
to enable registry settings or Active Directory objects to be restored.
Before continuing with the procedure to import the security templates, if the servers in
your environment are not running at least Windows 2000 SP3 as recommended in this
guide, apply the hotfix discussed in Knowledge Base article Q295444, "SCE Cannot Alter
a Service's SACL Entry in the Registry."
If this hotfix is not applied, the Group Policy templates will not be able to disable any
services. A hotfix is a single cumulative package composed of one or more files used to
address a defect in a product. Hotfixes address a specific customer situation and may not
be distributed outside the customer organization without written legal consent from
Microsoft. The terms QFE, patch, and update have also been used as synonyms for
hotfix.
XImporting the Domain Policy
1. In Active Directory Users and Computers, right – click the Domain, and then
select Properties.
2. On the Group Policy tab, click New to add a new GPO.
3. Type Domain Security Policy and press Enter.
4. Right click Domain Security Policy and select No Override.
5. Select Domain Security Policy and click Edit.
6. In the Group Policy window, click Computer Configuration\Windows Settings.
Right click Security Settings and select Import Policy.
7. In the Import Policy From dialog box, navigate to \SCI\Security Templates, and
double – click MSS Domain.inf.
8. Close the Group Policy that has been modified.
9. Close the Domain Properties window.
10. Force replication between your domain controllers so that all DCs have the policy
by doing the following:
a. Open a command prompt and use the Secedit.exe command line tool to force
the DC to refresh the domain policy with the command:
secedit /refreshpolicy machine_policy /enforce.
11. Verify in the Event Log that the policy downloaded successfully and that the server
can communicate with the other DCs in the domain.
130
Secedit.exe is a command line tool that when called from a batch file or automatic task
scheduler, can be used to automatically create and apply templates and analyze system
security. It can also be run dynamically from a command line.
It is important to note that this policy should be imported into any additional domains in
the organization. However, it is not uncommon to find environments where the root
domain password policy is much more strict than any of the other domains. Additionally,
care should be taken to ensure that any other domains that will use this same policy have
the same business requirements. Because the password policy can only be set at the
domain level, there may be business or legal requirements that segment some users into
a separate domain simply to enforce the use of a stricter password policy on that group.
Contoso chose to utilize the same policy for their root and child domains, and utilized the
same MSS Domain.inf to implement each.
Similar procedures as above should be used for applying any of the subsequent
templates for the baseline policy and the incremental policies.
Successful GPO Application Events
Aside from manually checking all of the settings to ensure that they have been
appropriately applied to the server in your organization, an event also should appear in
the Event Log to inform the administrator that the domain policy has downloaded
successfully. The following event information should appear in the Application Log with its
own unique Event ID number:
Type: Information
Source ID: SceCli
Event ID: 1704
Description: Security policy in the Group Policy objects are applied
successfully
If this message does not appear within a few minutes after applying the policy, rerun the
Secedit.exe command line tool to apply the domain policy, and then restart the server to
force the domain policy download.
By default, the security settings are refreshed every 90 minutes on a workstation or
server and every 5 minutes on a domain controller. You will see this event if any changes
have occurred during that time. Additionally, the settings are also refreshed every 16
hours, whether or not there are any changes.
131
Summary
There are several design considerations that should be made when reviewing a forest,
domain, and an Organizational Unit (OU) design for security.
Research and document any specific autonomy and isolation requirements for your
organization. Political autonomy, operational isolation, and legal or regulatory isolation
are all valid reasons to consider complex forest designs.
Understand the ability to control service administrators. Malicious service administrators
can present a great risk to an organization. At a lower level, malicious domain
administrators can access data in any domain in the forest.
While it may not be easy to change the forest or domain design in your organization, it
may be necessary to remediate some security risks for your enterprise.
Plan the OU deployment in your organization according to the needs of the service
administrators, and the data administrators. Create an OU model that will support using
Group Policy objects (GPOs) for the ongoing management of the different server roles in
your enterprise.
Finally, review all domain wide settings in your organization. Only one set of password,
account lockout, and Kerberos version 5 authentication protocol policies can be
configured for the domain. Other password and account lockout settings will only affect
the local accounts on member servers. Plan to configure settings that will apply to all
member servers of the domain, and ensure that these provide an adequate level of
security across your organization.
Related Topics
For more information on security and privacy at Microsoft, see:
http://www.microsoft.com/security
For information on the "Ten Immutable Laws of Security," see:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/columns/security/
essays/10imlaws.asp
For information on "Design Considerations for Delegation of Administration in Active
Directory," see:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ad/
windows2000/plan/addeladm.asp
For more information on configuring a Time Server, see:
Microsoft Knowledge Base article Q216734, "How to Configure an Authoritative Time
Server in Windows."
132
6
Hardening the Base Windows
2000 Server
Earlier chapters mention applying server hardening procedures to all of the servers at
Contoso, Ltd., the company used in the overall scenario for this guide, to illustrate the
policies and procedures required to secure Microsoft® Windows® 2000 servers in your
organization.
This chapter explains the base settings applied to the member servers at Contoso.
Changes that are needed for specific server roles are detailed in Chapter 7, "Hardening
Specific Server Roles." This includes the File and Print, Web, and Infrastructure roles.
Many of the settings that appear in the Member Server Baseline Policy (MSBP) are also
applied to the domain controller server role. The differences between the MSBP and the
domain controllers policy are explained in Chapter 7, "Hardening Specific Server Roles."
Group Policy was used to apply as many of the changes to the default Windows 2000
Server configuration as possible. For the member servers in this scenario, the Group
Policy settings described are stored in the security template baseline.inf. This template
was imported into the Member Server Baseline Policy Group Policy, which is linked to the
Member Server organizational unit (OU).
The MSBP is an area of a risk management strategy focused on common settings for all
member servers that includes audit policies, service configuration, policies that restrict
access to the registry, file system, and other specific security settings.
The location of the objects within the Microsoft® Active Directory® directory service at
Contoso is highlighted in the figure below.
133
Figure 6.1
The security template baseline.inf is imported into the MSBP, which is then linked to the Member Servers
OU
The settings contained within the baseline.inf security template are described in the
Windows 2000 Server Baseline Policy section of this chapter. This security template was
also used as the starting point for the security template called dcbaseline.inf.
The differences between baseline.inf and dcbaseline.inf are explained in Chapter 7,
"Hardening Specific Server Roles." This template was imported into the Domain
Controllers Policy Group Policy object (GPO) and linked to the Domain Controllers OU.
Step-by-step instructions for creating the OUs and group policies, and then importing the
appropriate security template into each GPO are provided in Chapter 5, "Securing the
Domain Infrastructure."
Note: Some hardening procedures can not be automated through Group Policy; these
are described in the Additional Member Server Hardening Procedures section of this
chapter.
134
Windows 2000 Server Baseline Policy
The process of configuring the settings at the domain level defines the common settings
for all member servers. This is done by creating a GPO linked to the Member Server OU,
known as a baseline policy. The GPO automates the process of configuring specific
security settings on each server.
Audit and Event Log Settings
An audit log records an entry whenever users perform certain actions that you specify.
For example, the modification of a file or a policy can trigger an audit entry. The audit
entry shows the action performed, the associated user account, and the date and time of
the action. You can audit both successful and failed attempts at actions.
The state of the operating system and applications on a computer is dynamic. For
example, security levels may be required to change temporarily to enable immediate
resolution of an administration or network issue; this change can often go unreversed.
This means that a computer may no longer meet the requirements for enterprise security.
Regular analysis enables an administrator to track and ensure an adequate level of
security on each computer as part of an enterprise risk management program. Analysis
focuses on highly specified information about all system aspects related to security. This
enables an administrator to tune the security levels, and most importantly, detect any
security flaws that may occur in the system over time.
Security auditing is extremely important for any enterprise system, as audit logs may give
the only indication that a security breach has happened. If the breach is discovered some
other way, proper audit settings generate an audit log that contains important information
about the breach.
Often the failure logs are much more informative than success logs, since failures more
often indicate error. For example, if a user successfully logs onto the system, this would
be considered normal. However, if a user unsuccessfully tries to log on to the system
multiple times, this may indicate someone is trying to break into the system using
someone else's user – ID.
The Event logs record events on the system. The security log records audit events. The
event log container of Group Policy is used to define attributes related to the application,
security, and system event logs, such as maximum log size, access rights for each log,
and retention settings and methods. The settings for the application, security, and system
event logs are configured in the MSBP and applied to all member servers in the
Northamerica domain.
135
The following table shows the settings defined in the Member Server Baseline Auditing
Policy.
Table 6.1: MSBP Audit and Event Log Policy Settings for Contoso
Full Policy Name as It Appears in the User Interface (UI)
Computer Setting
Audit account logon events
Success, Failure
Audit account management
Success, Failure
Audit directory service access
Success, Failure
Audit logon events
Success, Failure
Audit object access
Success, Failure
Audit policy change
Success, Failure
Audit privilege use
Failure
Audit process tracking
No Auditing
Audit system events
Success, Failure
Maximum application log size
10240 KB
Maximum security log size
81920 KB
Maximum system log size
10240 KB
Restrict guest access to application log
Enabled
Restrict guest access to security log
Enabled
Restrict guest access to system log
Enabled
Retain application log
Not defined
Retain security log
Not defined
Retain system log
Not defined
Retention method for application log
As needed
Retention method for security log
As needed
Retention method for system log
As needed
Shut down the computer when the security audit log is full
Disabled
Within the auditing and security options of the MSBP are a set of particularly important
auditing and event log settings that are highlighted below.
136
Auditing Settings
Vulnerability
If no auditing is configured, it will be difficult or impossible to determine what took place
during a security incident. However, if auditing is configured so that too many authorized
activities generate events, the security event log will fill up with useless data.
Countermeasure
All computers in your organization should have sensible auditing policies enabled so that
legitimate users can be held accountable for their actions and unauthorized activity can
be detected and tracked. The options for the auditing settings are:
●
Success.
●
Failure.
●
No Auditing.
Potential Impact
There will be no evidence available for network forensic analysis after security incidents
take place if the auditing is set too low on the computers in your organization. On the
other hand, if too much auditing is enabled, then the security log will fill up with
meaningless entries.
Contoso Scenario
For the Contoso network, appropriate auditing settings were chosen and implemented so
that significant security events are recorded in the security event log while most
unimportant ones are omitted. In Contoso's environment, we chose the auditing settings
as shown in Table 6.1.
The Audit Process Tracking option was configured for No Auditing specifically because of
the large number of events that could be created if the policy is enabled. This setting can
provide a large amount of benefit during an incident response from the detailed log of the
processes started and the time by any user.
Note: Turning on the capability to audit an object such as a file, folder, printer, or
registry key is a two-step process in Microsoft® Windows® 2000. After enabling the
audit object access policy, you must determine the objects to which you want to
monitor access and then modify their security descriptors accordingly.
For example, if you want to audit any attempts by users to open a particular file, you
can set a Success or Failure attribute directly on the file that you want to monitor for
that particular event using Windows Explorer or a command line tool such as
Xcacls.exe.
137
Maximum Size for Application, Security, and System Logs
Vulnerability
If you significantly increase the number of objects in your organization to audit, you run
the risk of filling the security log to capacity and thus forcing the system to shut down. If
this occurs, the system will be unusable until an administrator clears the security log. To
prevent this, you should disable the shutdown option listed in Table 6.2, below, and
increase the security log size. Both of these actions were taken in the Contoso scenario.
Countermeasure
All computers in your organization should have sensible log size policies enabled so that
legitimate users can be held accountable for their actions, unauthorized activity can be
detected and tracked, and system problems can be detected and diagnosed. Several
weeks' worth of data needed to be retained in the event logs for the Contoso servers.
Additionally, the servers have plenty of space available on their system volumes. After a
couple of weeks of testing, the busiest servers recorded as many as 5,000 security
events in a single day. By multiplying that figure by 21 days and estimating the average
event to take up 500 bytes or less within the log, a log size of about 120 megabytes (MB)
was determined to be sufficient. Another 50 percent was then added to the event log size
to provide a margin of error, which expanded it to 80 MB.
While there is no simple equation to determine the best log size for a particular server,
you can find a reasonable size through a bit of trial and error. Configure the log file size
for a sample of production servers that represent the enterprise. Then, wait two business
days and check to see how quickly the log files are filling up. Then increase or decrease
the log file size as needed to make sure that they can hold several weeks worth of
events. Wait two more business days and check the logs again, adjusting the size as
needed. Check the servers twice more over the next four weeks to verify that the logs are
retaining enough events.
Potential Impact
When event logs fill to capacity, entries can no longer be written to them unless the
retention method for each is set so that the system will overwrite the oldest entries with
the most recent ones. In the Contoso scenario, the risk of the event logs not containing
recent entries is mitigated by setting the retention method so that older events are
overwritten as needed.
The consequence of this action is that older events will be removed from the logs.
Attackers can use this to their advantage by generating a large number of extraneous
events to overwrite any evidence of their attack.
Ideally, all specifically monitored events will be sent to a server using Microsoft®
Operations Manager (MOM) or some other automated monitoring tool. This last point is
particularly important because an attacker who successfully compromises a server could
clear the security event log. If all events are sent to a monitoring server, then you will be
able to gather forensic information about the attacker's activities.
138
Contoso Scenario
The Maximum security log size was set to a value of 184,320 KB in a Group Policy
linked to the parent OU for Contoso's servers. The Maximum application log size was
set to a value of 10240 KB and the Maximum system log size to a value of 10240 KB.
These values were chosen to balance the use of disk space on the system volume with
the ability to review older events.
Contoso is utilizing MOM to monitor the server roles discussed in this guidance for
security related events.
Retention Method for Application, Security, and System Logs
Vulnerability
If you significantly increase the number of objects in your organization to audit, you run
the risk of filling the security log to capacity and thus forcing the system to shut down. If
this occurs, the system will be unusable until an administrator clears the security log. To
prevent this, you should disable the shutdown option listed in Table 6.2 and increase the
security log size. Both of these actions were taken in the Contoso scenario.
Setting the event log retention method to Manually or Overwrite events by days could
lead to important recent events not being recorded or to a Denial of Service (DoS).
Countermeasure
Set the Retention method for the system log to a value of Overwrite events as
needed in the Group Policy linked to the parent OU for all servers in your organization.
Some resources recommend configuring this setting to Manual; however, the
administrative burden that this setting imposes is too high for most organizations.
Ideally, all significant events will be sent to a monitoring server using MOM or some other
automated monitoring tool. The retention method settings are:
●
Overwrite events by days.
●
Overwrite events as needed.
●
Do not overwrite events (clear log manually).
●
Not defined.
Potential Impact
When event logs fill to capacity, entries can no longer be written to them unless the
retention method is set so that the system may overwrite the oldest entries with the most
recent ones.
Contoso Scenario
In the Contoso scenario, the risk of the event logs not containing recent entries is
mitigated by setting the retention method so that older events are overwritten as needed.
The consequence of this action is that older events will be removed from the logs. Ideally,
all significant events will be sent to a monitoring server using MOM or some other
automated monitoring tool. For these reasons, in Contoso's environment the Group
Policy in the Retention method for event logs was set to Overwrite events as needed.
Furthermore, Chapter 9, “Auditing and Intrusion Detection,” discusses some significant
events to watch for and methods for assessing and responding to information in the logs.
139
Shut Down the Computer When the Security Audit Log Is Full
Vulnerability
Security event logs contain highly critical information and must be acted upon quickly
since these logs record any failures or potential security issues on your servers. And
these events can have a cascading effect on all systems that depend on these servers.
As a part of your normal operations tasks, you should archive your security and system
logs regularly to avoid losing this important event log information.
In some organizations, it may be sufficient to retain event log information for only one or
two days, since most services failures will be noticed within this time period. However,
some servers generate a great deal of activity in most audited environments. Therefore, it
may be necessary to retain event records for longer periods, or, in some cases,
permanently.
An enterprise event management system, such as MOM, is a useful tool for centralizing,
managing, and archiving your event records in a central database. MOM is a Microsoft
product that provides centralized event and performance management of Microsoft
Windows 2000 – based servers and applications.
Countermeasure
Set the Shut down the computer when the security audit log is full to a value of
Enabled in the Group Policy linked to the parent OU for all servers in your organization.
The possible values for this Group Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
Enabling this option means that servers will shut down immediately when their event logs
are full. If your organization saves all event log data to MOM or some other enterprise
management system, and the event logs are configured to overwrite entries as needed,
then enabling this setting is a good idea. However, for many organizations the
administrative burden of enabling this setting is too high.
Contoso Scenario
The Shut down the computer when the security audit log is full setting is by default
set to Not Defined in Windows 2000 Server. In the Contoso scenario, this setting was
Disabled. While it is a security best practice to retain every security log entry to track all
attempted or successful attacks, it is impossible to prevent an attacker who has gained
administrative rights on a system from deleting some or all security log entries from the
local security event log.
Taking this into account, you will understand that configuring the computer to shut down
when the security audit log fills up only ensures that the system does not overwrite
existing entries. This configuration does nothing to prevent attackers from altering or
deleting entries. As mentioned above, an enterprise event management system is
necessary to mitigate against this vulnerability, by copying log entries off the computers
before they can be altered or deleted.
140
User Rights Assignment Configuration
Debug Programs
Vulnerability
The debug privilege can be exploited to capture sensitive system information from the
system memory. Some attack tools exploit the debug program's user right to extract
hashed passwords and other private security information. The risk of attackers being able
to exploit this vulnerability is mitigated by the fact that the debug program's user right is
by default assigned only to administrators.
Countermeasure
Revoke the Debug programs user right from all users and groups.
Potential Impact
Revoking this privilege will result in no one being able to debug programs. However,
under normal circumstances debugging is rarely necessary on production systems. If a
problem arises that requires debugging an application on a production server temporarily,
move the server to a different OU and assign the Debug programs user right to the
appropriate account.
Contoso Scenario
In the Contoso scenario, it was anticipated that administrators would rarely need to
debug applications; therefore, Group Policy was used to remove all groups from the
Debug programs user right.
141
MSBP Security Options
The Security Options section of Group Policy is used to enable or disable security
settings for computers, such as digital signing of data, Administrator and Guest account
names, floppy disk drive and CD – ROM drive access, driver installation behavior, and
logon prompts. The following security options are configured in the baseline Group
Policy.
Table 6.2: MSBP Security Option Settings
142
Full Security Option Name as It Appears in the UI
Computer Setting
Additional restrictions for anonymous connections
Do not allow enumeration
of SAM accounts and
shares.
Allow server operators to schedule tasks (domain controllers only)
Disabled.
Allow system to be shut down without having to log on
Disabled.
Allowed to eject removable NTFS media
Administrators.
Amount of idle time required before disconnecting session
15 minutes.
Audit the access of global system objects
Disabled.
Audit use of Backup and Restore privilege
Disabled.
Automatically log off users when logon time expires (see note
below)
Not Defined.
Automatically log off users when logon time expires (local) (see
note below)
Enabled.
Clear virtual memory page file when system shuts down
Enabled.
Digitally sign client communication (always)
Disabled.
Digitally sign client communication (when possible)
Enabled.
Digitally sign server communication (always)
Disabled.
Digitally sign server communication (when possible)
Enabled.
Disable CTRL+ALT+DEL requirement for logon
Disabled.
Do not display last user name in logon screen
Enabled.
LAN Manager Authentication Level
Send NTLMv2 responses
only.
Message text for users attempting to log on
This system is restricted
to authorized users.
Individuals attempting
unauthorized access will
be prosecuted. If
unauthorized, terminate
access now! Clicking on
OK indicates your
acceptance of the
information in the
background.
Message title for users attempting to log on
IT IS AN OFFENSE TO
CONTINUE WITHOUT
PROPER
AUTHORIZATION.
(continued)
Number of previous logons to cache (in case domain controller is
not available)
10 logons.
Prevent system maintenance of computer account password
Disabled.
Prevent users from installing printer drivers
Enabled.
Prompt user to change password before expiration
14 days.
Recovery Console: Allow automatic administrative logon
Disabled.
Recovery Console: Allow floppy copy and access to drives and
folders
Enabled.
Rename administrator account
Not defined.
Rename guest account
Not defined.
Restrict CD-ROM drive access to locally logged-on user only
Disabled.
Restrict floppy access to locally logged-on user only
Disabled.
Secure channel: Digitally encrypt or sign secure channel data
(always)
Disabled.
Secure channel: Digitally encrypt secure channel data (when
possible)
Enabled.
Secure channel: Digitally sign secure channel data (when possible)
Enabled.
Secure channel: Require strong (Windows 2000 or later) session
key
Enabled.
Secure system partition (for RISC platforms only)
Not defined.
Send unencrypted password to connect to third-party SMB servers
Disabled.
Shut down system immediately if unable to log security audits
Disabled.
Smart card removal behavior
Lock Workstation.
Strengthen default permissions of global system objects (for
example, Symbolic Links)
Enabled.
Unsigned driver installation behavior
Warn but allow
installation.
Unsigned non-driver installation behavior
Silently succeed.
Note: For domain accounts, there can be only one account policy. The account policy
must be defined in the Default Domain Policy, which is enforced by the domain
controllers that make up the domain. A domain controller always pulls the account
policy from the Default Domain Policy GPO, even if there is a different account policy
applied to the OU that contains the domain controller.
By default, workstations and servers joined to a domain (the member computers) also
receive the same account policy for their local accounts. However, local account
policies for member computers can be made different from the domain account policy
by defining an account policy for the OU that contains the member computers.
The default domain policy configures Automatically log off users when logon time
expires to disabled.
Because the security options in Table 6.2 merit further explanation, the rest of this
section focuses on explaining the logic behind each setting implemented in the Contoso
scenario, as well as what other options are available for each one.
143
Additional Restrictions for Anonymous Connections
Vulnerability
By default, Windows 2000 allows anonymous users to perform certain activities such as
enumerating the names of domain accounts and network shares. This allows a potential
attacker to view information on a remote server without having to authenticate who they
are with a user account.
While this vulnerability does not allow an attacker to compromise your server, it could
provide the attacker with additional information to mount an attack. To better secure
anonymous access, this option can be changed through Group Policy or via the registry.
Countermeasure
The anonymous user functionality can be changed by modifying the registry value entry
RestrictAnonymous located in the HKLM\SYSTEM\CurrentControlSet\Control\
LSA registry key to one of the following values:
●
0 — None. Rely on default permissions
●
1 — Do not allow enumeration of Security Accounts Manager (SAM) accounts
and shares
●
2 — No access without explicit anonymous permissions
The default value for the Local Security Authority (LSA) value entry in Windows 2000 is
0 – Rely on default permissions.
Additionally, the option Additional Restrictions for Anonymous Connections can also
be configured through Group Policy to provide the same functionality. This value can be
set to:
●
None: Rely on default permissions.
This provides the same functionality as RestrictAnonymous=0.
●
Do not allow enumeration of SAM accounts and shares.
This provides the same functionality as RestrictAnonymous=1.
●
No access without anonymous permissions.
This provides the same functionality as RestrictAnonymous=2.
Potential Impact
Setting RestrictAnonymous to 1 does not actually block anonymous connections.
However, this value does prevent most of the information leaks available over the null
session, primarily enumeration of user accounts and shares. Without setting this value to
2, some of this information can still be obtained.
144
However, setting the value to 2 can produce several undesirable results, depending on
the target environment. The following applications and services are known to break when
RestrictAnonymous is set to 2:
●
The RestrictAnonymous = 2 setting is recommended for Windows 2000 in
various white papers and tools from Microsoft and other sources including the
MBSA tool, but the setting is only supported in environments where all systems are
running Windows 2000 or later. Support from Microsoft Product Support Services
(PSS) for Windows 2000 will be provided on a best effort basis only. Further, the
effect of the Windows 2000 RestrictAnonymous setting is spread across more
than one Group Policy setting in the later supported platforms. If you want to use
RestrictAnonymous = 2 in your environment, proceed at your own risk and test it
thoroughly in your platform testing environment for application incompatibility.
●
Down – level member workstations or servers can not set up a secure channel to
the server.
●
Down – level domain controllers in trusting domains can not set up a Net logon
secure channel to domain controllers with the RestrictAnonymous registry value
set to 2.
●
Microsoft® Windows NT® users can not change their passwords after the
passwords expire. Also, Macintosh computer users can not change their
passwords at all.
●
The Browser service can not retrieve domain lists or server lists from backup
browsers, master browsers, or domain master browsers that are running on
computers with the RestrictAnonymous registry value set to 2. Because of this,
any program that relies on the Browser service does not function properly.
●
If you use a Microsoft® Outlook® client computer that connects to a
Microsoft® Exchange 2000 Server, you will not be able to look through the global
address list or resolve names referenced from it. The global address list appears
as empty. This issue was fixed in Windows 2000 Service Pack 3.
●
You may not be able to add a network printer by selecting it from the Active
Directory on domain controllers with the RestrictAnonymous registry value set to
2. However, you can still add a network printer by selecting it from the tree view.
Because of these known issues, it is not recommended to set RestrictAnonymous to 2
in a mixed client environment. For details on the effect that this may have in your
environment, see the Microsoft Knowledge Base article Q246261, "How to Use the
RestrictAnonymous Registry Value in Windows 2000."
Contoso Scenario
In the Contoso scenario, Group Policy was used to set Additional Restrictions for
Anonymous Connections to Do not allow enumeration of SAM accounts and
shares because of the mixed client scenario environment.
Allow System to Be Shut Down Without Having to Log On
Vulnerability
Users who can access the console locally or through Terminal Services could shut the
system down. An attacker or a misguided user could connect to the server via Terminal
Services and shut it down or restart it without having to identify him – or herself.
An attacker could also perform this action by walking up to the local console. A server will
be restarted, causing a temporary DoS condition, or a server will be shut down leaving all
of its applications and services unavailable.
145
Countermeasure
Set the Allow system to be shut down without having to log on to the value Disabled
in the Group Policy linked to the parent OU for servers. The possible values for this
Group Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
Administrators will have to log on to servers to shut them down or restart them.
Contoso Scenario
In the Contoso scenario, there is no reason for users to be able to shut down servers
from the console without needing to log on first. Therefore, Group Policy was used to set
Allow system to be shut down without having to log on to Disabled.
Allowed to Eject Removable NTFS Media
Vulnerability
Users may be able to move NTFS – formatted removable disks to a different computer
where they have administrative privileges. If a removable disk is moved to a computer
where the user has administrative privileges, the user could take ownership of any file,
grant him – or her full control and view or modify any file. Sensitive information may be
exposed, or data could be altered in an undetectable way. The value of this setting is
diminished by the fact that most removable storage devices will eject media by the press
of a button.
Countermeasure
Set the Allowed to eject removable NTFS media value to Administrators in the Group
Policy linked to the parent OU for servers. The possible values for this Group Policy
setting are:
●
User-defined security accounts.
●
Not defined.
Potential Impact
Only administrators will be able to eject NTFS – formatted removable media.
Contoso Scenario
The only people who need to be able to remove NTFS – formatted removable media are
administrators. Therefore, in the Contoso scenario, Group Policy was used to set
Allowed to eject removable NTFS media to the Administrators group.
Amount of Idle Time Required Before Disconnecting Session
Vulnerability
Each server message block (SMB) session consumes server resources. If numerous null
sessions are established, the server will slow down or possibly fail. An attacker could
repeatedly establish SMB sessions until the server stops responding. SMB services will
become slow or unresponsive.
146
Countermeasure
Set the Amount of idle time required before disconnecting session to the value 15
minutes in the Group Policy linked to the parent OU for servers. The possible values for
this Group Policy setting are:
●
User-defined period of time in minutes.
●
Not defined.
Potential Impact
There will be little impact because SMB sessions will be re – established automatically if
the client resumes activity.
Contoso Scenario
To help protect the Contoso servers from SMB-based DoS attacks, Group Policy was
used to set Amount of idle time required before disconnecting session to 15
minutes.
Audit the Access of Global System Objects
Vulnerability
If this policy is enabled, it causes system objects, such as mutexes, events, semaphores,
and DOS devices, to be created with a default system access control list (SACL). If the
Audit object access audit policy is also enabled, access to these system objects is
audited.
Countermeasure
Set the Audit the access of global system objects to Disabled in the Group Policy
linked to the parent OU for servers. The possible values for this Group Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
Enabling this policy this could generate a large number of security events, especially on
busy domain controllers and application servers. This could cause servers to respond
slowly and force the security event log to record numerous events of little significance.
Contoso Scenario
To help prevent the security event logs on the Contoso servers from filling with
unimportant events, Group Policy was used to set Audit the access of global system
objects to Disabled.
Audit Use of Backup and Restore Privilege
Vulnerability
This setting determines whether backup and restore user privileges are audited when the
Audit privilege use policy is in effect. Enabling this option when the Audit privilege use
policy is also enabled generates an audit event for every file that is backed up or
restored. Enabling this setting could help you to track down an administrator who is
accidentally or maliciously restoring data in an unauthorized manner.
147
Countermeasure
Set the Audit use of Backup and Restore privilege to the value Disabled in the Group
Policy linked to the parent OU for servers. The possible values for this Group Policy
setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
Enabling this policy this could generate a large number of security events, which could
cause servers to respond slowly and force the security event log to record numerous
events of little significance.
Contoso Scenario
To help prevent the security event logs on the Contoso servers from filling with
unimportant events, Group Policy was used to set Audit use of Backup and Restore
privilege to Disabled.
Automatically Log Off Users When Logon Time Expires (Local)
Vulnerability
This setting determines whether to disconnect users who are connected to the local
computer outside of their user account's valid logon hours. This setting affects the SMB
component of a Windows 2000 Server. When this policy is enabled, it causes client
sessions with the SMB server to be forcibly disconnected when the client's logon hours
expire. If this policy is disabled, an established client session is allowed to be maintained
after the client's logon hours have expired.
Countermeasure
Set the Automatically log off users when logon time expires (local) to the value of
Enabled in the Group Policy linked to the parent OU for servers. The possible values for
this Group Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
This setting does not apply to administrator accounts.
Potential Impact
SMB sessions will be terminated on member servers when a user's logon time expires,
and the user will be unable to log on to the system until his or her next scheduled access
time commences.
Contoso Scenario
To help protect servers in the Contoso scenario from members of the information
technology (IT) team who forget to log off of their console sessions, Group Policy was
configured to set Automatically log off users when logon time expires (local) to
Enabled.
148
Clear Virtual Memory Page File When System Shuts Down
Vulnerability
Important information kept in real memory may be dumped periodically to the page file.
This helps Windows 2000 handle multitasking functions. An attacker who has physical
access to a server that has been shut down could view the contents of the paging file.
The attacker would move the system volume into a different computer and then analyze
the contents of the paging file. This is a time consuming process, but data cached from
random access memory (RAM) to the paging file could be exposed.
Note: An attacker who has physical access to the server could bypass this
countermeasure by simply unplugging the server from its power source.
Countermeasure
Set the Clear virtual memory page file when system shuts down to the value of
Enabled in the Group Policy linked to the parent OU for servers. With this setting
enabled, Windows 2000 will clear the page file when the system is shut down, removing
all information stored in this file. Depending on the size of the page file, this process
could take several minutes before the system completely shuts down. The possible
values for this Group Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
Shutting down and restarting the server will take longer and will be especially noticeable
on servers with large paging files. For a server with 2 gigabytes GB of RAM and a 2 – GB
paging file this setting may add 20 minutes, 30 minutes, or even more to the shutdown
process. For some organizations, downtime of this duration violates their internal service
level agreements. Therefore, use caution when implementing this countermeasure in
your environment.
Contoso Scenario
Although the Contoso servers are physically secured Contoso decided to implement this
setting because it is more secure and it will have no impact on legacy applications and
operating systems connecting to the server. Group Policy is used to set Clear virtual
memory page file when system shuts down to Enabled.
149
Digitally Sign Client & Server Communications
Vulnerability
There are four separate settings relating to digitally signing SMB communications:
Digitally Sign Client Communications (Always), Digitally Sign Server
Communications (Always), Digitally Sign Client Communications (When Possible),
and Digitally Sign Server Communications (When Possible).
Implementing digital signing in high security networks helps prevent the impersonation of
clients and servers. This type of impersonation is known as session hijacking — a type of
exploit in which session hijacking tools allow an attacker to interrupt, end, or steal a
session in progress. Unsigned SMB packets could be intercepted and modified by an
attacker. An attacker who had access to the same network as the client or server could
intercept SMB traffic. The attacker could then modify the traffic and forward it so that the
server might perform undesirable actions. Alternatively, the attacker could pose as the
server or client after a legitimate authentication and gain unauthorized access to data.
SMB signing authenticates both the user and the server hosting the data. If either side
fails the authentication process, data transmission will not take place. When SMB signing
is implemented, there may be a noticeable performance impact to sign and verify each
packet between the servers.
Note: An alternative countermeasure that could protect all network traffic would be to
implement digital signatures with Internet Protocol security (IPsec). There are
hardware-based accelerators for IPSec encryption and signing that could be used to
minimize the performance impact from the servers' CPU. There are no such
accelerators available for SMB signing.
Countermeasure
Set Digitally sign client communication (always) to Disabled; Digitally sign client
communication (when possible) to Enabled; Digitally sign server communication
(always) to Disabled; and Digitally sign server communication (when possible) to
Enabled in a Group Policy linked to the parent OU for servers. Some resources
recommend configuring all of these settings to Enabled, but enabling them may cause
slower performance on client computers, and it will prevent them from communicating
with legacy SMB applications and operating systems. The possible values for this Group
Policy setting are:
150
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
The Windows 2000 Server, Windows 2000 Professional, and Windows XP Professional
file and print sharing protocol SMB supports mutual authentication, which closes session
hijacking attacks and supports message authentication, thus preventing active message
attacks. SMB signing provides this authentication by placing a digital signature into each
SMB, which is then verified by both the client and the server.
However, forcing all SMB traffic to be digitally signed will have a performance impact; on
busy servers; this impact could be substantial. Additionally, when computers are
configured to ignore all unsigned SMB communications, legacy applications and
operating systems will be unable to connect. Completely disabling all SMB signing leaves
the computers vulnerable to session hijacking attacks.
Contoso Scenario
In the Contoso scenario, Digitally Sign was disabled on all SMB traffic due to concerns
about performance. Group Policy was used to set Digitally sign client communication
(always) to Disabled; Digitally sign client communication (when possible) to
Enabled; Digitally sign server communication (always) to Disabled; and Digitally
sign server communication (when possible) to Enabled.
Disable CTRL+ALT+DEL Requirement for Logon
Vulnerability
Microsoft developed this feature to help users with certain types of physical impairments
to make it easier for them to log on to Windows computers running Windows. Not having
to press the key combination CTRL+ALT+DEL leaves users susceptible to attacks that
attempt to intercept their passwords. Requiring CTRL+ALT+DEL before users log on
ensures that users are communicating by means of a trusted path when entering their
passwords.
An attacker could install a Trojan horse program (a type of malicious code) that looks like
the standard Windows logon dialog box and capture the user's password. The attacker
would then be able to log on to the compromised account with whatever level of privilege
that user has.
Countermeasure
Set Disable CTRL+ALT+DEL requirement for logon to Disabled in the Group Policy
linked to the parent OU for servers. The possible values for this Group Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
Users have to simultaneously hold down three keys before the logon dialog box will
appear (unless they are using a smart card to log on).
Contoso Scenario
In the Contoso scenario, there is no reason for users to be able to log on to a server
without pressing the three keys; therefore, Group Policy was used to configure the value
for the Disable CTRL+ALT+DEL requirement for logon setting to Disabled.
151
Do Not Display Last User Name in Logon Screen
Vulnerability
An attacker with access to the console, for example somebody with physical access or
somebody who is able to connect to the server via Terminal Services, could view the
name of the last user who logged on to the server. The attacker could then attempt to log
on to the server by guessing the password, using an automated tool to determine the
password from a dictionary, or by brute force.
Countermeasure
Set Do not display last user name in logon screen to the value Enabled in the Group
Policy linked to the parent OU for servers. The possible values for this Group Policy
setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
Users will always have to type their user names when logging on to the servers.
Contoso Scenario
In the Contoso scenario, there was concern that an attacker could view the user name of
the last user to log onto a server; therefore, Group Policy was used to set Do not display
last user name in logon screen to Enabled.
LAN Manager Authentication Level
LAN Manager (LM) is a family of early Microsoft client/server software that allows users
to link personal computer systems together on a single network. Networking capabilities
include transparent file and print sharing, user security features, and network
administration tools.
LM authentication, including the LM, NTLM, and NTLM version 2 (NTLMv2) variants, is
the protocol used to authenticate all Windows clients for such operations as:
152
●
Joining a domain.
●
Authenticating between Active Directory forests.
●
Authenticating to downlevel domains.
●
Authenticating to downlevel (non – Windows 2000 or Windows XP – based servers).
●
Authenticating to nondomain servers.
Vulnerability
All Windows clients (including Windows 2000 and Windows XP) are configured by default
to send LM and NTLM authentication responses (except Win9x clients, which only send
LM). The default setting on servers allows all clients to authenticate with servers and use
their resources. However, this means that LM responses (the weakest form of
authentication response) will be sent over the network, and will potentially be potentially
available for attackers to sniff that traffic and attempt to more easily reproduce the user's
password.
The Windows 9x and Windows NT operating systems can not use the Kerberos version 5
protocol for authentication. For this reason, by default these systems authenticate with
both the LM and NTLM protocols for network authentication in a Windows 2000 domain.
You can enforce a more secure authentication protocol for Windows 9x and Windows NT
by using NTLMv2. For the logon process, NTLMv2 uses a secure channel to protect the
authentication process. Even if you do use NTLMv2 for legacy clients and servers,
Windows 2000 – based clients and servers that are members of the domain will
authenticate with Windows 2000 domain controllers using the Kerberos protocol.
For information about enabling NTLMv2, see Knowledge Base article Q239869, "How to
Enable NTLM 2 Authentication for Windows 95/98/2000/NT." Microsoft® Windows NT®
4.0 requires Service Pack 4 (SP4) to support NTLMv2, and Windows 9x platforms need
the directory service client installed in order to support NTLMv2.
Countermeasure
Set LAN Manager Authentication Level to Send NTLMv2 responses only in the
Group Policy linked to the parent OU for servers. This level of authentication is strongly
recommended by Microsoft and a number of independent organizations when all clients
support NTLMv2.
The possible values for this Group Policy setting are:
●
Send LM & NTLM responses.
●
Send LM & NTLM — use NTLMv2 session security if negotiated.
●
Send NTLM responses only.
●
Send NTLMv2 responses only.
●
Send NTLMv2 responses only\refuse LM.
●
Send NTLMv2 responses only\refuse LM & NTLM.
●
Not Defined.
These settings correspond to the levels discussed in other documents from Microsoft as
follows:
●
Level 0 – Send LM and NTLM response; never use NTLMv2 session security.
Clients use LM and NTLM authentication, and never use NTLMv2 session security;
domain controllers accept LM, NTLM, and NTLMv2 authentication.
●
Level 1 – Use NTLMv2 session security if negotiated. Clients use LM and NTLM
authentication, and use NTLMv2 session security if the server supports it; domain
controllers accept LM, NTLM, and NTLMv2 authentication.
●
Level 2 – Send NTLM response only. Clients use only NTLM authentication, and
use NTLMv2 session security if the server supports it; domain controllers accept
LM, NTLM, and NTLMv2 authentication.
●
Level 3 – Send NTLMv2 response only. Clients use NTLMv2 authentication, and
use NTLMv2 session security if the server supports it; domain controllers accept
LM, NTLM, and NTLMv2 authentication.
153
●
Level 4 – Domain controllers refuse LM responses. Clients use NTLM
authentication, and use NTLMv2 session security if the server supports it; domain
controllers refuse LM authentication (that is, they accept NTLM and NTLMv2).
●
Level 5 – Domain controllers refuse LM and NTLM responses (accept only
NTLMv2). Clients use NTLMv2 authentication, use and NTLMv2 session security if
the server supports it; domain controllers refuse NTLM and LM authentication (they
accept only NTLMv2).
Potential Impact
Clients that do not support NTLMv2 authentication will not be able to authenticate in the
domain and access domain resources using LM and NTLM.
Contoso Scenario
In the Contoso scenario, Group Policy was used to set the LAN Manager
Authentication Level to Send NTLMv2 responses only. This setting was chosen so
that legacy Windows clients that are not configured to use NTLMv2 security can still use
the domain resources. This means that the less secure authentication traffic will pass
over the network. An attacker who is able to sniff traffic on the network may be able to
collect NTLM authentication traffic to determine user names and passwords of domain
members. Network sniffing is the inspection of network traffic.
The Windows 98 clients will continue to use LM or NTLM authentication, and will continue
to be authenticated by the domain controllers because of the setting above. These
machines could be configured to only use NTLMv2 if the DSClient was installed on the
machines. Because of the large amount of work required to install the DSClient on all
Windows 98 machines, Contoso has accepted the fact that this vulnerability will exist until
these workstations are updated.
Note: Refer to Microsoft Knowledge Base article 305379, " Authentication Problems in
Windows 2000 with NTLM 2 Levels Above 2 in a Windows NT 4.0 Domain" located at
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q305379 for information
about a hotfix to ensure that this setting works in networks with a mix of Windows 2000
and Windows NT 4.0 systems.
Message Title and Text for Users Attempting to Log On
Vulnerability
Not utilizing this message warning setting leaves your organization legally vulnerable to
trespassers who unlawfully penetrate your network. Legal precedents over the past
couple of decades have established that organizations that display warnings to users
who connect to their servers over a network have a higher rate of successful prosecution
of trespassers than organizations that do not.
154
Countermeasure
Set Message text for users attempting to log on to the following message value:
This system is restricted to authorized users. Individuals attempting
unauthorized access will be prosecuted. If unauthorized, terminate access
now! Clicking on OK indicates your acceptance of the information in the
background.
Set Message title for users attempting to log on to:
IT IS AN OFFENSE TO CONTINUE WITHOUT PROPER AUTHORIZATION.
Apply both of these settings in the Group Policy linked to the parent OU for servers. The
possible values for these Group Policy settings are:
●
User-defined text.
●
Not defined.
Potential Impact
Users will see a dialog box before they will be able to log on to the console of the server.
Note: Any warning that you display should first be approved by your organization's
legal and human resources representatives.
Contoso Scenario
In order to facilitate prosecution of attackers, Group Policy is used to set Message text
for users attempting to log on and Message title for users attempting to log on to
the message text indicated above.
Number of Previous Logons to Cache (in Case Domain Controller is
Not Available)
Vulnerability
The number assigned to this setting indicates the number of users whose logon
information will be cached locally. If the number is set to 10, then the logon information
for 10 users will be cached. When an eleventh user logs on to the computer, the oldest
cached logon session will be overwritten.
Users who access the console of the server will have their logon credentials cached on
that server. An attacker who is able to access the file system of the server could locate
this cached information and use a brute force attack to determine passwords for the
users.
This type of attack is mitigated by the way in which Windows 2000 secures this sensitive
information. The cached credentials are kept in the registry of the systems, which is
encrypted and spread across numerous physical locations.
Countermeasure
Set Number of previous logons to cache (in case domain controller is not
available) to a value of 10 in the Group Policy linked to the parent OU for servers. Some
resources suggest setting this value to 0.
155
This setting was configured so that in the event of failure to communicate with a domain
controller, users will still be able to log on to computers. The possible values for this
Group Policy setting are:
●
User-defined number.
●
Not defined.
Potential Impact
Logon information will be cached locally on the servers.
Contoso Scenario
To ensure that authorized users could log on to the Contoso servers even when the
domain controllers were unavailable, Group Policy is used to set Number of previous
logons to cache (in case domain controller is not available) to 10.
Prevent System Maintenance of Computer Account Password
Vulnerability
The default configuration for computers running Windows 2000 that belong to a domain is
that they are automatically required to change the passwords for their accounts every
seven days. Disabling this feature causes computers running Windows 2000 to retain the
same passwords as their computer accounts. Computers that are no longer able to
automatically change their account passwor are under risked risk of an attacker
determining the password for the system's domain account.
Countermeasure
Verify that the Prevent system maintenance of computer account password option is
set to Disabled. The possible values for this Group Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
None.
Contoso Scenario
In the Contoso scenario, we wanted to minimize the risk of an attacker determining a
computer's password for its domain account. Therefore, Group Policy is used to set
Prevent system maintenance of computer account password to the value Disabled.
Prevent Users from Installing Printer Drivers
Vulnerability
It may be appropriate to enable users to allow printer access on their own workstations,
but this is not suitable for servers. Installing a printer driver on a server may
unintentionally cause the system to become less stable. Only administrators should have
this privilege on servers.
A malicious user may deliberately try to damage your organization's system by installing
inappropriate printer drivers. A malicious user is anyone who has access to a system and
poses a security threat to it. An example would be people who try to elevate their
privileges to gain access to unauthorized data.
156
Countermeasure
Set Prevent users from installing printer drivers to the value Enabled in the Group
Policy linked to the parent OU for servers. The possible values for this Group Policy
setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
Only users with Administrative, Power User, or Server Operator privileges will be able to
install printers on the servers.
Contoso Scenario
In the Contoso scenario, only administrators should ever need to install printer drivers.
Therefore, Group Policy was used to set Prevent users from installing printer drivers
to the value Enabled.
Prompt User to Change Password Before Expiration
Vulnerability
In the Contoso scenario, user passwords expire periodically. If users are not notified
when their passwords are about to expire, they may not realize it until the passwords has
already expired. This could lead to confusion for users accessing the network locally, or
make it impossible for users who are accessing your organization's network via dial – up
or virtual private network (VPN) connections to log on to the network.
Countermeasure
Set Prompt user to change password before expiration to a value of 14 days in the
Group Policy linked to the parent OU for servers. The possible values for this Group
Policy setting are:
●
User defined number of days.
●
Not defined.
Potential Impact
Users will see a dialog box each time that they log on to the domain when the expiration
date for their password is 14 days or fewer in the future.
Contoso Scenario
In the Contoso scenario, the security team wanted to be sure that users changed their
passwords before they expired. Therefore, Group Policy was used to set Prompt user to
change password before expiration to 14 days.
Recovery Console: Allow Automatic Administrative Logon
Vulnerability
The Recovery Console can be very useful when troubleshooting and repairing systems
that can not be restarted. However, configuring this setting to enable automatic log on to
the console is dangerous. Anyone could walk up to the server, shut it down by
disconnecting the power, reboot it, select Recover Console from the restart menu, and
then assume full control of the server.
157
Countermeasure
Set Recovery Console: Allow automatic administrative logon to Disabled in the
Group Policy linked to the parent OU for servers. The possible values for this Group
Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
When the Recovery Console is utilized, the user will have to enter a user name and
password to access the Recovery Console account.
Contoso Scenario
In the Contoso scenario, whenever the Recovery Console must be used, an authorized
member of the IT team will be present to troubleshoot and repair the computer.
Therefore, Group Policy was used to set Recovery Console: Allow automatic
administrative logon to Disabled.
Recovery Console: Allow Floppy Copy and Access to Drives and
Folders
Vulnerability
An authorized administrator could forget to remove a CD-ROM or floppy disk with
sensitive data or applications that a malicious user could then steal. An authorized
administrator could accidentally leave a startup disk in the computer after having used
the Recovery Console. If the computer restarted for any reason and the Basic
Input/Output System (BIOS) was configured to boot from the CD-ROM or floppy disk
drive before the hard disk the server would start from the removable disk. This would
cause the server's network services to be unavailable.
Countermeasure
Set Recovery Console: Allow floppy copy and access to drives and folders to the
value Enabled in the Group Policy linked to the parent OU for servers. Some resources
suggest disabling this setting. However, enabling it gives the administrator more flexibility
when working with a failed server through the Recovery Console. The possible values for
this Group Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
Users who have started a server via the Recovery Console and logged in with the built-in
Administrator account will not be able to copy files and folders to a floppy disk.
Contoso Scenario
In the Contoso scenario, it was decided to retain the option to be able to copy files from a
CD – ROM or floppy disk while using the Recovery Console to repair an unusable server.
Therefore, Group Policy was used to set Recovery Console: Allow floppy copy and
access to drives and folders to Enabled.
158
Restrict Removable Media Access to Locally Logged-On User Only
Vulnerability
This policy determines whether a CD – ROM is accessible to both local and remote users
simultaneously. If this policy is enabled, it allows only the interactively logged – on user to
access removable CD – ROM media. If this policy is enabled and no one is logged on
interactively, the CD – ROM can be accessed over the network.
Countermeasure
Disable both Restrict CD – ROM drive access to locally logged-on user only and
Restrict floppy access to locally logged – on user only in the Group Policy linked to
the parent OU for servers. The possible values for these Group Policy settings are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
If this setting is enabled users connecting to the server over the network will not be able
to utilize any CD – ROM or floppy disk drives installed on the server. Additionally, this
setting causes problems for management tools that leverage WMI, for example, when
this setting is enabled the Disk Management console will take as long as 30 seconds to
open and after opening no CD – ROM drives will appear in the tool. This setting would not
be suitable for a system serving as a CD jukebox for network users.
Contoso Scenario
Because Contoso relies on the Disk Management tool for managing storage volumes
these settings were disabled. Group Policy was used to set Restrict CD – ROM drive
access to locally logged-on user only to Disabled and set Restrict floppy access to
locally logged – on user only to Disabled.
Secure Channel: Digitally Encrypt or Sign Secure Channel Data
Vulnerability
When a Windows 2000 system joins a domain, a computer account is created. After
joining the domain, it uses the password for that account to create a secure channel with
the domain controller for its domain every time that it restarts. Requests sent on the
secure channel are authenticated, and sensitive information (such as passwords) is
encrypted. But the channel is not integrity checked, and not all information is encrypted.
There are several settings relating to this countermeasure: Secure channel: Digitally
encrypt or sign secure channel data (always); Secure channel: Digitally encrypt
secure channel data (when possible); and Secure channel: Digitally sign secure
channel data (when possible). If a system is set to always encrypt or sign secure
channel data, then a secure channel can not be established with a domain controller that
is not capable of signing or encrypting all secure channel traffic, because all secure
channel data is signed and encrypted. If the computer is configured to encrypt or sign
secure channel data when possible, a secure channel can be established, but the level of
encryption and signing is negotiated.
159
Countermeasure
Set Secure channel: Digitally encrypt or sign secure channel data (always) to the
value Disabled; Secure channel: Digitally encrypt secure channel data (when
possible) to the value Enabled; and Secure channel: Digitally sign secure channel
data (when possible) to the value Enabled in the Group Policy linked to the parent OU
for servers. The possible values for this Group Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
Digital encryption and signing of the “secure channel” is a good idea where it is
supported. The secure channel is the Netlogon communication channel for protecting
domain credentials as they are sent to the domain controller. However, digital encryption
and signing of the secure channel is only supported in Windows NT 4.0 SP6a or later,
and is not supported in Windows 98SE clients. Thus, this setting can not be enabled on
domain controllers when they have to support Windows 98 clients as members of the
domain. Potential impact can include disabling the ability to create or delete down – level
trust relationships, disabling logons from downlevel clients, and not being able to
authenticate other domains' users from a downlevel trusted domain.
Once all Windows 9x clients have been eliminated from the domain, and all Windows NT
4.0 servers and domain controllers (from trusted/trusting domains) have been upgraded
to SP6a, this setting could be enabled.
Secure channel data transmitted between downlevel clients and the servers in your
organization may not be encrypted or protected with digital signatures.
Contoso Scenario
Some guidance exists that suggests configuring all of these to Enabled, but to ensure
backward compatibility, the Contoso servers were configured to digitally sign and encrypt
their secure channel data when communicating with computers that support the feature.
In the Contoso scenario, Group Policy was used to set Secure channel: Digitally
encrypt or sign secure channel data (always) to Disabled; Secure channel: Digitally
encrypt secure channel data (when possible) to Enabled; and Secure channel:
Digitally sign secure channel data (when possible) to Enabled.
Secure Channel: Require Strong (Windows 2000 or Later) Session
Key
Vulnerability
Session keys in older versions of the Windows operating system are not as secure as
those in Windows 2000 Server. Session keys used to establish secure channel
communications between domain controllers and member computers are much stronger
in Windows 2000 than they were in previous operating systems from Microsoft.
Whenever possible, you should take advantage of these stronger session keys to help
protect secure channel communications from eavesdropping and session hijacking
network attacks. Eavesdropping is a form of hacking in which network data is read or
altered in transit. The data can be modified to hide or change the sender, or to redirect it.
160
Countermeasure
Set Secure channel: Require strong (Windows 2000 or later) session key to
Enabled in the Group Policy linked to the parent OU for servers. The possible values for
this Group Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Enabling this setting ensures that all outgoing secure channel traffic will require a strong
(Windows 2000 or later) encryption key. If this policy is disabled, the key strength is
negotiated with the remote server. This option should only be enabled if the Domain
Controllers in all trusted domains support strong keys. By default, this value is disabled.
Potential Impact
You will be unable to join computers running Windows 2000 with this setting enabled to
Windows NT 4.0 domains.
Contoso Scenario
In the Contoso scenario, there are no remaining NT 4.0 domains, so Group Policy was
used to set Secure channel: Require strong (Windows 2000 or later) session key to
Enabled.
Send Unencrypted Password to Connect to Third-Party SMB Servers
Vulnerability
If this setting is enabled, the server could transmit passwords in cleartext across the
network to other systems offering SMB services. These others systems may not utilize
any of the SMB security mechanisms included with Windows 2000. Cleartext is used in a
message that is not encrypted. Cleartext messages are also referred to as plaintext
messages.
Countermeasure
Set Send unencrypted password to connect to third – party SMB servers to
Disabled in the Group Policy linked to the parent OU for servers. The possible values for
this Group Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
Some very old applications and operating systems may not be able to communicate with
the servers in your organization via the SMB protocol.
Contoso Scenario
There are no third – party SMB servers in the Contoso scenario; therefore, Group Policy is
used to set Send unencrypted password to connect to third-party SMB servers to
Disabled.
161
Shut Down System Immediately if Unable to Log Security Audits
Vulnerability
This setting is removed to prevent a DoS attack aimed at filling the security log to
capacity with audit entries. Configuring computers to shut down when the security log is
full could lead to a DoS condition.
Some resources recommend configuring this setting to Manual; however, the
administrative burden is too high for most organizations to do this. Ideally, all significant
events will be sent to a monitoring server using MOM or some other automated
monitoring tool.
Countermeasure
Set Shut down system immediately if unable to log security audits to Disabled in
the Group Policy linked to the parent OU for servers. The possible values for this Group
Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
If the security log fills to capacity, the computer will continue to operate without recording
additional events. The risk of unrecorded security events is mitigated by setting the
Retention method for the security log to As needed.
Contoso Scenario
The administrative burden of enabling this setting in the Contoso scenario was
determined to be too high; therefore, Group Policy is used to set Shut down system
immediately if unable to log security audits to Disabled.
Smart Card Removal Behavior
Vulnerability
If smart cards are used for authentication, then the computer should automatically lock
itself when the card is removed. If this setting is not used, users may forget to manually
lock their workstations when they are away from them. This may allow a malicious user to
access another user's computer to obtain sensitive information or make unauthorized
changes to the computer or the network.
Countermeasure
Set Smart card removal behavior to Lock Workstation in the Group Policy linked to
the parent OU for servers. The possible values for this Group Policy setting are:
●
162
No Action.
●
Lock Workstation.
●
Force Logoff.
●
Not defined.
Potential Impact
Users will have to re-insert their smart cards and re – enter their personal identification
numbers (PINs) when they return to their workstations.
Contoso Scenario
We wanted to ensure that the console for servers in the Contoso scenario would not be
accessible when administrators removed their smart cards; therefore, Group Policy was
used to set Smart card removal behavior to Lock Workstation.
Strengthen Default Permissions of Global System Objects (for
Example, Symbolic Links)
Vulnerability
This setting determines the strength of the default discretionary access control list
(DACL) for objects. Windows 2000 maintains a global list of shared system resources
such as DOS device names, mutexes, and semaphores.
In this way, objects can be located and shared among processes. Each type of object is
created with a default DACL that specifies who can access the objects with what
permissions. If this policy is enabled, the default DACL is strengthened, allowing nonadministrator users to read shared objects, but not to modify shared objects that they did
not create.
Countermeasure
Set Strengthen default permissions of global system objects (for example,
Symbolic Links) to Enabled in the Group Policy linked to the parent OU for servers. The
possible values for this Group Policy setting are:
●
Enabled.
●
Disabled.
●
Not defined.
Potential Impact
None.
Contoso Scenario
In order to further secure the Contoso servers, Group Policy was used to set Strengthen
default permissions of global system objects (for example, Symbolic Links) to
Enabled.
Unsigned Driver Installation Behavior
Vulnerability
This option prevents the installation of unsigned drivers, or warns the administrator that
an unsigned driver software is about to be installed. This can prevent the installation of
drivers that have not been certified to run on Windows 2000.
163
Countermeasure
Set Unsigned driver installation behavior to the value Warn but allow installation in
the Group Policy linked to the parent OU for servers. This differs from the default setting
in Windows 2000, which is Not defined. The possible values for this Group Policy setting
are:
●
Warn but allow installation.
●
Do not allow installation.
●
Not defined.
Potential Impact
A less restrictive setting was used in the Contoso scenario to give more flexibility to
administrators for using unsigned drivers. Users with sufficient privileges to install device
drivers will be able to install unsigned device drivers. However, this could result in
stability problems for system servers. Another potential problem with setting this to Warn
but allow installation is that unattended installation scripts will fail if they attempt to
install unsigned drivers.
Contoso Scenario
In the Contoso scenario, it was decided the administrators should have the flexibility to
install unsigned drivers when it is determined to be the best course of action. Therefore,
Group Policy was used to set Unsigned driver installation behavior to Warn but allow
installation.
Unsigned Non – Driver Installation Behavior
Vulnerability
This option prevents the installation of unsigned applications, or warns the administrator
that an unsigned non – driver software application is about to be installed. This can
prevent the installation of non – driver software that has not been certified to run on
Windows 2000.
Countermeasure
Set Unsigned non – driver installation behavior to the value the Silently succeed in
the Group Policy linked to the parent OU for servers. Other guidance exists that suggests
setting this to Warn but allow installation. This setting was chosen so that Exchange
2000 Server and other applications can be installed in an unattended manner and to
prevent installation warnings from being generated by other unsigned applications. The
possible values for this Group Policy setting are:
164
●
Silently succeed.
●
Warn but allow installation.
●
Do not allow installation.
●
Not defined.
Potential Impact
Code signing has not been implemented in most software applications and services. Not
only does this policy setting has no real benefit since there is little or no signed
application software to distinguish from the masses of unsigned application software, but
it could prevent or make difficult the installation of software that has been tested in your
own certification environment — this is especially true of unattended installs which can be
stalled even by the Warn but allow installation setting.
Users with sufficient privileges to install applications will be able to install applications that
have not been digitally signed. This could result in stability problems for the server.
Contoso Scenario
In the Contoso scenario, the default setting was chosen so that unsigned application
software such as Exchange 2000 Server can be installed in an unattended manner, and
so that other unsigned applications can be installed without generating hundreds of error
messages. Group Policy was used to set Unsigned non-driver installation behavior to
Silently succeed.
Services Configuration
When Windows 2000 Server is first installed, default services are created and are
configured to run when the system starts. Many of these services do not need to run in
the Contoso network of the Contoso scenario.
Any service or application is a potential point of attack. Therefore, any unneeded services
or executable files should be disabled or removed in your system environment. There are
additional optional services available with Windows 2000, such as Certificate Services,
that are not installed during a default installation of Windows 2000 Server.
These optional services can be added to an existing system by using Add/Remove
Programs or the Windows 2000 Configure Your Server Wizard, or by creating a
customized automated installation of Windows 2000. In the MSBP, these optional
services, as well as all unnecessary services, are disabled.
The MSBP only enables the services required for a Windows 2000 member server to
participate in a Windows 2000 domain and provide basic management services. Specific
services required for each server role are enabled via role – specific group policies as
described in Chapter 7, "Hardening Specific Server Roles."
If additional server types were needed on the Contoso network, it would then have been
necessary to enable additional services. For example, if a certificate server was going to
be used for distributing Secure Socket Layer (SSL), secure e – mail and other types of
certificates to end users, then Certificate Services would need to be installed. A Group
Policy that applies to that new server role would also need to be created that sets the
Certificate Services service to Automatic. For descriptions of the purposes for all of the
services included with Windows 2000 Server, see Appendix A, "Purpose of Windows
2000 Services."
Note: If additional services are enabled, they may in turn have dependencies that
require further services. All of the services needed for a specific server role should be
added in the policy for the server role that it performs in your organization.
165
The table below illustrates which services are configured to start automatically in the
MSBP.
Table 6.3: MSBP Services Enabled
Full Service Name as It Appears
in the UI
Service Name
Default Setting
Startup Type
Automatic Updates
WUAUServ
Automatic
Automatic
Computer Browser
Browser
Automatic
Automatic
DHCP Client
DHCP
Automatic
Automatic
Distributed Link Tracking Client
TrkWks
Automatic
Automatic
DNS Client
DNSCache
Automatic
Automatic
Event Log
EventLog
Automatic
Automatic
IPSEC Policy Agent(IPSEC Service)
PolicyAgent
Automatic
Automatic
Logical Disk Manager
Dmserver
Automatic
Automatic
Netlogon
Netlogon
Automatic
Automatic
NTLM Security Support Provider
NtLmSsps
Manual
Automatic
Plug and Play
PlugPlay
Automatic
Automatic
Protected Storage
ProtectedStorage
Automatic
Automatic
Remote Procedure Call (RPC)
RpcSs
Automatic
Automatic
Remote Registry Service
RemoteRegistry
Automatic
Automatic
Security Accounts Manager
SaContoso
Automatic
Automatic
Server
Lanmanserver
Automatic
Automatic
SNMP Service
SNMP
Not Installed
Automatic
System Event Notification
SENS
Automatic
Automatic
TCP/IP NetBIOS Helper Service
LmHosts
Automatic
Automatic
Terminal Services
TermService
Disabled
Automatic
Windows Installer
MSIServer
Manual
Automatic
Windows Management
Instrumentation
WinMgmt
Manual
Automatic
Windows Time
W32Time
Automatic (see
note below)
Automatic
Workstation
LanmanWorkstati
on
Automatic
Automatic
Note: Default settings are automatic for a server in the domain and manual if the
server belongs to a workgroup.
166
The table below illustrates which services are disabled in the MSBP.
Table 6.4: MSBP Services Disabled
Full Service Name as It Appears
in the UI
Service Name
Default Setting
Startup Type
Alerter
Alerter
Automatic
Disabled
Application Management
AppMgmt
Manual
Disabled
ClipBook
ClipSrv
Manual
Disabled
Distributed Transaction Coordinator
MSDTC
Automatic
Disabled
Fax Service
Fax
Manual
Disabled
Indexing Service
Cisvc
Manual
Disabled
Internet Connection Sharing
SharedAccess
Manual
Disabled
License Logging Service
LicenseService
Automatic
Disabled
Messenger
Messenger
Automatic
Disabled
NetMeeting Remote Desktop Sharing
Mnmsrvc
Manual
Disabled
Network DDE
NetDDE
Manual
Disabled
Network DDE DSDM
NetDDEdsdm
Manual
Disabled
QoS Admission Control (RSVP)
RSVP
Manual
Disabled
Remote Access Auto Connection
Manager
RasAuto
Manual
Disabled
Remote Access Connection Manager
RasMan
Manual
Disabled
Removable Storage
NtmsSvc
Automatic
Disabled
Routing and Remote Access
RemoteAccess
Disabled
Disabled
RunAs Service
Seclogon
Automatic
Disabled
Smart Card
ScardSvr
Manual
Disabled
Smart Card Helper
ScardDrv
Manual
Disabled
Task Scheduler
Schedule
Automatic
Disabled
Telephony
TapiSrv
Manual
Disabled
Telnet
TlntSvr
Manual
Disabled
Uninterruptible Power Supply
UPS
Manual
Disabled
Utility Manager
UtilMan
Manual
Disabled
The table below illustrates which services that are not installed by default are disabled in
the MSBP.
167
Table 6.5: MSBP Non-Default Services Disabled
168
Full Service Name as It Appears
in the UI
Service Name
Default Setting
Startup Type
Boot Information Negotiation Layer
BINLSVC
Not installed
Disabled
Certificate Services
CertSvc
Not installed
Disabled
Cluster Service
ClusSvc
Not installed
Disabled
File Server for Macintosh
MacFile
Not installed
Disabled
FTP Publishing Service
MSFTPSVC
Not installed
Disabled
Gateway Service for Netware (see
note below)
NWCWorkstation
Not installed
Disabled
Internet Authentication Service
IAS
Not installed
Disabled
Message Queuing
MSMQ
Not installed
Disabled
Network News Transfer Protocol
(NNTP)
NntpSvc
Not installed
Disabled
On-Line Presentation Broadcast
NSLService
Not installed
Disabled
Print Server for Macintosh
MacPrint
Not installed
Disabled
QoS RSVP
RSVP
Not installed
Disabled
Remote Storage Engine
Remote_Storage
_Engine
Not installed
Disabled
Remote Storage File
Remote_Storage
_File_System_A
gent
Not installed
Disabled
Remote Storage Media
Remote_Storage
_Subsystem
Not installed
Disabled
Remote Storage Notification
Remote_Storage
_User_Link
Not installed
Disabled
SAP Agent
NwSapAgent
Not installed
Disabled
Simple TCP/IP Services
SimpTcp
Not installed
Disabled
Single Instance Storage Groveler
Groveler
Not installed
Disabled
Site Server ILS Service
LDAPSVCX
Not installed
Disabled
Simple Mail Transport Protocol
(SMTP)
SMTPSVC
Automatic
Disabled
SNMP Trap Service
SNMPTRAP
Not installed
Disabled
TCP/IP Print Server
LPDSVC
Not installed
Disabled
Terminal Services Licensing
TermServ
Licensing
Not installed
Disabled
Trivial FTP Daemon
TFTPD
Not installed
Disabled
Windows Media Monitor Service
nsmonitor
Not installed
Disabled
Windows Media Program Service
nsprogram
Not installed
Disabled
Windows Media Station Service
nsstation
Not installed
Disabled
Windows Media Unicast Service
nsunicast
Not installed
Disabled
Note: NetWare is a Novell network management product that offers access to core
network resources including files, printers, directories, e – mail, and databases across
all types of networks, storage platforms, and client desktops.
The table below illustrates which services are configured to start manually in the MSBP.
Table 6.6: MSBP Services Configured to Start Manually
Full Service Name as It Appears
in the UI
Service Name
Default Setting
Startup Type
Background Intelligent Transfer
Service
BITS
Manual
Manual
COM+ Event Services
EventSystem
Manual
Manual
Logical Disk Manager Administrative
Service
Dmadmin
Manual
Manual
Network Connections
Netman
Manual
Manual
Performance Logs and Alerts
SysmonLog
Manual
Manual
Windows Management
Instrumentation Driver Extensions
WMI
Manual
Manual
The table below illustrates which services are configured to start automatically for specific
server roles in the Contoso scenario. For the other server roles these services are
disabled by setting their startup mode to Disabled in the MSBP. These services and why
they are required for specific server roles are discussed in Chapter 7, "Hardening Specific
Server Roles."
169
Table 6.7: MSBP Services Enabled for Specific Server Roles
Full Service Name as It Appears
in the UI
Service Name
Default Setting
Startup Type
DHCP Server
DHCPServer
Not installed
Enabled only
in the
Infrastructure
role.
Distributed File System
Dfs
Automatic
Enabled only
in the domain
controller role.
Distributed Link Tracking Server
TrkSrv
Automatic
Enabled only
in the Domain
Controller role.
DNS Server
DNS
Not Installed
Enabled only
in the Domain
Controller role.
File Replication
NtFrs
Manual
Enabled only
in the Domain
Controller role.
IIS Admin Service
IISADMIN
Automatic
Enabled in the
IIS role.
Intersite Messaging
IsmServ
Disabled
Enabled in the
Domain
Controller role.
Kerberos Key Distribution Center
Kdc
Disabled
Enabled only
in the Domain
Controller role.
Print Spooler
Spooler
Automatic
Enabled only
in the File and
Print role.
Remote Procedure Call (RPC)
Locator
Rpclocator
Manual
Enabled only
in the Domain
Controller role.
Windows Internet Name Service
(WINS)
WINS
Not installed
Enabled only
in the
Infrastructure
role.
World Wide Web Publishing Service
W3svc
Automatic
Enabled only
in the IIS role.
The following Windows 2000 Server services discussed in the tables above merit
additional attention.
170
Computer Browser
Vulnerability
The Computer Browser service maintains the list of computers on the network and
supplies the list to programs that request it. The Computer Browser service is used by
Windows – based computers that need to view network domains and resources.
Countermeasure
Enable the Computer Browser service by setting its startup mode to Automatic. The
possible values for this Group Policy setting are:
●
Automatic.
●
Manual.
●
Disabled.
●
Not defined.
Potential Impact
Computers that connect to the same physical network segment as the Contoso servers
will be able to remotely access the Computer Browser service to see the browse list of
domains and resources.
Contoso Scenario
The network in the Contoso scenario utilizes the Computer Browser service to enumerate
services within the forest. Therefore, Group Policy is used to set the Computer Browser
service startup mode to Automatic.
NTLM Security Support Provider
Vulnerability
The NTLM Security Support Provider service provides security to RPC programs that use
transports other than named pipes and enables users to log on using the NTLM
authentication protocol.
Countermeasure
Enable the NTLM Security Support Provider service by setting its startup mode to
Automatic. The possible values for this Group Policy setting are:
●
Automatic.
●
Manual.
●
Disabled.
●
Not defined.
Potential Impact
This service is included with Windows 2000 Server purely for backwards compatibility
with applications that specifically look for this service to be running. This functionality is
now included in the core operating system.
Contoso Scenario
The servers in the Contoso scenario run a third-party agent that requires this service;
therefore Group Policy was used to set the NTLM Security Support Provider service
startup mode to Automatic.
171
SNMP Service
Vulnerability
In many cases, management applications require an agent to be installed on each server.
Typically, these agents will use Simple Network Management Protocol (SNMP) to
forward alerts back to a centralized management server.
Countermeasure
Enable the SNMP Service by setting its startup mode to Automatic. The possible values
for this Group Policy setting are:
●
Automatic.
●
Manual.
●
Disabled.
●
Not defined.
Potential Impact
Enabling SNMP Service creates a risk of it own because the default community string for
read access used for Microsoft products is the word Public. By default write access
through SNMP is disabled in Windows 2000. SNMP can provide not only the functionality
to read values from a server but modify information as well. The community string is
similar to a password and should be treated with the same level of security. This risk is
mitigated by manually changing the community string as described later in this chapter.
Another risk created by enabling the SNMP Service is that traffic is all sent in cleartext.
An attacker who is able to sniff traffic on the network in the Contoso scenario would be
able to view the SNMP packets.
Contoso Scenario
The MOM agents installed on the servers in the Contoso scenario are dependent on this
service. Therefore, Group Policy was used to set the SNMP Service startup mode to
Automatic.
Terminal Services
Vulnerability
Remote administration of servers saves time and money. Support staff can connect to
servers and perform administrative tasks without having to physically walk up to the
console of the server to manage it. This is particularly important in large, distributed
networks.
Countermeasure
Enable Terminal Services by setting its startup mode to Automatic. The possible values
for this Group Policy setting are:
172
●
Automatic.
●
Manual.
●
Disabled.
●
Not defined.
Potential Impact
An attacker who is able to connect to Transmission Control Protocol (TCP) port 3389 will
be able to establish a Remote Desktop Protocol (RDP) connection. The attacker would
still need to know the user name and password of an account that has sufficient
privileges to log on to the server. Due to other security settings implemented in the
Contoso servers, in the Contoso scenario it would be extremely difficult and time
consuming for the attacker to use a brute force attack via a RDP connection and
Terminal Services.
Contoso Scenario
For the reasons outlined above, servers in the Contoso scenario have the Terminal
Services service installed and enabled. Group Policy was used to set the Terminal
Services startup mode to Automatic.
Windows Management Instrumentation
Vulnerability
The Windows Management Instrumentation (WMI) service is needed for managing
logical disks that use computer management. The service also facilitates performance
alerts. Many other applications and tools also use WMI.
Countermeasure
Enable the Windows Management Instrumentation service by setting its startup mode
to Automatic. The possible values for this Group Policy setting are:
●
Automatic.
●
Manual.
●
Disabled.
●
Not defined.
Potential Impact
If the WIM interfaces are be enabled, an attacker who gains access to a system may be
able to take advantage of them to gather more information about the hardware and
software installed on the server.
Contoso Scenario
Servers in the Contoso scenario need to be managed via WMI. Therefore Group Policy
was used to set the Windows Management Instrumentation service startup mode to
Automatic.
Messenger Service and Alert Service
Vulnerability
Although not explicitly dependent on one another, these services work together to send
administrative alerts. The Messenger Service sends alerts triggered by the Alert service.
If you are using performance logs and alerts to trigger alerts, you will need to enable
these services on the servers in your organization.
173
Countermeasure
Disable the Messenger Service and Alert Service by setting startup mode for these
services to Disabled. The possible values for this Group Policy setting are:
●
Automatic.
●
Manual.
●
Disabled.
●
Not defined.
Potential Impact
Automatic administrative alerts will not be sent, and messenger notifications can not be
sent to or received by the computer or by users currently logged on to it. For example,
the NET SEND and NET NAME commands will no longer function.
Contoso Scenario
These services are not required in the Contoso scenario. Therefore, Group Policy was
used to set the Messenger Service and Alert Service startup mode for these services
to Disabled.
Additional Registry Settings
For the servers in the Contoso scenario, additional registry value entries are added to the
baseline security template file that are not defined within the Administrative Template
(.adm) file. The .adm file defines the system policies and restrictions for the desktop,
shell, and security for Windows 2000 Server.
This means that when you load the Microsoft Management Console (MMC) Security
Templates snap – in and view the baseline.inf template, the registry values in the following
tables are not represented. Instead, these settings have been added to the .inf file using
the text editor called Notepad included with Windows and will be applied to the server
when the policy is downloaded.
These settings are embedded within the baseline.inf security template to automate the
changes. If the policy is removed, these settings are not automatically removed with it
and must be manually changed using a registry editing tool such as Regedt32.exe.
Security Considerations for Network Attacks
Vulnerability
DoS attacks directed at the Transmission Control Protocol/Internet Protocol (TCP/IP)
stack tend to be of two classes: attacks that use an excessive number of system
resources, for example, by opening numerous TCP connections; or attacks that send
specially crafted packets that cause the network stack or the entire operating system to
fail. These registry settings help to protect against the attacks directed at the TCP/IP
stack.
Countermeasure
Set values as indicated in Tables 6.8 and 6.9 below in the Group Policy linked to the
parent OU for servers. DoS attacks include those that flood a Web server with
communication to keep it busy, and others that flood a remote network with an enormous
amount of protocol packets. Routers and servers become overloaded by attempting to
route or handle each packet.
174
DoS attacks can be difficult to defend against. To help prevent them, the TCP/IP protocol
stack is hardened. This registry value was added to the baseline security template file,
but it is not defined within the Administrative Template (.adm) file. This means that when
you load the MMC Security Templates snap – in and view the baseline.inf template, the
registry is not visible. Instead, these settings can be added to the .inf file using a text
editor. The settings will then be applied to the server when the policy is downloaded.
Potential Impact
The potential impacts of this countermeasure are detailed below in Table 6.10.
Contoso Scenario
In the Contoso scenario, Group Policy was used to set these registry settings to increase
the resistance of the Windows 2000 TCP/IP stack to standard types of DoS network
attacks.
The following registry value entries have been added to the template file in the
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\ registry key:
Table 6.8: MSBP TCP/IP Parameters Added to Registry
Registry Value Entry
Format
Value (Decimal)
EnableICMPRedirect
DWORD
0
SynAttackProtect
DWORD
2
EnableDeadGWDetect
DWORD
0
EnablePMTUDiscovery
DWORD
0
KeepAliveTime
DWORD
300,000
DisableIPSourceRouting
DWORD
2
TcpMaxConnectResponseRetransmissions
DWORD
2
TcpMaxDataRetransmissions
DWORD
3
PerformRouterDiscovery
DWORD
0
TCPMaxPortsExhausted
DWORD
5
Windows Sockets applications such as File Transfer Protocol (FTP) servers and Web
servers have their connection attempts handled by Afd.sys. Afd.sys has been modified to
support large numbers of connections in the half-open state without denying access to
legitimate clients.
This is accomplished by allowing the administrator to configure a dynamic backlog. The
new version of Afd.sys supports four new registry parameters that can be used to control
the dynamic backlog behavior.
The following registry value entries have been added to the template file in the
HKLM\System\CurrentControlSet\Services\AFD\Parameters\ registry key:
Table 6.9: MSBP Afd.sys Settings Added to Registry
Registry Value Entry
Format
Value (Decimal)
DynamicBacklogGrowthDelta
DWORD
10
EnableDynamicBacklog
DWORD
1
MinimumDynamicBacklog
DWORD
20
MaximumDynamicBacklog
DWORD
20000
175
Potential Impact
Table 6.10: Impact of Countermeasures and Potential Exploits
176
Registry Value Entry
Countermeasure Potential Impact
Potential Exploit
EnableICMPRedirect
When Routing and Remote Access
Services (RRAS) is configured as an
autonomous system boundary router
(ASBR), it does not correctly import
connected interface subnet routes.
Instead, this router injects host routes
into the Open Shortest Path First
(OSPF) routes. Because the OSPF
router can not be used as an ASBR
router, importing connected interface
subnet routes into OSPF results in
confusing routing tables with strange
routing paths.
Internet Control Message
Protocol (ICMP) redirects
cause the stack to plumb
host routes. These routes
override the OSPFgenerated routes.
This by itself is the
expected behavior. The
problem is that the 10
minute time-out period for
the ICMP redirect-plumbed
routes creates a black hole
for the network concerned.
SynAttackProtect
This registry value causes TCP to
adjust retransmission of SYN-ACKs.
When you configure this value, the
connection responses time out more
quickly in the event of a SYN attack.
This value adds additional delays to
connection indications, and TCP
connection requests quickly time out
when a SYN attack is in progress.
When you configure this setting, the
scalable windows and TCP parameters
that are configured on each adapter
(including Initial Round Trip Time (RTT)
and window size) socket options no
longer work.
In a SYN flood attack, the
attacker sends a
continuous stream of SYN
packets to a server, and the
server leaves the half-open
connections open until it is
overwhelmed and is no
longer able to respond to
legitimate requests.
EnableDeadGWDetect
When dead-gateway detection is
enabled, TCP may ask the IP to change
to a backup gateway if a number of
connections are experiencing difficulty.
When this setting is configured to 0,
Windows will no longer detect dead
gateways and automatically switch to
an alternate.
An attacker could force the
server to switch gateways,
potentially to an unintended
one.
(continued)
EnablePMTUDiscovery
When you set EnablePMTUDiscovery
to 1, TCP attempts to discover either
the maximum transmission unit (MTU)
or the largest packet size over the path
to a remote host.
TCP can eliminate fragmentation at
routers along the path that connect
networks with different MTUs by
discovering the path MTU and limiting
TCP segments to this size.
Fragmentation adversely affects TCP
throughput. When this value is set to 0,
an MTU of 576 bytes is used for all
connections that are not hosts on the
local subnet.
If you do not set this value
to 0, an attacker could force
the MTU to a very small
value and overwork the
stack by forcing the server
to fragment a large number
of packets.
KeepAliveTime
This value controls how often TCP
attempts to verify that an idle
connection is still intact by sending a
keep-alive packet. If the remote
computer is still reachable, it
acknowledges the keep-alive packet.
Keep-alive packets are not sent by
default. You can use a program to
configure this value on a connection.
Lowering this from the default value of 2
hours to 5 minutes means that inactive
sessions will be disconnected more
quickly.
An attacker who was able
to connect to network
applications could cause a
DoS condition by
establishing numerous
connections.
DisableIPSourceRouting
IP source routing is a mechanism
allowing the sender to determine the IP
route that a datagram should take
through the network. Setting this value
to 2 will cause all incoming source
routed packets to be dropped.
An attacker uses source
routed packets to obscure
their identity and location.
Source routing allows a
computer sending a packet
to specify the route it takes.
177
(continued)
178
TCPMaxConnectRespo
nseRetransmissions
This parameter controls the number of
times that a SYN-ACK is retransmitted
in response to a connection request if
the SYN is not acknowledged.
If this value is greater than or equal to
2, the stack employs SYN-ATTACK
protection internally. If this value is less
than 2, the stack does not read the
registry values at all for SYN-ATTACK
protection. This parameter shortens the
default time that it takes to clean up a
half-open TCP connection.
A site that is under heavy attack might
set the value as low as 1. A value of 0 is
also valid. However, if this parameter is
set to 0, SYN-ACKs will not be
retransmitted at all and will time out in 3
seconds. With the value this low,
legitimate connection attempts from
distant clients may fail.
In a SYN flood attack, the
attacker sends a
continuous stream of SYN
packets to a server, and the
server leaves the half-open
connections open until it is
overwhelmed and no longer
is able to respond to
legitimate requests.
TCPMaxData
Retransmissions
TCP starts a retransmission timer when
each outbound segment is handed
down to the IP. If no acknowledgment
has been received for the data in a
given segment before the timer expires,
then the segment is retransmitted up to
three times.
In a SYN flood attack, the
attacker sends a
continuous stream of SYN
packets to a server, and the
server leaves the half-open
connections open until it is
overwhelmed and no longer
is able to respond to
legitimate requests.
PerformRouterDiscovery
This is set to prevent Windows 2000,
which supports the Internet Router
Discovery Protocol (IRDP), from
automatically detecting and configuring
Default Gateway addresses on the
computer.
An attacker who gained
control of a system on the
same network segment
could configure a computer
on the network to
impersonate a router.
Other computers with IRDP
enabled would then attempt
to route their traffic through
the already compromised
system.
(continued)
TCPMaxPortsExhausted
This parameter controls the point at
which SYN-ATTACK protection starts to
operate. SYN-ATTACK protection
begins to operate when
TCPMaxPortsExhausted connect
requests have been refused by the
system because the available backlog
for connections is set at 0.
This should have little impact on the
server or systems attempting to use it in
a legitimate manner.
In a SYN flood attack, the
attacker sends a
continuous stream of SYN
packets to a server, and the
server leaves the half-open
connections open until it is
overwhelmed and no longer
is able to respond to
legitimate requests.
AFD settings:
Windows Sockets applications such as
FTP servers and Web servers have
their connection attempts handled by
Afd.sys. Afd.sys has been modified to
support large numbers of connections in
the half-open state without denying
access to legitimate clients.
This is accomplished by allowing the
administrator to configure a dynamic
backlog.
DynamicBacklogGrowthDelta controls
the number of free connections to
create when additional connections are
necessary. Be careful with this value, as
a large value could lead to explosive
free connection allocations.
In a SYN flood attack, the
attacker sends a
continuous stream of SYN
packets to a server, and the
server leaves the half-open
connections open until it is
overwhelmed and no longer
is able to respond to
legitimate requests.
DynamicBacklogGrowth
Delta
EnableDynamicBacklog
MinimumDynamic
Backlog
MaximumDynamic
Backlog
Configure NetBIOS Name Release Security
Network basic input/output system (NetBIOS) over TCP/IP is a networking protocol that
among other things provides a means of easily resolving NetBIOS names registered on
Windows – based systems to the IP addresses configured on those systems.
Vulnerability
The NetBIOS over TCP/IP (NetBT) protocol is designed not to use authentication, and is
therefore vulnerable to spoofing. A malicious user could exploit the unauthenticated
nature of the protocol to send a name-conflict datagram to a target computer, causing it
to relinquish its name and stop responding to queries.
The result of such an attack could be to cause intermittent connectivity issues on the
target system, or even to prevent the use of Network Neighborhood, domain logons, the
net send command, or further NetBIOS name resolution.
For more details, see Knowledge Base article Q269239, "MS00-047: NetBIOS
Vulnerability May Cause Duplicate Name on the Network Conflicts."
179
Countermeasure
Test and deploy the registry changes recommended in Knowledge Base article Q269239.
Applying the registry value NoNameReleaseOnDemand and setting it to 1 ensures that
the servers will no longer comply with name release requests from computers other than
the WINS servers configured on in the network settings of the server.
Alternatively, you could disable the use of Windows Internet Name Service (WINS) in
your environment, and further ensure that all applications rely upon DNS for name
resolution services. While this is a recommended long – term strategy, it is generally
impractical for most organizations to attempt this as a short-term solution. Organizations
still running WINS generally have application dependencies that can not be quickly
resolved without upgrades and software rollouts, which require careful planning and
significant time commitments.
If you can not deploy this countermeasure, and you want to guarantee NetBIOS name
resolution, then take the additional step of "pre-loading" NetBIOS names in the
LMHOSTS file on certain computers. Knowledge Base article Q269239 details the
procedure for pre-loading the LMHOSTS file.
Note: There is a high maintenance factor required to update the LMHOSTS files in
most environments. Microsoft encourages the use of WINS over LMHOSTS.
Potential Impact
An attacker could send a request over the network asking a computer to release its
NetBIOS name. As with any changes that could affect applications, Microsoft
recommends testing this change in a non – production environment before making the
change in production.
Contoso Scenario
In the Contoso scenario, NetBIOS naming services are still required to be supported.
This hotfix is deployed to all servers, and the registry is updated via the Incremental
Infrastructure server policy.
The following registry value entry was added to the template file to the
HKLM\System\CurrentControlSet\Services\Netbt\Parameters\ registry key:
Table 6.11: MSBP Setting Added to Registry to Configure the NetBIOS Name
Release protection
Registry Key
Format
NoNameReleaseOnDemand
DWORD
Value (Decimal)
1
Disable Auto Generation of 8.3 Filenames
Vulnerability
Windows 2000 supports 8.3 file name formats for backward compatibility with16-bit
applications. The 8.3 file name convention is a naming format that allows file names up to
eight characters long.
This means that an attacker only needs eight characters to refer to a file that may be 20
characters long. For example, a file named Thisisalongfilename.doc, could be referenced
by its 8.3 filename Thisis~1.doc. If you avoid using 16-bit applications, you can turn this
feature off. Disabling short name generation on an NTFS partition also increases
directory enumeration performance.
180
Attackers could use short file names to access data files and applications with long file
names that would normally be difficult to locate. An attacker who has gained access to
the file system could access data or execute applications.
Countermeasure
Set NtfsDisable8dot3NameCreation to the value 1 in the Group Policy linked to the
parent OU for servers. This registry value was added to the baseline security template
file, but it is not defined within the .adm file. This means that when you load the MMC
Security Templates snap – in and view the baseline.inf template, the registry is not visible.
Instead, these settings can be added to the .inf file using a text editor. The settings will
then be applied to the server when the policy is downloaded.
Potential Impact
The 16 – bit applications in your organization will not be able to access files with names
longer than the 8.3 format allows.
Contoso Scenario
In the Contoso scenario, Group Policy is used to set NtfsDisable8dot3NameCreation to
the value 1.
The following registry value entry has been added to the template in the
HKLM\System\CurrentControlSet\Control\FileSystem\ registry key:
Table 6.12: MSBP Setting to Remove 8.3 Filename Creation Added to Registry
Registry Value Entry
Format
NtfsDisable8dot3NameCreation
DWORD
Value (Decimal)
1
Note: If you apply this setting to an existing server that already has files with auto
generated 8.3 file names, it does not remove them. To remove existing 8.3 file names,
you will need to copy those files off the server, delete the files from the original
location, and then copy the files back to their original locations.
Disable Autorun
Vulnerability
Autorun begins reading from a drive on your computer as soon as media is inserted in it.
As a result, the setup file of programs and the sound on audio media starts immediately.
To prevent a possible malicious program from starting when media is inserted, the Group
Policy disables Autorun on all drives.
An attacker with physical access to the system could insert an Autorun enabled DVD or
CD into the computer that will then automatically launch malicious code. This malicious
program could contain whatever code the attacker wishes.
Countermeasure
Set NoDriveTypeAutoRun to the hexadecimal value 0xFF in the Group Policy linked to
the parent OU for servers. This registry value was added to the baseline security
template file, but it is not defined within the .adm file. This means that when you load the
MMC Security Templates snap – in and view the baseline.inf template, the registry is not
visible. Instead, these settings can be added to the .inf file using a text editor, and they
will then be applied to the server when the policy is downloaded.
181
Potential Impact
Autorun will no longer work when Autorun enabled discs are inserted into the computer.
Contoso Scenario
In the Contoso scenario, Group Policy was used to add the following registry value entry
to the template in the
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\ key:
Table 6.13: MSBP Setting to Disable Autorun on All Drives Added to Registry
Registry Value Entry
Format
NoDriveTypeAutoRun
DWORD
Value (Hex)
0xFF
Removing OS/2 and POSIX Subsystems
Vulnerability
The OS/2 Subsystem is required if the server needs to significantly interact with OS/2
Clients. OS/2 is a family of Microsoft protected – mode, virtual – memory, multitasking
operating systems for personal computers based on the Intel 80286 and 80386
processors. The Portable Operating System Interface for UNIX (POSIX) is an Institute of
Electrical and Electronic Engineers (IEEE) standard that defines a set of operating
system services.
The subsystem introduces a security risk relating to processes that can potentially persist
across logins. That is, if a user starts a process and then logs out, there is a potential that
the process will be accessed by the next user who logs in to the system. The process
started by the first user may retain the user's system privileges.
Countermeasure
In order to disable the OS/2 Subsystem, the Optional, OS/2, and POSIX registry keys
were deleted in the Group Policy linked to the parent OU for servers. The commands to
delete these registry subkeys were added to the baseline security template file, but they
are not defined within the .adm file.
This means that when you load the MMC Security Templates snap – in and view the
baseline.inf template, the registry change is not visible. Instead, these settings can be
added to the .inf file using a text editor. The settings will then be applied to the server
when the policy is downloaded.
Potential Impact
Applications that rely on the OS/2 or POSIX subsystems will no longer operate. For
example, Microsoft Services for Unix (SFU) 3.0 installs an updated version of the POSIX
subsystem that requires both the Optional and POSIX subkeys, so you would need to
remove the lines that remove these subkeys from the security template for any servers
that use SFU 3.0.
Contoso Scenario
In the Contoso scenario, Group Policy is used to delete the following subkeys of the
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems registry
key by adding entries to the security template:
182
●
Optional
●
OS/2
●
POSIX
Make Screensaver Password Protection Immediate
Vulnerability
The default grace period allowed for user movement before the screen saver lock takes
effect is five seconds. Leaving the grace period in the default setting makes your
computer vulnerable to a potential attack from someone walking up to the console to
attempt to log in to the system before the lock takes effect. An entry to the registry can be
made to adjust the length of the delay.
Countermeasure
To make password protection effective immediately, set ScreenSaverGracePeriod to
the value 0. The value is the time in seconds before the screen saver grace period
expires.
Potential Impact
Users will have to enter their passwords to resume their console sessions as soon as the
screen saver activates.
Contoso Scenario
In the Contoso scenario, the following registry value entry was added to the template in
the HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\ScreenSaverGracePeriod\ key:
Table 6.14: MSBP Setting to Make Screensaver Password Protection Immediate
Added to Registry
Registry Value Entry
Format
ScreenSaverGracePeriod
String
Value (Decimal)
0
Restrict Null Session Access
Vulnerability
Null sessions are a weakness that can be exploited through the various shares that are
on the computers in your environment.
Countermeasure
Modify null session access to shares on your computers by adding
RestrictNullSessAccess with the value 1, a registry value that toggles null session
shares on or off to determine whether the Server service restricts access to clients
logged on to the system account without user name and password authentication.
Potential Impact
Setting the value to 1 restricts null session access to unauthenticated users to all server
pipes and shares except those listed in the NullSessionPipes and NullSessionShares
entries.
Contoso Scenario
In the Contoso scenario, Group Policy was used to add the following registry key to the
template in the
HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\ key:
183
Table 6.16: MSBP Setting to Restrict Null Session Access Added to Registry
Registry Value Entry
Format
Value (Decimal)
RestrictNullSessAccess
DWORD
1
Restrict Null Session Access over Named Pipes
Vulnerability
Restricting access over named pipes helps prevent unauthorized access to the network.
Countermeasure
Delete the registry subkeys NullSessionPipes and NullSessionShares located at
HKLM\SYSTEM\CurrentControlSet\ Services\lanmanserver\parameters.
Potential Impact
Null session access over named pipes will be disabled; applications that rely on this
feature will no longer function. Null session access to shares will be disabled, and
applications that rely on unauthenticated access to network shares will not work. For
example, with Microsoft® Commercial Internet System 1.0, the Internet Mail Service runs
under the Inetinfo process. Inetinfo starts in the context of the system account. When
Internet Mail Service needs to query the Microsoft® SQL Server™ database, it uses the
system account, which uses null credentials to access a SQL pipe on the computer
running SQL Server computer.
There are two ways that you could resolve this problem: configure the World Wide Web
Publishing Service to run with an account other than System that can connect to the SQL
Server database, or enable null session pipes. You can refer to Microsoft Knowledge
Base article 207671: "HOW TO: Access Network Files from IIS Applications" located at:
http://support.microsoft.com/default.aspx?scid=KB;en-us;207671 for more information.
Contoso Scenario
In the Contoso scenario, Group Policy was used to delete the following subkeys of the
HKLM\SYSTEM\CurrentControlSet\ Services\lanmanserver\parameters registry key
by adding entries to the security template:
●
NullSessionPipes
●
NullSessionShares
Security Log Approaching Capacity Warning
Vulnerability
SP3 for Windows 2000 includes a new feature for generating a security audit in the
security event log when the security log reaches a user – defined threshold. When the
security log reaches 90 percent of capacity, it will show one event entry for eventID 523
with the following text: “The security event log is 90 percent full.”
Countermeasure
To enable this feature, add a new registry DWORD value called WarningLevel and set
the value for it to 90 in the following key:
HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Security.
184
Potential Impact
This setting will generate an audit event when the audit log reaches the 90 percent full
threshold.
Contoso Scenario
In the Contoso scenario, Group Policy was used to add the following registry value entry
to the template in the HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Security\
key:
Table 6.17: MSBP Setting to Enable Security Log Approaching Capacity Warning
Added to Registry
Registry Value Entry
Format
Value (Decimal)
WarningLevel
DWORD
90
Requiring Domain Controller Authentication to Unlock the Console
Vulnerability
The computer caches in memory the credentials in memory of any users that have been
authenticated locally. To unlock the console, the computer uses the cached credentials,
from memory, to authenticate anyone who attempts to unlock the console.
When cached credentials are used, any changes that have recently been made to the
account, such as user rights assignments, account lockout, or the account being
disabled, are not considered or applied after this authentication process. This means that
user privileges are not updated, but more importantly that disabled accounts are still able
to unlock the console of the system.
Countermeasure
To ensure that any changes to the account are enforced immediately, require the
computer to authenticate the account each time that an attempt is made to unlock the
console, rather than allowing the system to rely on using cached credentials to do this.
To enable this feature, add a new registry DWORD value called ForceUnlockLogon and
set the value for it to 1 in the following key: HKLM\Software\Microsoft\
Windows NT\CurrentVersion\Winlogon\.
Potential Impact
When the console on a domain controller is locked, either by a user or automatically by a
screen saver time-out, the console must be unlocked to gain access to the computer.
Contoso Scenario
In the Contoso scenario, Group Policy is used to add the following registry value entry to
the template in the HKLM\Software\Microsoft\
Windows NT\CurrentVersion\Winlogon\ key:
Table 6.18: MSBP Setting to Require Domain Controller Authentication to Unlock
Console Added to Registry
Registry Value Entry
Format
Value (Decimal)
ForceUnlockLogon
DWORD
1
185
Additional Member Server Hardening Procedures
Although most of the countermeasures used to harden the Contoso servers were applied
through group policy there are additional settings that are difficult or impossible to apply
with group policy. This section describes how some of these additional countermeasures
were implemented manually, such as securing accounts; and how others were put in
place using shell scripts, such as the IPSec filters.
Manual Hardening Procedures
The following subsections illustrate the manual procedures used to apply
countermeasures to the Contoso servers.
Securing the Accounts
Vulnerability
Windows 2000 has a number of built – in user accounts that can not be deleted but can
be renamed. Two of the most well known built – in accounts in Windows 2000 are Guest
and Administrator.
By default, the Guest account is disabled on member servers and domain controllers.
This setting should not be changed. The built – in Administrator account should be
renamed and the description altered to prevent attackers from compromising a remote
server using a well known name.
Many variations of malicious code use the built – in administrator account in an initial
attempt to compromise a server. The value of this configuration change has diminished
over the past few years since the release of attack tools that attempt to break into the
server by specifying the security identifier (SID) of the built – in Administrator account. A
SID is the value that uniquely identifies each user, group, computer account, and logon
session on a network. It is not possible to change the SID of this built – in account.
Note: The built – in administrator account can be renamed using Group Policy. We
have not implemented this setting in the baseline policies because you should choose
a name which is not well known. We were concerned that some organizations that
deploy our security templates would not change the setting and that they would have
the same name for their renamed administrator accounts as in the Contoso scenario.
We encourage you to use the Group Policy setting called Rename administrator
account located in Computer Configuration\Windows Settings\Security Settings\
Event Log\ in your environment.
Countermeasure
Manually rename the administrator account and change the password to a long and
complex value on every server. Also, use different names and passwords on each server.
Record these changes in a secure place. If the same account names and passwords are
used on all of the servers, an attacker who gains access to one member server will be
able to gain access to all others with the same account name and password.
Potential Impact
The users responsible for managing the servers will have to keep track of which account
name is used for each server. If it is necessary to log in to a particular server with the
local administrator account, then the user will have to refer to this secured documentation
to find out what the user name and password for it is.
186
Contoso Scenario
In the Contoso scenario, the Computer Management console was used to change the
local administrator account and password on each member server.
Securing Service Accounts
Windows 2000 services typically run under the Local System account, but they can also
be run under a domain user or local account. Use local accounts whenever possible over
domain user accounts.
A service runs under the security context of its service account, so if an attacker
compromises a service on a member server, the service account can potentially be used
to attack a domain controller. When determining which account to use as a service
account, ensure that the assigned privileges are limited to what is required for the
successful operation of the service. The table below explains the privileges inherent to
each type of service account.
Table 6.19: Windows 2000 Account Privileges in Different Environments
Authentication Service on
Windows 2000 Servers
Intraforest Only on
Windows 2000 Servers
Multiforest with NTLM
Trusts Between
Domains
Local user service account
No network resources, local
access only under account's
assigned privileges.
No network resources, local
access only under account's
assigned privileges.
Domain user service account
Network access as domain
user, local access under user's
privileges.
Network access as domain
user, local access under
user's privileges.
LocalSystem
Network access as computer
account authenticated user,
local access under
LocalSystem.
No network resources
spanning forests, local
access under LocalSystem.
Important: All Windows 2000 default services run under LocalSystem, a setting that
should not be changed. Any additional services added to the system requiring the use
of domain accounts should be evaluated carefully before they are deployed.
Disable LM Hash Creation
Vulnerability
Windows 2000 – based servers can authenticate computers running all previous versions
of Windows. However, previous versions of Windows do not use the Kerberos protocol
for authentication, so Windows 2000 supports LAN Manager (LM), Windows NT (NTLM,)
and NTLM version 2 (NTLMv2).The LM hash is relatively weak compared to the NTLM
hash and therefore prone to rapid brute force attack.
Tools such as L0phtcrack have been available for several years that can determine a
password based on its LM hash using dictionary and brute force attacks. If you do not
have clients that require LM authentication, you should disable the storage of LM hashes.
187
Countermeasure
To disable the creation of the LM hash, you must manually add a NoLMHash key to the
following registry key: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\
Note: If you want to disable the creation of the LM hash, this key must be manually
added to the registry. There is no way to use Group Policy to add a key to the registry;
only values can be added.
Adding this key will disable the creation of the LM hash for newly stored passwords. Any
existing hashes stored in the SAM database or NTDS.dit file will not be removed.
Because of this, you should force all users to change their password after this setting is
applied.
Potential Impact
Local administrator accounts and clients running legacy operating systems or
applications that require LM hashes for authentication will not be able to connect to
servers in your organization.
Contoso Scenario
In the Contoso scenario, we disabled the creation of the LM hash, by manually adding a
NoLMHash key to the following registry key:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\
Note: To disable the storage of LM hashes with this registry setting you must be
running Windows 2000 SP2 or later.
NTFS
Vulnerability
NTFS partitions support ACLs at the file and folder levels. This support is not available
with the file allocation table (FAT), FAT32, or FAT32x file systems. FAT32 is a version of
the FAT file system that has been updated to permit significantly smaller default cluster
sizes and support hard disks up to two terabytes in size. FAT32 is included in Windows
95 OSR2, Windows 98, Microsoft® Windows® Me, Windows 2000, and Windows XP.
Countermeasure
Format all partitions on every server using NTFS. Use the convert utility to non –
destructively convert FAT partitions to NTFS, but keep in mind that the convert utility will
set the ACLs for the converted drive to Everyone: Full Control.
For Windows 2000 Server-based systems, apply the following security templates locally
to configure the default file system ACLs for workstations, servers, and domain
controllers, respectively:
●
%windir%\inf\defltwk.inf
●
%windir%\inf\defltsv.inf
●
%windir%\inf\defltdc.inf
Note: The default domain controller security settings are applied during the promotion
of a server to a domain controller.
188
Potential Impact
No negative impact.
Contoso Scenario
All partitions on the Contoso servers were formatted with NTFS partitions.
Data and Application Segmentation
Vulnerability
There are two classes of vulnerabilities exposed by locating applications, data, and log
files on the same storage volume as the operating system. One potential threat is a user
or users accidentally or deliberately filling the storage volume with data by causing an
application log file to fill up the drive or by uploading files to the server.
The second potential threat is through directory traversal exploits in which an attacker
takes advantage of a bug in a network service to navigate up the directory tree to the root
of the system volume. The attacker may then back down through the operating system
file folders to remotely execute a utility.
There are thousands of variations on directory traversal attacks that exploit scores of
vulnerable applications and operating systems. IIS has been vulnerable to several over
the past few years. For example, the NIMDA and Code Red worms used a buffer
overflow exploit to traverse Web site directory trees and then remotely execute cmd.exe
to gain access to a remote shell and execute additional commands.
Therefore, whenever possible it is necessary to locate Web content, applications, user
data, application logs, and any other files not required by the operating system on the
system volume in a separate storage partition.
Countermeasure
Relocate Web content, applications, data, and application log files to a partition separate
from the system volume.
Potential Impact
No significant negative impact.
Contoso Scenario
The details of how these issues are addressed in the Contoso scenario are discussed in
Chapter 7, "Hardening Specific Server Roles."
Configure SNMP Community Name
Vulnerability
The SNMP protocol is inherently weak when it comes to security. The single biggest
vulnerability with SNMP is that nearly all vendors set a default community string name.
These default community names are well known; for example, Microsoft uses the word
Public.
A second vulnerability is more difficult to overcome: Because SNMP traffic is all sent in
cleartext, when an SNMP management device connects to an SNMP client, the
community string is transmitted across the network without being encrypted or hashed.
This second vulnerability can be addressed by encrypting all traffic between servers.
However, this countermeasure is beyond the scope of this guide.
189
Countermeasure
Configure the SNMP community string for read access on all systems to a random
alphanumeric value. This can be done from the Services console by double-clicking
SNMP Service and then selecting the Security tab from the SNMP Service Properties
dialog box. Select public from the list of Accepted community names, click the Edit
button, and type the new community name in the SNMP Service Community Name
dialog box when it appears. Click the OK button to close each of the dialog boxes. Leave
write access via SNMP disabled.
Note: The community name is stored in the Registry as a registry value with a
DWORD value of 4, so you could automate this change by creating a script or adding a
line to the baseline.inf security template before importing it into the Member Server
Baseline Policy. The value is stored in:
HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities
Potential Impact
The community string on all management tools that utilize the SNMP protocol also must
be reconfigured.
Contoso Scenario
In the Contoso scenario, the SNMP community string is reconfigured to mouse3pad.
Configuring IPSec Policies
Internet Protocol security (IPSec) was initially designed to encrypt data as it travels
between two computers, protecting the data from modification and interpretation if
anyone were to see it on the network. IPSec is a key line of defense against internal,
private network, and external attacks.
Although most network security strategies have focused on preventing attacks from
outside an organization's network, a great deal of sensitive information can be lost by
internal attacks that interpret data on the network. Most data is not protected when it
travels across the network, so employees, supporting staff members, or visitors may be
able to plug into your network and copy data for later analysis.
While IPSec can be used to encrypt data on the network, it can also be used as an
excellent way to secure the network layer of the defense in depth model. This can be
achieved by using IPSec policies to lock down a network interface. Internal attackers can
potentially mount network – level attacks against other computers. Firewalls located
between the internal network and the Internet offer no protection against such internal
threats, so using IPSec to block unnecessary ports offers a significantly greater level of
security for corporate assets.
190
Windows 2000 Server IPSec filtering was not designed to replace a full-featured firewall.
IPSec filtering should be considered as a tool to harden servers. The use of IPSec can
provide defense in depth against attacks that can be blocked with static. In addition,
IPSec filtering can help contain and control malicious code traffic from worms and
viruses. There are a few critical characteristics concerning security about IPSec filtering
that should be understood before using the tool:
1. A security compromise that results in an attacker obtaining either Local
Administrator or Local System access could allow them to disable or change the
IPSec policy.
2. To ensure that the target computer is locked down adequately, the
NoDefaultExempt registry setting must be configured to a value of 1. This setting
is required for all IPSec filtering scenarios used in this security guidance.
Instructions for configuring the NoDefaultExempt setting are described in
Knowledge Base article, IPSec Does Not Secure Kerberos Traffic Between
Domain Controllers, Q254728.
3. IPSec does not provide stateful filtering for outbound connections. Because of this,
static inbound filters have been created as part of this security guidance to ensure
that responses to outgoing communication can be received. This effectively blocks
the majority of attempts by an attacker to scan or connect to open ports on the
servers in your system. However, it is still possible for an attacker to use special
tools to create a connection through the IPSec inbound permit filter. If outbound
permit filters to any destination Internet Protocol (IP) address are required (for
example, an outbound filter to allow an Simple Mail Transfer Protocol (SMTP)
server to send mail to any other destination STMP server connected to the
Internet), then a firewall or other stateful filtering device must be placed between
the host computer and the Internet. When possible, outbound permit filters should
be specific to the IP address required to receive the traffic.
Important: IPSec does not provide complete security filtering during computer startup.
There is a small window of time in which the Transmission Control Protocol/Internet
Protocol (TCP/IP) stack is responsive, and that an automated attack could potentially
access applications ports that the IPSec policy would otherwise block. In most cases,
the application has not been able to start processing connections before IPSec filtering
is in place. Setting service dependencies on the IPSec Policy Agent service startup will
not effectively guarantee the filters are in place.
To achieve the highest level of security using IPSec filters, the computer should be
disconnected from the network during restart. The exact time that IPSec filters are in
place depends on many factors specific to the server configuration and the size of the
IPSec policy. Local testing should be performed to determine a safe time interval
before reconnecting your servers to your network. If testing cannot be performed, a
firewall or filtering router should be used to restrict incoming traffic to only the permitted
ports.
There are several terms that will be used throughout the remainder of the document.
●
Filter List — Includes ports, protocols, and directions. Filter lists trigger a decision
when traffic matches something specified in this list. One list can contain multiple
filters.
●
Filter Action — The required response when traffic matches a filter list. Specific
actions will include blocking or permitting certain traffic.
●
Rule — A rule is a correlation of a filter list with a filter action.
●
Policy — A collection of rules. Only one policy can be active at any particular time.
191
Planning IPSec Policies Using Network Traffic Maps
An easy way to record this information is in a table called a network traffic map. A
network traffic map contains basic information about the server role, direction of network
traffic, destination of traffic, IP address of the interface, IP protocol, the TCP port, and the
User Datagram Protocol (UDP) port involved. A sample network traffic map is shown
below.
A network traffic map helps you understand what network traffic is coming in and out of
particular servers. Before creating IPSec policies, it is critical to have a good
understanding of the traffic that will be required for the server to function properly. Failure
to do so may result in the creation of filters that are too strict, causing application failures.
In the Contoso scenario, network services were determined that would be needed by
each server role. Next, ports were identified that are required by each service. Then
IPSec filters were created that allowed only the ports that had been identified. This
process resulted in very restrictive IPSec filters. After implementing the filters, some
troubleshooting was performed to verify that all of the network services functioned
properly. A few more ports had to be enabled, which are documented for each server role
in Chapter 7, "Hardening Specific Server Roles." By starting with the most restrictive
IPSec filters and opening up additional ports as needed, the highest possible security
was achieved for these settings.
Table 6.20: IPSec Network Traffic Map
Service
Protocol
Source
Port
Destination
Port
Source
Address
Destination
Address
Action
HTTP
Server
TCP
ANY
80
ANY
Host IP
ALLOW
HTTPS
Server
TCP
ANY
443
ANY
Host IP
ALLOW
DNS Client
TCP
ANY
53
Host IP
ANY
ALLOW
UDP
ANY
53
Host IP
ANY
ALLOW
It makes the process much easier if you divide the services into client and server
services. The client services can be any service that the machine where the policies is
utilizing from another host. For example, in the above example, the server may need
DNS client services to perform name lookups for one of the Web applications.
The server services are any service that the machine is providing to other hosts. Again, in
the example above, the Web server will be providing HTTP and HTTPS services to other
machines, so appropriate traffic must be allowed. Sample scripts which implement the
settings documented in Chapter 7, "Hardening Specific Server Roles" can be
downloaded with this guide.
The data in the network traffic map will vary based on the role of the server. Once this
chart is completed, the IPSec policies can be built based on this information. It is possible
to distribute the IPSec policies based on Group Policy, but because many of the IPSec
policies will be tailored to specific computers, it may be better to use local policies to
implement these changes.
192
Implementing IPSec Policies
IPSec policies can be implemented through the IP Security Policies section of the Local
Security Settings MMC snap – in. This process is easy to implement on one server, but
may be difficult to achieve on many servers. For this reason, in this section, the scripted
method of deploying IPSec policies is discussed.
Scripted Implementation
Included in the Windows 2000 Resource Kit is IPSecPol.exe, a command – line utility that
you can use to create, assign, and delete IPSec policies. IPSecPol.exe is very flexible; it
can create dynamic and static policies in Active Directory and in local and remote
registries. See the documentation in the Windows 2000 Resource Kit for complete
information. This guide provides guidance on creating static policies in the local
computer's registry. To download IPSecPol.exe see:
http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/ipsecpol-o.asp.
IPSecPol.exe has quite a number of parameters, and its syntax can be confusing to
understand at first. However, if you follow the examples shown below, you can duplicate
the entire configuration shown previously in the graphical user interface (GUI) examples
with three commands. You might want to open the MMC and refresh its display after
each command to verify that the command performed in the way that you were
expecting. Let's get started.
The first command, shown below, creates a new policy, adds a rule to the policy, and
adds two filter lists and one filter action to the rule:
ipsecpol -w REG -p "Packet Filter" -r "Inbound web protocols"
-f *+192.168.0.201:80:TCP -f *+192.168.0.201:443:TCP -n PASS
The command is shown on two lines for printing; enter it as a single line. The parameters
are:
●
-w REG -Write a static policy to the registry. This is exactly the same as using the
MMC.
●
-p "Packet Filter" -Create a policy called "Packet Filter."
●
-r "Inbound web protocols" -Create a rule called "Inbound Web protocols."
●
-f *+192.168.0.201:80:TCP -Add a filter, where * specifies any source address and
any port, 131.107.1.1:80 specifies the destination address (the server's own
address) and specific port, :TCP specifies the protocol, and + indicates that the
filter is mirrored.
●
-f *+192.168.0.201:443:TCP -Same as the previous, except that the destination
port is 443.
●
-n PASS -Pass the traffic through without negotiating security.
Note: The values of the -w, -f, and -n parameters are case-sensitive — use lower
case only.
193
As many filters as necessary may be created. If the server runs multiple services, a
separate IPSecPol.exe command should be used for each class of filters. For example, in
addition to the Web services addressed above, the following command would allow
inbound connections to port 25 and would allow outbound connections to anywhere on
port 25:
ipsecpol -w REG -p "Packet Filter" -r "SMTP Protocol"
-f *+192.168.0.201:25:TCP -f 192.168.0.201+*:25:TCP -n PASS
The last filter, -f 192.168.0.201+*:25:TCP, looks a little different. It allows outbound traffic
to originate from the server's own address on any port to any server on port 25. This filter
allows the server to initiate outbound SMTP connections to the Internet.
However, this filter is mirrored, which also allows any remote computer to connect to any
local port on the machine if the traffic originates from port 25. There are several tools
available to modify the source port of traffic, otherwise known as "source port spoofing".
To protect your machine against such an attack, multiple one way "BLOCK" filters can be
created to prevent any unwanted traffic from coming in on port 25 and reaching other
open ports on the server. For more information on preventing this type of attack, refer to
Chapter 11 of Threats and Countermeasures: Security Settings in Windows Server 2003
and Windows XP at http://go.microsoft.com/fwlink/?LinkId=15159.
The next command creates the generic rule that matches all traffic and blocks it:
ipsecpol -w REG -p "Packet Filter" -r "All inbound traffic"
-f *+192.168.0.201 -n BLOCK
The parameters are:
●
-w REG -Write a static policy to the registry. This is exactly the same as using the
MMC.
●
-p "Packet Filter" -Add to the existing policy called "Packet Filter."
●
-r "All inbound traffic" -Create a rule called "All inbound traffic."
●
-f *+192.168.0.201 -Add a filter, where * specifies any source address and any
port, 192.168.0.201 specifies the destination address and any port, the absence of
a protocol means any protocol, and + indicates that the filter is mirrored.
●
-n BLOCK -Block the traffic.
The last command assigns the policy:
ipsecpol -w REG -p "Packet Filter" –x
The parameters are:
194
●
-w REG -Write a static policy to the registry. This is exactly the same as using the
MMC.
●
-p "Packet Filter" -Add to the existing policy called "Packet Filter."
●
-x -Assign the policy.
When adding IPSecPol.exe support to your server build scripts, it is recommended to not
actually assign the policy until after the server is completely built. The script should
include only the -n PASS and -n BLOCK commands; after all the servers are installed,
the policies can be remotely assigned using this form of the command:
ipsecpol \\machinename -w REG -p "policyname" –x
Administrative rights are required on the computer specified in the command. To
temporarily unassign a policy, replace the -x with -y.
An entire policy can be deleted in the same fashion, including all associated filter lists and
filter actions. The command to delete the policy is:
ipsecpol -w REG -p "policyname" –o
Server Roles
Because of the specific nature of each server role, specific policies will have to be
created for each role. These server specific steps are included in Chapter 7, "Hardening
Specific Server Roles."
195
Summary
This chapter explains the server hardening procedures initially applied to all of the
servers in the scenario for Contoso, Ltd. Most of these procedures were accomplished by
creating a security template and importing it into a GPO linked to the parent OU for the
member server.
However, some hardening procedures can not be applied through Group Policy. For this
reason, these were configured manually. Additional steps were taken for specific server
roles to enable them to function within their roles in as secure a manner as possible.
The role-specific steps include both additional hardening procedures, as well as
procedures to reduce the security settings in the baseline security policy. These changes
are discussed in detail in Chapter 7, "Hardening Specific Server Roles."
More Information
For more information on disabling NetBIOS, see Appendix B, "Disabling NetBIOS on
Servers in Untrusted Networks."
For information about the STRIDE (Spoofing identity, Tampering with data, Repudiation,
Information disclosure, Denial of service, and Elevation of privilege) threat model, see:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csvr2002/htm/
cs_se_securecode_zlsj.asp
For more information about security at Microsoft, see: http://www.microsoft.com/security
For information about design considerations for delegating administration in Active
Directory, see:
http://www.microsoft.com/technet/prodtechnol/ad/windows2000/plan/addeladm.asp
For more information about security threats, see:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bestprac/
secthret.asp
For more information about the relationship between .inf and .adm files, see Knowledge
Base article Q228460, "Location of ADM (Administrative Template) Files in Windows," at:
http://support.microsoft.com/default.aspx?scid=kb;en-us;228460.
For more information about applying the Q299687 Security Hotfix in an environment with
Exchange 2000 Server, see Knowledge Base article Q309622, "Clients Cannot Browse
the Global Address List After You Apply the Q299687 Windows 2000 Security Hotfix" at:
http://support.microsoft.com/default.aspx?scid=kb;en-us;309622.
For more information about hardening the Windows 2000 TCP/IP stack, see Knowledge
Base article Q315669, "HOW TO: Harden the TCP/IP Stack in Windows 2000 Against
Denial of Service," at: http://support.microsoft.com/default.aspx?scid=kb;en-us;315669.
For more details on hardening the settings for Windows Sockets applications, see
Knowledge Base article Q142641, "Internet Server Unavailable Because of Malicious
SYN Attacks," at: http://support.microsoft.com/default.aspx?scid=kb;en-us;142641.
196
For more information on ensuring that more secure LAN Manager Authentication Level
settings works in networks with a mix of Windows 2000 and Windows NT 4.0 systems
see Microsoft Knowledge Base article Q305379, " Authentication Problems in Windows
2000 with NTLM 2 Levels Above 2 in a Windows NT 4.0 Domain" at
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q305379.
For more information about LM hash authentication, see Knowledge Base article
Q147706, "How to Disable LM Authentication on Windows NT," at:
http://support.microsoft.com/default.aspx?scid=kb;en-us;147706.
For more information about disabling the creation of LM hashes, see Knowledge Base
article Q299656, "New Registry Key to Remove LM Hashes from Active Directory and
Security Account Manager," at:
http://support.microsoft.com/default.aspx?scid=kb;en-us;299656.
For more information about resolving authentication issues created by disabling null
sessions, see the Microsoft Knowledge Base article 207671: "HOW TO: Access Network
Files from IIS Applications," at:
http://support.microsoft.com/default.aspx?scid=KB;en-us;207671.
For more information about the Windows 2000 Resource Kit see:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/
windows2000serv/reskit/w2krkit.asp.
For more information about the Windows Server 2003 Resource Kit see:
http://www.microsoft.com/windowsserver2003/techinfo/reskit/resourcekit.mspx.
197
7
Hardening Specific Server
Roles
The previous chapter provides you with a solid understanding of how to develop and
deploy a secure baseline using Group Policy for the Microsoft® Windows® 2000 servers
in the Contoso, Ltd. scenario. Once a secure baseline across these servers is
established, you need to consider how to secure each server according to the role that it
plays in the infrastructure of your organization.
This chapter contains the recommended security settings to achieve a secure
environment for the following four major server roles that are present in most
organizations running Windows 2000 servers:
●
Microsoft® Active Directory® directory service domain controller
●
Infrastructure Server, providing Dynamic Host Configuration Protocol (DHCP) and
Windows Internet Naming Services (WINS) services
●
File and Print Server
●
Internet Information Services (IIS)
Each server in your environment hosts a set of application services that dictate a
complimentary set of security settings that must be applied to ensure maximum
availability and reliability of those services. These sets of security settings that you apply
ensure that the data accessible from those servers is protected.
As detailed in the Member Server Baseline Policy (MSBP) discussed in Chapter 6,
"Hardening the Base Windows 2000 Server," Group Policy is used to apply as many
security enhancements to the Windows 2000 servers in your environment as possible.
For each server role, the Group Policy settings are stored in individual security templates
that are imported into a corresponding Group Policy object (GPO). A GPO represents a
collection of Group Policy settings used to define security settings in a Windows 2000based environment.
For example, to secure the IIS servers in this scenario, the Group Policy settings
described are stored in the MSS IIS Role.inf security template. This template is imported
into the GPO for the IIS Group Policy that is linked to the Web organizational unit (OU) in
the child domain for Contoso.
199
The location of the GPOs within the Active Directory for Contoso is highlighted in the
following figure:
Figure 7.1OU security template GPO design by server role for Contoso
The settings contained within the security template for each server role in the figure
above are defined in this chapter. However, some security hardening procedures cannot
be automated through Group Policy. In these cases, specific procedures recommended
for each one are described in the later sections of this chapter.
The MSS Baseline.inf security template, which is detailed in Chapter 6, "Hardening the
Base Windows 2000 Server," is also used as the basis for the security template called
MSS DCBaseline Role.inf. The differences between the MSS Baseline.inf and MSS
DCBaseline Role.inf security templates are explained in the Domain Controllers Group
Policy section of this chapter.
200
Active Directory Domain Controller Role
The domain controller server role is one of the most important roles to defend in a
Windows 2000 Active Directory enterprise environment. This is because the loss or
compromise of the domain controllers would be devastating to clients, servers, and
applications that consume such things as domain authentication, Group Policy, and the
central lightweight directory access protocol (LDAP) directory.
Due to their importance, domain controllers should be stored in physically secure
facilities, which are accessible only to qualified administrative staff. When domain
controllers must be stored in unsecure locations, branch offices for example, certain
security settings can be adjusted to limit the potential damage from physical threats.
Where applicable, the recommended settings for domain controllers stored in unsecure
locations are noted within this chapter.
Domain Controller Baseline Policy
Unlike the other server role policies detailed in this chapter, the Group Policy for the
Domain Controllers role is a baseline policy, putting it in the same class as the Member
Server Baseline Policy (MSBP) defined in Chapter 6, "Hardening the Base Windows
2000 Server." This means that the Domain Controller Group Policy requires no other
security policies to be applied other than the Default Domain Policy inherited from the
domain container and the Default Domain Controllers Policy set in the Domain
Controllers OU.
Since the Domain Controller Baseline Policy is based on the MSBP, you should have
read Chapter 6 to understand many of the settings that are also in the Domain Controller
Baseline Policy. Most of the Domain Controller Baseline Policy is a direct copy of the
MSBP. Any settings in the Domain Controller Baseline Policy that differ from the MSBP
are documented in this section.
Note: Protection of the Directory Service (the contents of Active Directory including the
objects, classes, and attributes) is addressed in Chapter 5, "Securing the Domain
Infrastructure."
Audit Policy Settings
The Audit Policy settings for the Domain Controller Baseline Policy are the same as
those specified in the MSBP. The baseline policy settings ensure that all the relevant
security audit information is logged on the domain controllers, including Directory
Services Access.
Event Log Settings
The Event Log settings for the Domain Controller Baseline Policy are the same as those
specified in the MSBP.
201
User Rights Assignment
The Default Domain Controllers Policy specifies a number of User Rights Assignments
for the domain controllers. In addition to the default settings, there are two user rights for
which you should increase the security for the domain controllers:
●
Log on locally
●
Shut down the system
The recommended settings for these rights are identified in the following table.
Table 7.1: Domain Controller Baseline Policy User Rights Settings
User Rights Setting in UI
Groups Assigned
Recommendation
Log on locally
Administrators
Backup Operators
Server Operators
Remove Account Operators and
Print Operators because they are
only used for account management.
Printer shares should not be allowed
from the domain controllers.
Shut down the system
Administrators
Server Operators
Remove Account Operators, Backup
Operators and Print Operators as
they should not be allowed to shut
down domain controllers.
Log on Locally
Vulnerability
Any account with the right to Log on locally could be used to log on at the console of a
domain controller. When someone uses Terminal Services over the network, the account
also requires the Log on locally user right. If a user attempts to log on to the server using
Terminal Services, that person must use an account that also has Guest Access or User
Access permissions for the Terminal Services Remote Desktop Protocol (RDP).
It is a best practice to not allow unauthorized users to log on locally. In the case of the
domain controllers, this best practice typically applies to the Account Operators and
Printer Operators groups. Providing this privilege gives unauthorized users the ability to
download, view, and potentially install new code, which can then be used to exploit any
escalation of privilege vulnerability that requires local logon access.
Countermeasure
Remove the following two default groups: Account Operators and Print Operators.
Neither of these default groups should require the ability to log on to the domain
controllers in your environment. Perform this through the Domain Controller Baseline
Policy.
Alternatively, you can add these groups to the Deny Logon Locally privilege in the
Domain Controller Baseline Policy. This privilege setting is configured in the Domain
Controller Baseline Policy template.
202
Potential Impact
Removing these default groups could limit the delegated abilities of assigned user roles
in your environment. Confirm that delegated activities will not be adversely affected.
Contoso Scenario
Only Administrators, Backup Operators and Server Operators have the Log on locally
privilege on Contoso's domain controllers. Backup Operators require this privilege to
support backup software, which requires service accounts. Server Operators require this
privilege to be able to shut down the domain controllers, since it is also necessary to log
on to the domain controller to be able to shut it down.
This setting was configured to remove these default groups in the Domain Controller
Baseline Policy template.
Shut Down the System
Vulnerability
The ability to shut down domain controllers should be limited to a very small number of
trusted administrators. Even though a system shutdown requires the ability to log on to
the server, you should be very careful about the accounts and groups that you allow to
shut down a domain controller. For details on this, see Chapter 6 under the setting "Allow
system to be shut down without having to log on."
Shutting down the domain controllers would make them no longer available to perform
such functions as processing logons, serving Group Policy, and answering LDAP
queries. The impact of shutting down domain controllers that possess Flexible SingleMaster Operations (FSMO) roles is that these servers can disable key domain
functionality, such as processing logons for new passwords (the PDC Emulator role).
Countermeasure
Remove the following three default groups from any Domain Controller Group Policy that
grants the Shut down the system privilege: Account Operators, Backup Operators, and
Print Operators. These default groups should not require the ability to shut down domain
controllers.
Alternatively, if you want to delegate the ability to shut down domain controllers to other
groups, you can do so. However, keep in mind that you would normally not want to shut
down your central authentication databases, because then users cannot be authenticated
by the domain.
Potential Impact
The impact of removing these default groups could include limiting the delegated abilities
of assigned roles in your environment. Confirm that delegated activities will not be
adversely affected.
Contoso Scenario
Only Administrators and Server Operators have the Shut down the system privilege on
Contoso domain controllers. Backup Operators do not require this privilege to support
backup software. Server Operators require this privilege because they are often
delegated the ability to shut down the domain controllers without being granted
Administrators membership.
This setting to remove these default groups was configured in the Domain Controller
Baseline Policy template.
203
Security Options
The following table outlines the security option settings that are different from those in the
MSBP, or that require special considerations in the context of a domain controller. None
of these settings required any changes to default client configuration to support
connectivity with the domain controllers.
Table 7.2: Domain Controller Baseline Policy Security Option Settings
Security Option Setting in UI
Recommendation
Comment
Additional restrictions for
anonymous connections
Do not allow
enumeration of
Security Accounts
Manager (SAM)
accounts and shares.
Same as MSBP recommendation
in Chapter 6. This is especially
important for domain controllers.
Allow server operators to schedule
tasks (domain controllers only)
Disabled.
Server operators do not require
this level of privilege on domain
controllers.
LAN Manager Authentication Level
Send NTLM version 2
(NTLMv2) response
only.
Same as MSBP in Chapter 6,.
Required to support Windows 98
SE clients.
Number of previous logons to
cache (in case domain controller is
not available)
Set value to 0.
There is no reason to support
cached domain account logons,
since these servers are the
domain controllers.
Secure channel: Digitally encrypt or
sign secure channel data (always)
Disabled.
Same as MSBP in Chapter 6.
Required to support Windows 98
SE clients and any Microsoft®
Windows NT® version 4.0
Service Pack 5 (SP5) or lower
domain controllers in local and
trusted domains.
Some of the security options documented in Table 7.2 merit further explanation. The rest
of this section details the considerations behind these settings as implemented in the
domain controllers for the Contoso scenario.
204
Additional Restrictions for Anonymous Connections
Domain controllers are especially sensitive to the need of some clients for anonymous
access. For this reason, the domain controllers must allow anonymous connections to
support the following types of functionality:
●
Inter-forest trust relationships.
●
Trust relationships with Windows NT 4.0 domains.
●
Windows NT 4.0 Routing and Remote Access Services (RRAS) servers to look up
group memberships for domain user accounts.
●
Windows 98 SE and Windows NT 4.0 clients with secure channel connections for
domain logons.
Allow Server Operators to Schedule Tasks (Domain Controllers Only)
Vulnerability
Legitimate users who belong to the Server Operators group could schedule tasks in the
Domain Controllers group. Because the Scheduler Service runs by default as System, an
attacker with Server Operators membership could exploit this privilege. For example, an
attacker could schedule a task that adds his or her account to the Domain Administrators
group.
Countermeasure
Set Allow server operators to schedule tasks (domain controllers only) to the value
Disabled.
Potential Impact
Only users with domain administrator privileges will be able to schedule tasks via the
Scheduler Service on the domain controllers.
Contoso Scenario
In the Contoso scenario, only administrators need the ability to schedule tasks on the
domain controllers. Group Policy was used to set Allow server operators to schedule
tasks (domain controllers only) to Disabled.
LAN Manager Authentication Level
For the Windows 2000 domain controller, it is especially important that all clients are able
to authenticate to a domain controller in order to join the domain in the first place, as well
as to continue to participate in the domain. It is also very important that domain
controllers authenticate to domain controllers in other domains (inter-forest or Windows
NT 4.0 domains) to validate credentials outside the forest. Both of these operations
require some form of local area network (LAN) Manager (that is, non-Kerberos version 5
authentication protocol) authentication.
205
All Windows clients (including Windows 2000 and Microsoft® Windows® XP) are
configured by default to send LAN Manager (LM) and NTLM authentication responses
(except Windows 9x clients that only send LM). They do not send NTLMv2 authentication
responses by default. Therefore, enforcing NTLMv2 authentication on a Windows 2000
domain controller is not possible until all clients (and domain controllers outside the forest
that participates in trust relationships) are reconfigured to send NTLMv2 responses.
Number of Previous Logons to Cache
Vulnerability
While it is typical to allow cached logons on Windows domain clients, it is fundamentally
unnecessary to cache domain logons on a domain controller. This is because it is
impossible for the domain controller not to validate its own domain credentials.
Countermeasure
Configure the Number of previous logons to cache (in case domain controller is not
available) setting to the value 0 for domain controllers.
Potential Impact
By disabling cached logons on the domain controllers, it would be impossible to
authenticate previously authenticated accounts from other domains on a domain
controller, if the other domain's domain controllers were all inaccessible. For example, in
the Contoso child domain, it is possible that if all Contoso root domain controllers were
inaccessible, accounts such as Enterprise Admins could not log on to the child domain
controllers.
The impact of such a position is not permanent and is resolved as soon as access to the
inaccessible domain controllers is restored.
Contoso Scenario
Group Policy was used to configure the Number of previous logons to cache (in case
domain controller is not available) setting in the Domain Controller Baseline Policy to
the value 0.
Secure Channel: Digitally Encrypt or Sign Secure Channel Data
(Always)
Digital encryption and signing of the “secure channel” is worth investigating where it is
supported. However, digital encryption and signing of the secure channel is only
supported in Windows NT 4.0 SP6a or later and is not supported in Windows 9x clients.
Thus, this setting cannot be enabled on domain controllers when they have to support
Windows 9x clients as members of the domain.
This setting will only enforce signing or encryption if one of the other "when possible"
settings related to it has been applied to the domain controller. If neither of these settings
has been applied, then this setting has no effect on the domain controller. However, once
either of these other settings is enabled on the domain controller, you cannot enable this
setting until the following conditions are met.
Potential impacts from this setting include disabling the ability to create or delete
downstream trust relationships, disabling logons from downstream clients, and not being
able to authenticate other domain users from a downstream trusted domain.
206
This setting should only be enabled on your domain controllers when all the following
conditions are true:
●
All Windows 9x clients have been eliminated from the domain.
●
All Windows NT 4.0 clients, servers, and domain controllers (from trusted/trusting
domains) have been upgraded to SP6a.
●
All Windows clients have been configured to enable Secure Channel: Digitally
Encrypt Secure Channel Data (when possible) or Secure Channel: Digitally Sign
Secure Channel Data (when possible); one or both of these settings must be
enabled on the domain controllers.
System Services
This is a summary of the prescribed system services that must be enabled on all
Windows 2000 domain controllers. The system services are configured in the SCI
DCBaseline Role.inf policy template, which is then imported into the Domain Controller
Policy GPO.
Table 7.3: Mandatory Domain Controller Services in Baseline Policy
Service Name in UI
Startup Type
Comment
Distributed File System
Automatic
Required for Active Directory Sysvol share
File Replication
Automatic
Needed for file replication between domain
controllers
Intersite Messaging
Automatic
Required to support Active Directory
replication
Kerberos Key Distribution
Center
Automatic
Allows users to log on to the network using the
Kerberos V5 protocol
Remote Procedure Call
(RPC) Locator
Automatic
Allows the domain controller to provide RPC
name service
There are additional services that are commonly enabled on Windows 2000 domain
controllers, but they are not essential in every organization. The settings recommended
for these services fit the Contoso scenario, but they are frequently the subject of debate
and may not be applicable in your environment.
Table 7.4: Additional Domain Controller Services Considerations
Service Name in UI
Startup Type
Comment
DNS Server
Automatic
Active Directory-integrated DNS is used in
the Contoso environment.
IIS Admin Service
Disabled
SMTP-based Active Directory replication is
not enabled in the Contoso environment, so
IIS Admin Service is not needed.
NT LM Security Support
Provider
Automatic
Provides security to RPC programs that use
transports other than Named pipes.
Simple Mail Transport Protocol
(SMTP)
Disabled
SMTP-based Active Directory replication is
not enabled in the Contoso environment.
207
Note: If you run the DCDiag.exe utility from the Windows 2000 Support Tools, it will
check for all services that could run on the domain controllers in your environment.
Because some services are disabled in the Domain Controller Baseline Policy —
including IISADMIN, SMTPSVC, and TrkSvr — DCDiag.exe will report errors. This is to
be expected and does not indicate a problem with your configuration.
DNS Server
Vulnerability
The DNS Server service is required to support Active Directory-integrated DNS services.
The DNS Server is used to support the dynamic DNS update protocol in Windows 2000
Server.
Any running service or application is a potential point of attack —services and
components that are not running cannot effectively be attacked. Therefore, to create
more secure systems, a best practice is to turn off unused features to reduce the "surface
area" available for attack.
Countermeasure
None. This service is required.
Alternatively, if "Active Directory-integrated" DNS is not required, this service may be
disabled on the domain controllers and enabled in the Infrastructure server role. The
Infrastructure server role could then run the DNS Server service as a primary or
secondary DNS server.
Potential Impact
Disabling Active Directory-integrated DNS Services where required will make all domain
operations fail, including those for replication, logon, and Group Policy. This also will
cause failures in Active Directory-integrated applications such as Microsoft® Exchange
2000.
Contoso Scenario
The Contoso environment requires Active Directory-integrated DNS, so the DNS Server
service Startup Type was configured to the value Automatic.
Intersite Messaging
Vulnerability
This service is required by the Active Directory Knowledge Consistency Checker (KCC).
This service is also used to support SMTP–based Active Directory replication between
sites. Each transport used for replication is defined in a separate add-in dynamic link
library (DLL). The add-in DLLs are loaded into Intersite Messaging.
Intersite Messaging directs send and receive requests to the appropriate transport add-in
DLLs, which then route the messages to Intersite Messaging on the destination
computer. If you use SMTP for replication in your environment, you need to enable this
service.
Any running service or application is a potential point of attack, and, conversely, services
and components that are not running cannot effectively be attacked. Therefore, to create
more secure systems, it is a best practice to turn off unused features to reduce the
surface area available for attack.
208
Countermeasure
The option for the Intersite Messaging service should be set to Automatic in the
Domain Controller Baseline Policy.
Alternatively, if you want to generate manual replication topologies and thus do not need
to support the KCC, you may want to disable this service.
Potential Impact
None.
Contoso Scenario
Since the Contoso environment depends on the KCC to calculate replication topologies,
the Intersite Messaging Service is required, and, therefore, this service was enabled in
the Domain Controller Baseline Policy.
IIS Admin Service
Vulnerability
If the SMTP service is enabled, then the IIS Admin service also needs to be enabled
because the former is dependent on the IIS Admin service.
As stated previously, any running service or application is a potential point of attack, and,
therefore, to create more secure systems in your environment, it is a best practice to turn
off unused features and options.
Countermeasure
Set the option for IIS Admin Service in the Domain Controller Baseline Policy to
Disable.
Alternatively, if SMTP–based replication is required, then this service should be set to
Automatic startup in the Domain Controller Baseline Policy.
Potential Impact
Since this service is required for the SMTP service to successfully run, disabling the IIS
Admin Service also disables SMTP–based replication of Active Directory information. If
SMTP–based replication is required to traverse slow links and high-latency links, then
this setting will prevent such Active Directory replication. For this reason, you should set
this service to Automatic.
Contoso Scenario
Since the Contoso environment is composed of high-speed links between Active
Directory sites, SMTP–based replication is not required, and, therefore, this service was
disabled.
NTLM Security Support Provider
Vulnerability
The NTLM Security Support Provider supports the NTLM Security Support Provider
Interface (SSPI) for RPC applications that call down to the SSPI for RPC message
security. This service is considered essential for Windows 2000 servers to operate.
The NTLM SSPI provides the potential for RPC applications to authenticate to the
domain controller using the weaker LM or NTLM authentication protocols rather than the
NTLMv2 authentication protocol.
209
Countermeasure
None. This service, which is enabled by default, may be required for application
compatibility.
This service may be disabled in some circumstances, but it is considered an essential
service for supporting some older applications running under Windows 2000. If you want
to disable this service, it is strongly recommended that you first test all applications
running on or accessing your domain controllers to ensure that the absence of the NTLM
SSPI does not cause those applications to fail.
Eliminating LM and NTLM authentication (in favor of the stronger NTLMv2 and Kerberos
authentication protocols) in your environment will require some research, planning, and
testing. You should first investigate the following Microsoft Knowledge Base articles:
●
Q147706, "How to Disable LM Authentication on Windows NT."
●
Q239869, "How to Enable NTLM 2 Authentication for Windows 95/98/2000 and
NT."
Potential Impact
Enabling this service allows the relatively weak LM and NTLM protocols to authenticate
to the domain controllers in your organization, which can be mitigated by using NTLMv2
on clients of the domain controllers.
Contoso Scenario
The NTLM Security Support Provider service is needed to support many scenarios in the
Contoso environment. For this reason, this service was enabled in the Domain Controller
Baseline Policy.
Simple Mail Transport Protocol (SMTP)
Vulnerability
The SMTP service on a domain controller allows other domain controllers to replicate
Active Directory updates between sites via the SMTP protocol, as opposed to the default
RPC protocol. It is useful when attempting replication across very slow or high-latency
network links between sites containing domain controllers and is necessary when an
organization does not allow RPC to cross internal network boundaries such as firewalls.
Intersite replication can occur using either RPC or SMTP. If you use SMTP for intersite
replication in your environment, you must enable the SMTP Service.
SMTP presents two potential vulnerabilities:
1. As an additional service that listens remotely and acts on data that is submitted to
it, SMTP could potentially be subverted through buffer overflows.
2. The SMTP server can authenticate incoming SMTP requests by using domain user
accounts. However, because the SMTP server does not apply the usual account
lockout logic that is enforced by Active Directory's Password Policy, an attacker is
able to retry passwords for domain accounts without the usual lockouts or delays.
Countermeasure
If SMTP – based Active Directory replication is not needed for your environment, the
option for the SMTP service should be set to Disabled in the Domain Controller Group
Policy.
210
Alternatively, if you do not want to disable the SMTP service, you may want to investigate
securing the SMTP service itself with either Access Connection filters — the SMTP Server
Properties, Access tab, and Connection button — or Internet Protocol Security (IPSec)
filters that block connections on TCP port 25 for all but specified Internet Protocol (IP)
addresses. IPSec is a developing standard for security at the network or packet
processing layer of network communication. It is useful for implementing virtual private
networks (VPNs) and for authenticating or encrypting IP data between individual IP hosts.
You should also consider enabling the SMTP service only on replication partners that
replicate between domains that require SMTP–based Active Directory replication.
Note: If you want to enable SMTP replication, you will need to configure digital
certificates on each domain controller that will participate in the SMTP replication
partnership. See Appendix C, "Configuring Digital Certificates on Domain Controllers
for Secure LDAP and SMTP Replication," for further details.
Potential Impact
The potential impact of disabling SMTP on domain controllers is minimal, unless you
have configured SMTP – based Active Directory replication to be handled by those
domain controllers — in which case the replication would fail.
Contoso Scenario
All Active Directory replication in the Contoso environment was configured to occur via
the IP (otherwise known as RPC) transport. For this reason, the SMTP service was
disabled.
File Access Control Lists
Vulnerability
File permission ACLs for all newly-created volumes other than the %SystemDrive%
(usually the C partition) default to Everyone: Full Control. This means that any files or
folders added to such volumes will generally inherit Everyone: Full Control permissions.
Any file shares created on such volumes will expose the shared files to these file
permissions by default. These files would then be exposed to Information Disclosure and
Tampering with Data threats as defined in the STRIDE (Spoofing identity, Tampering with
data, Repudiation, Information disclosure, Denial of service, and Elevation of privilege)
model. See Chapter 2, "Defining the Security Landscape" in the Categorizing Threats
section for a more detailed description of these threats.
The only file permission ACLs changes that are enabled in the Domain Controller
Baseline Policy are on the %SystemDrive%.
You should update the file permissions on any additional nonremovable volumes that are
created along with the %SystemDrive% (for example, the D, E, and F partitions). This is
especially true for the partition that contains the Active Directory database, the DNS log
files, and any other sensitive data files.
211
Countermeasure
Configure the default permissions for all nonsystem disk partitions by enabling Full
Control inheritable permissions for Administrators, Creator/Owner, and SYSTEM. Do
not grant permissions to any other groups or users. Granting such permissions to
Creator/Owner allows the system to assign ownership to individual administrators rather
than just to the Administrators group.
Alternatively, you may want to select different permissions for the root of each volume.
However, at a minimum you should ensure that the permissions on the folders for DNS
logs and for the Active Directory database and log files are locked down to allow Full
Control only for Administrators and SYSTEM.
Potential Impact
Any applications already installed in these nonsystem partitions might fail to operate
properly if the existing permissions are overwritten. Some Windows applications are
configured to set their own explicit permissions in the directories in which they are
installed. For this reason, these applications should always be tested in a lab
environment with the permission setting changes applied to them as recommended here.
Contoso Scenario
The %SystemDrive% (typically the C partition) root permissions were configured in the
Domain Controller Baseline Policy to allow Full Control only for Administrators,
Creator/Owner, and SYSTEM and to inherit and propagate those permissions to child
folders and files. For other disk partitions, those permissions were configured manually.
XTo change root folder permissions on nonsystem disk partitions (for example
the E partition) manually
1. Open a command prompt.
2. Type the following command: cacls e:\ /t /g administrators:F system:F
"creator/owner":F
3. When prompted, type Y to proceed.
Additional Security Settings — Directory Services
Disabling the NoLmHash Setting on Domain Controllers
Vulnerability
The NoLmHash setting mitigates the vulnerability of the storage of LM hashes in the
accounts database and prevents the use of LM Challenge/Response authentication.
However, whereas the NoLmHash setting was enabled in the MSBP, it is not possible in
the Contoso scenario to enable this setting on the domain controllers.
This is because Contoso needs to support the Windows 98 clients in the scenario that
are not capable of NTLM or NTLMv2 authentication. Since the Contoso Windows 98
clients can only authenticate with the LM authentication protocol, the domain controllers
must preserve the ability to authenticate using LM, as well. This unfortunately requires a
stored version of the LM Hash on the domain controllers, which precludes the use of the
NoLmHash setting on any Contoso domain controllers.
212
Countermeasure
Ensure that the NoLmHash registry key does not exist on your domain controllers.
Potential Impact
The impact of not disabling the LM Hash creation is to continue to store an LM hash
value representing users' passwords in the Active Directory. However, the risk of
attackers gaining access to these weaker hashes is generally lower on domain
controllers than on servers and workstation because physical access is usually harder to
obtain for domain controllers. See the Use of Syskey topic later in this chapter for more
information on mitigating physical access attacks.
Not disabling the creation of the LM Hash also allows the LM Challenge-Response
authentication to occur over the network, which is the weakest of the Windows challengeresponse authentication methods. This is required for support of Windows 98 SE clients,
but is not necessary once all Windows 9x clients have been removed from the domain
environment.
Contoso Scenario
The manual change to disable the creation of the LM hash was not performed on the
domain controllers. The NoLmHash key was not added to the
HKLM\SYSTEM\CurrentControlSet\Lsa registry key in the domain controllers' registry.
Data Relocation — Active Directory Database and Log Files
Vulnerability
The database and log files (ntds.dit, edb.log, and temp.edb) are always exclusively
locked when the directory service is online; that is, these files cannot be directly read or
written. However, it is theoretically possible that they could be subverted if an attacker
somehow gained access to the files through the (lsass.exe) process that locks these files.
It is a best practice to move the Active Directory database and log files to a nonsystem
disk volume to improve domain controller performance, preferably to a striped or
striped/mirrored volume. General security best practices also recommend that sensitive
files such as these should be moved off the system volume to minimize the risk of
directory traversal attacks on these files.
Countermeasure
Ensure that during installation of the Active Directory Domain Controller, you select store
the Database and Log directories on a nonsystem volume (usually not on the C:
volume). The best choice would be a high-performance disk volume such as a striped or
striped/mirrored array.
Alternatively, for pre-existing domain controllers — assuming that you have not already
moved these files off the system partition — you could move the Active Directory
database and log files by doing the following:
●
Change the ACL on these files in the nonsystem partition.
Note: If you set the ACLs in the previous section, File Access Control Lists, then
this will not be necessary, because the more secure ACLs will propagate from the
root folder permissions.
●
Change the ACL on the boot.ini file that protects the computer restart configuration
to prevent an attacker from making Directory Services Restore Mode the default
restart selection and then rebooting the server.
213
Potential Impact
Placing the database and logs on a nonsystem volume during installation has minimal or
no impact, as long as a volume with sufficient size and performance is chosen.
Moving the database and logs on an existing domain controller can have significant
impact. This is because the system will have to be taken offline during the operation, and
because there is always the small risk that the hardware could fail during the move
procedure.
Always create a backup of the System State before proceeding with such an operation.
See Knowledge Base article Q257420, "HOW TO: Move the Ntds.dit File or Log Files" for
complete instructions on the following procedure.
Contoso Scenario
In the Contoso environment, the database and logs were installed on a nonsystem
volume during the installation process.
XTo change the location of the Active Directory database and logs during
installation of a domain controller
1. Start Dcpromo.exe, and make your chosen configurations in the Database and
Log locations dialog box.
2. Type your chosen alternative for the database location (for example, D:\NTDS) and
log location (for example E:\NTDSLogs).
3. Continue with the remaining DCPROMO steps.
XTo move the database and logs on an existing domain controller
1. Restart the domain controller.
2. Press F8 at the Startup menu, click Directory Services Restore Mode, and then
log on as the administrator when prompted.
3. Start the ntdsutil.exe utility, and then type files at the ntdsutil prompt.
4. At the File Maintenance prompt, use one or both of the following procedures:
a. To move a database, type move db to %s (where %s is the drive and folder to
which you want to move the database).
b. To move log files, type move logs to %s (where %s is the drive and folder to
which you want move the log files).
5. To view the log files or database, type info and to verify the integrity of the
database at its new location, type integrity
6. Type quit and then type quit again to return to a command prompt.
7. Restart the system in Normal mode.
Note: A domain controller that has been successfully promoted has the following
permissions assigned by default to the Ntds folder structure: Administrators and
SYSTEM = Full Control. No additional lockdown of these files is recommended.
214
Secure the Pre–Windows 2000 Compatible Access Group
Vulnerability
The default permissions on most objects in Active Directory grant read access to the
Pre–Windows 2000 Compatible Access group. All User and Group objects have this
permission, and the domain partition grants the List Contents permission to this group.
When the Everyone special group is made a member of the Pre–Windows 2000
Compatible group in an Active Directory domain, all User and Group objects become
allowed for LDAP read operations by anonymous users, including each user object's
group memberships. These anonymous users can also list the contents of the domain.
Countermeasure
Remove the Everyone alias from the Pre–Windows 2000 Compatible Access group for
an existing domain.
Alternatively, for new domains, choose the permissions compatible only with Windows
2000 servers setting in the Permissions dialog box during the DCPROMO process for
the first domain controller.
Theoretically, you could remove the inherited permissions for the Pre–Windows 2000
Compatible Access group from the domain container. However, removing blanket
permissions creates a greater risk. This is because this alternative has not been fully
tested by Microsoft, and because it limits your flexibility to leverage this permission in the
future.
It should also be pointed out that changing those permissions on Active Directory objects
does not strengthen security in your environment any more than emptying the Pre–
Windows 2000 Compatible Access group in the first place to ensure that this group
remains empty unless an attacker or worm added another account to this group.
Potential Impact
Any applications that require anonymous access to Active Directory will lose their ability
to work as expected. Services and applications known to suffer when the Everyone group
is removed from the Pre–Windows 2000 Compatible Access group include:
●
Remote Access Service (RAS) running on Windows NT 4.0 backup domain
controllers (BDCs).
●
Routing and Remote Access Service (RRAS) running on Windows NT 4.0 servers.
●
Microsoft® SQL Server™ 2000 for batch mode resolution of users' group
membership.
Note: SQL Server 2000 running on Active Directory member servers can get the
access that it needs by alternatively placing the member server's computer
account in the Pre-Windows 2000 Compatible Access group, rather than adding
the Everyone group.
●
The procedure for viewing user and group lists from trusted domains — otherwise
the group name has to be typed manually.
215
Contoso Scenario
In the Contoso scenario, the Everyone alias was removed from the Pre–Windows 2000
Compatible Access group for each domain using the following procedure.
XTo remove the Everyone alias from the Pre–Windows 2000 Compatible Access
group
1. Start a command prompt on a domain controller in the domain where this group is
to be removed.
2. Type the following command: net localgroup "Pre-Windows 2000 Compatible
Access" Everyone /DELETE
3. Type net localgroup "Pre-Windows 2000 Compatible Access" to confirm that
the group is now empty.
You should see the following results:
C:\>net localgroup "pre-windows 2000 compatible access"
Alias name
pre-windows 2000 compatible access
Comment
A backward compatibility group which allows read access
on all users and groups in the domain
Members
------------------------------------------------------------------------------The command completed successfully.
4. Restart all domain controllers in the domain for this setting to take effect.
Remove the Add Workstations to Domain Right
Vulnerability
By default, all Authenticated Users have the ability to add up to 10 computer accounts to
a Windows 2000 domain. These new computer accounts are created in the Computers
container.
As opposed to the Windows NT 4.0 domain model, in a Windows 2000 domain each
computer account is a full security principal, with the ability as the computer to
authenticate and access domain resources. Some organizations want to limit the number
of computers in the Active Directory environment so that they can be consistently built
and managed.
Giving users the ability to add workstations to the domain can hamper this effort. It also
provides avenues for users to perform activities that would be more difficult to trace by
allowing them to create additional unauthorized domain computers.
Finally, if an existing system shuts down gracefully, it will unregister its Service Principal
Name (SPN) from Active Directory. During the time that the system is down — for
example, after a Denial of Service (DoS) attack — an attacker could register his or her
own computer to that SPN and then intercept all traffic destined for the legitimate server.
216
Countermeasure
Remove the Authenticated Users group from the Add workstations to domain user
right in the Default Domain Controllers Policy.
Alternatively, if you want to allow a different, more restricted group of users to create
computer accounts, you can change the value of Add workstations to domain user
right in the Default Domain Controllers Policy. For example, you could create a new
domain group called Computer Account creators, populate the new group with the
accounts of users who should have the Add workstations to domain right, and then
add the new group name to this domain right in the Default Domain Controllers Policy.
You also can grant the Create Computer Accounts and Delete Computer Accounts
permissions on any OU (or the domain container) in the Active Directory domain to
specific groups of users. Users with these permissions are able to create any number of
computer accounts in that container (for example, a branch office OU) to which they have
these permissions.
For example, a security group called "Server Management Staff" could be granted the
Create Computer Accounts and Delete Computer Accounts permissions on the Member
Servers OU. Any member of the Server Management Staff group would then have the
ability to create any number of computers accounts in the Member Servers OU. For more
information about creating computer accounts in OUs, see the Knowledge Base article
Q251335, "Domain Users Cannot Join Workstation or Server to a Domain."
Finally, if you still want to allow all Authenticated Users to create machine accounts via
the Add workstations to domain privilege, but fewer than the default setting for ten
accounts, you can change the value of the ms–DS–MachineAccountQuota attribute from
the default value of 10 to another decimal value greater than 0. Setting this value to 0
disables this privilege. For more information, see the Knowledge Base article Q251335,
"Domain Users Cannot Join Workstation or Server to a Domain."
Potential Impact
Users who previously had the ability to add their own workstations to the domain will no
longer be able to perform that action. This could have an impact on their ability to perform
their jobs, especially if they frequently create computer accounts.
This step can increase the overhead for the environment by forcing the organization to
provision computer accounts ahead of time for new computers. It also can increase the
need to coordinate computer rollouts with a central information technology (IT) release
management team, which will have to create the computer accounts on demand.
Creating computer accounts ahead of time for new computers also creates a new
vulnerability. The longer new computer accounts go unclaimed, the more likely someone
may "steal" one by adding an unauthorized computer to the domain, and registering it
under the name of an unclaimed account. This is possible because Windows 2000 uses
a predictable default computer account password. The default password for each unused
account registered in Active Directory remains the same until a new computer claims one
by joining the domain.
The computer account "theft" would normally be reported when the legitimate user is
unable to join his or her new computer to the domain. However, the attacker may use the
domain computer during this interim period.
217
Contoso Scenario
In the Contoso scenario, all additions to the corporate network are performed by IT staff
that has Create/Delete permissions in the relevant OUs. No users are allowed to add
workstations to the domain, so the privilege was revoked for all users.
The Authenticated Users group was removed from the Add Workstations to Domain right
in the MSS DCBaseline Role.inf template using the following procedure.
XTo modify the groups that have the Add workstations to domain privilege
1. Start Active Directory Users and Computers as a user with permission to edit
the Default Domain Controllers Policy GPO.
2. Right-click the Domain Controllers OU and choose Properties.
3. Select the Group Policy tab, click the Default Domain Controllers Policy GPO
and then click the Edit button.
4. Double-click the Windows settings folder, Security Settings, Local Policies,
and then User Rights Assignment.
5. Double-click the Add workstations to domain setting.
6. To remove a member, click that member (for example Authenticated Users), and
then click the Remove button.
7. To add a member, click the Add button, select the user or group, and then click
OK.
Protect Against Denial of Service Attacks on Kerberos/TCP
Vulnerability
There are limited conditions under which Windows 2000 domain controllers will
temporarily stop accepting the Kerberos protocol requests via TCP. This is a known
issue, and it is resolved with a post-SP3 hotfix. A hotfix is a cumulative package
composed of one or more files used to address a defect in a product. Hotfixes address
specific customer situations and may not be distributed outside the customer organization
without written legal consent from Microsoft.
This vulnerability is detailed more fully in Knowledge Base article Q320903, "Clients
Cannot Log On by Using Kerberos over TCP."
It is extremely unlikely that even highly-utilized domain controllers will experience this
issue during legitimate use. However, it is possible that an attacker may exploit this DoS
condition and temporarily exhaust the ability of a domain controller to service Kerberos
via TCP requests.
By default and by design, the Kerberos authentication protocol traffic is sent and received
on User Datagram Protocol (UDP) port 88. If the Kerberos protocol packets exceed 2,000
bytes (the default size limit) then Windows 2000 will switch to using TCP port 88.
Some organizations will choose to configure their Windows 2000 and Windows XP clients
to always use Transmission Control Protocol (TCP) for the Kerberos protocol traffic.
Knowledge Base article Q244474, "Forcing Kerberos to Use TCP Rather Than UDP in
Windows 2000," explains the most common situation that warrants making this change.
218
Countermeasure
If your environment is such that you believe this to be a credible threat, or if you are
experiencing the conditions detailed in Knowledge Base article Q320903, obtain the
hotfix prescribed in this Knowledge Base article from Microsoft and deploy it to all
affected domain controllers.
Alternatively, you could monitor the calls to your help desk for indications of unusually
slow logon times. These can be an indicator that you may be experiencing this issue.
However, slower than usual logon times can be the result of many other issues.
Determining what is causing slow logon times is notoriously difficult.
You also can limit the use of the workaround detailed in Knowledge Base article
Q244474 to minimize the volume of Kerberos traffic via TCP. However, Q244474
describes a problem of failed logons, which are often due to dropped packet fragments.
Problems related to this are much harder to resolve without switching over to TCP. If you
have deliberately chosen to make that switch, it is unlikely you will be able to switch back
to the UDP.
Further, many organizations are choosing to increase the reliability of their Kerberos
protocol authentication, because this authentication protocol method is becoming key to
their enterprise applications, and switching to TCP is a key means of increasing this
reliability. For these reasons, limiting the use of TCP to minimize the DoS potential is not
recommended.
Potential Impact
The potential impact is the same as for any hotfix. As always, you should be sure to test
before rolling out the hotfix to your production environment.
Contoso Scenario
In the Contoso scenario, there is a high degree of sensitivity to logon times and the
potential of internal network attacks. For this reason, the hotfix for Knowledge Base
article Q320903 was deployed as a proactive measure.
XTo obtain and deploy the hotfix for Q320903
1. Contact Microsoft Product Support or the Premier Help Desk and request the
hotfix prescribed in Knowledge Base article Q320903.
2. Test and deploy the hotfix according to your organization's existing hotfix testing
and deployment processes.
Additional Security Settings — Active Directory Integrated
DNS
Microsoft recommends using Active Directory integrated DNS, in part because integrating
the zones into Active Directory simplifies the process of securing the DNS infrastructure.
Protect DNS Servers
Vulnerability
When a DNS server is attacked, one possible goal of the attacker is to control the DNS
information being returned in response to DNS client queries. This way, clients could be
misdirected to unauthorized computers without their knowledge. IP spoofing and cache
poisoning are examples of this type of attack.
219
In IP spoofing, a transmission is given the IP address of an authorized user to obtain
access to a computer or network. Cache poisoning occurs when by default any names
added from referral answers are cached to help expedite resolving subsequent DNS
queries.
Once clients start inadvertently communicating with unauthorized computers, those
computers may attempt to gain access to information stored on the client computers.
Not all attacks focus on spoofing DNS servers. Some DoS attacks could alter DNS
records in legitimate DNS servers to provide invalid addresses in response to client
queries. By causing the server to respond with invalid addresses, clients and servers
cannot locate the resources they need to function, such as domain controllers, Web
servers or file shares. This is discussed in the "Secure the DNS Data Container" section
later in this chapter.
Countermeasure
Since all DNS client configurations are based on IP addresses, configure all routers to
drop spoofed IP packets to ensure that the IP addresses of the DNS servers are not
being spoofed by other computers.
Alternatively, you could limit the damage to your DNS servers from such attacks by
monitoring DNS server performance.
Potential Impact
None.
Contoso Scenario
Since the Contoso DNS servers (domain controllers) in the Northamerica domain have a
relatively high Asset Priority, all routers in the Contoso environment were configured to
prevent IP address spoofing.
Not all Contoso clients are capable of using IPSec, so IPSec encryption or signing was
not enabled on the DNS servers. However, IPSec blocking filters were enabled for
different reasons — for more information, see the "Blocking Ports with IPSec Filters"
section later in this chapter.
Domain controller and DNS server performance was monitored using Microsoft
Operations Manager (MOM).
Configure Secure Dynamic Updates
Vulnerability
The Windows 2000 DNS server and client supports DDNS updates, which allow client
systems to add DNS records directly into the database on supporting DNS servers.
Unauthorized DDNS updates can be made to a Windows 2000 DNS server if:
220
●
The attacker operates a client that uses the DDNS protocol.
●
The DNS server is configured to accept unsecured updates.
At a minimum, an attacker could add bogus entries to the DNS database; at worst, the
attacker could overwrite or delete legitimate entries in the DNS database. The result of
this kind of attack could include:
●
Directing clients to unauthorized domain controllers.
When a client submits a DNS query looking for the address of a domain controller,
a compromised DNS server can be instructed to return the address of an
unauthorized server. Then, with the use of other non–DNS related attacks, the
client might be tricked into passing on secure information to the bogus server.
●
Responding to DNS queries with invalid addresses.
This would make clients and servers unable to locate one another. Without the
ability for clients to locate servers they cannot access the directory. Without the
ability of the domain controllers to locate other domain controllers, the directory will
stop replicating.
●
Creating a DoS condition in which either of the following may occur:
●
The server’s disk space may be exhausted by generating a huge zone file filled
with dummy records.
●
A huge number of entries, for example, more than 50,000, may be created in
the zone container in the directory causing slow replication.
Countermeasure
In order to prevent an attacker from registering bad records you should use secure
dynamic updates. Using secure DDNS updates guarantees that registration requests are
only processed if they are sent from valid clients in the forest. This makes it more difficult
for an attacker to launch this type of attack. An attacker must then gain access to a
workstation that is a member of the forest first.
Alternatively, you could disable DDNS updates. This would prevent the types of exploits
detailed above. However, this would significantly increase the cost of maintaining up-todate DNS records since all updates would then have to be manually processed. In a
Windows 2000 environment, the number of DNS records that have to be maintained is
probably much higher than DNS administrators would be accustomed to in pre–Windows
2000 environments.
For more details on this, see the following Knowledge Base articles:
●
Q246804, "How to Enable/Disable Windows 2000 Dynamic DNS Registrations."
●
Q198767, "How to Prevent Domain Controllers from Dynamically Registering DNS
Names."
Potential Impact
Some non–Windows 2000 systems may not be able to record DDNS entries in the Active
Directory integrated DNS zones once the zones are secured. This issue can be mitigated
for Dynamic Host Configuration Protocol (DHCP) clients by enabling Windows 2000
DHCP servers to register DNS records on behalf of DHCP clients.
However, the use of DHCP servers to register DDNS records will be of no help for non–
DHCP clients. For systems that do not support secure DDNS updates or acquire their IP
address information from a Windows 2000 DHCP server, but must have their DNS
information registered in the secure Active Directory integrated DNS zones, you will have
to register these records manually.
221
Contoso Scenario
The Active Directory-integrated DNS servers in the Contoso scenario were manually
configured to accept only secure DDNS updates.
XTo enable secure DDNS updates for each DNS zone (Forward Lookup Zone and
Reverse Lookup Zone)
1. Open the DNS Server MMC snap-in and then the folder of interest (Forward
Lookup Zone or Reverse Lookup Zone).
2. Right-click the zone of interest (for example northamerica.corp.contoso.com) and
choose Properties.
3. On the General tab, in the Allow dynamic updates? dialog box, ensure Only
secure updates is selected.
Note: This procedure assumes that on the General tab of the zone of interest, the
Type is configured as Active Directory-integrated.
Secure the DNS Data Container
Vulnerability
Permissions ACLs can be set on the zone containers to limit access by users who might
attempt to modify them via management tools like the DNS snap-in or ADSIEdit.
Administrators, Domain Administrators, Enterprise Administrators, and DNS
Administrators have Full Control permission by default to all DNS components; everyone
else is granted read access.
If the default ACLs are changed, you may encounter a non-malicious threat from users
who could unintentionally be granted the permission to modify the DNS Data containers.
This could allow modifications of the DNS Server properties or any of the data being
stored in the integrated DNS zones. Non-malicious threats typically result from
employees who are untrained in computers and unaware of security threats and
vulnerabilities.
Countermeasure
Limit the ACLs on the Microsoft DNS container in any domain that uses Active
Directory-integrated DNS to the default ACLs.
Alternatively, you could limit the membership of groups that, by default, have the ability to
modify these settings and data (that is, Administrators, Domain Administrators, Enterprise
Administrators, and DNS Administrators).
Potential Impact
Incorrect permission settings on the Microsoft DNS container or any of the integrated
DNS zones could have very serious consequences for your organization. Permissions
that are too loose could allow unauthorized users to harm your DNS servers or their zone
data. Conversely, permissions that are too tight could theoretically create a DoS condition
when trying to load DNS data from the directory, or when adding new dynamic updates.
Note: In all cases, ensure that SYSTEM has Full Control.
222
Contoso Scenario
The default permissions on the Microsoft DNS and subordinate zones in the Contoso
scenario were confirmed.
XTo view or edit the permissions for Active Directory integrated DNS
1. Open the DNS Server MMC, right-click the DNS server and choose Properties.
2. Select the Security tab, then click the Advanced button.
Configure Protection Against DNS Cache Poisoning
Vulnerability
It is possible to add unauthorized entries directly into the cache on a DNS server so that
clients may be misdirected to unauthorized locations. This is an instance of cache
pollution.
Countermeasure
Set the Secure cache against pollution option on all DNS servers to the value Enable.
With this feature enabled, the server can determine whether referred names are
potentially polluting or unsecured, and then discard them.
The server determines whether to cache each referral based on whether or not each one
can be identified as part of the exact related DNS domain name tree recorded in the
original query. For more information, see Knowledge Base article Q316786, "Description
of the DNS Server Secure Cache Against Pollution Setting."
Potential Impact
Minimal.
Contoso Scenario
The Active Directory-integrated DNS servers were secured against cache pollution in the
Contoso scenario.
XTo enable security against DNS server cache pollution
1. Open the DNS Server MMC, right-click the DNS server and choose Properties.
2. Select the Advanced tab and ensure the checkbox for Secure cache against
pollution is selected.
Secure DNS Data and Log Directories
Vulnerability
Windows 2000 DNS servers that are configured for Active Directory-integrated DNS store
their zone data in Active Directory. However, DNS servers configured as Primary or
Secondary servers will store their zone data in a text file in
%SystemRoot%\system32\dns by default.
In addition, if debug logs are configured on the DNS server, these logs are by default also
stored in a text file %SystemRoot%\system32\dns.
The default permissions on both of these files allow Read and Execute access for Users
and Modify access for Power Users.
This DNS server data could be compromised if the server is exposed to buffer overflow or
directory traversal attacks, which can enable access to data within the system volume. A
buffer overflow is a type of exploit employed by attackers to gain access to a system.
223
Countermeasure
Reduce the permissions on the %SystemRoot%\system32\dns folder so that only
Administrators and SYSTEM have permissions to these files.
Alternatively, you could move the data and log files to a separate disk volume or to
another directory that is less well-known to attackers than the default location. Moving the
files does not necessarily improve the permissions on those files however, which means
they are still potentially vulnerable to attack by those who could find them (for example,
by finding their location specified in the registry).
Potential Impact
Since only the Administrators and System require access to these files, the potential
impact is minimal. You might delegate management of DNS services to a new group that
does not have membership in the Administrators group on the DNS server. In this case,
you must ensure that the new group also has permissions to access these files to fulfill
their duties.
Contoso Scenario
In the Contoso scenario, all DNS data is derived from the Active Directory so no file
system permissions changes were necessary.
XTo limit the permissions on the default DNS files directory
1. Open a command prompt.
2. Type the following command: cacls.exe %systemroot%\system32\dns /t /
g administrators:F system:F
3. When prompted, type Y to proceed.
Note: Remember to change the directory specified in the above cacls.exe
command if you happen to move the DNS files to a new but unsecured directory.
Move DNS Data and Log Directories
Vulnerability
Windows 2000 DNS servers that are configured for Active Directory-integrated DNS store
their zone data in Active Directory. However, DNS servers configured as Primary servers
will store their zone data by default in a text file in %SystemRoot%\system32\dns.
In addition, if debug logs are configured on the DNS server, those logs are by default also
stored in a text file in %SystemRoot%\system32\dns.
This data could be read or compromised if the server is exposed to buffer overflow or
directory traversal attacks, which can enable access to data within the system volume.
Countermeasure
Move the DNS zone data files and log files to a nonsystem disk partition.
Alternatively, you could reduce the permissions level in the default directory for DNS files
located in the %SystemRoot%\system32\dns folder. However, this does not always limit
the attack potential against these files, as some attacks can occur via compromised
services that run as Administrator-level accounts or as SYSTEM.
224
Potential Impact
If you do not notify your Storage Management team of the new location for these files,
they may inadvertently get missed during scheduled backups. You can avoid a potential
availability issue by ensuring that your backup software is configured to back up these
files in their new location.
Contoso Scenario
In the Contoso scenario, the DNS zone data is integrated with Active Directory and thus
no data files were stored on disk. No changes were necessary.
In the Contoso scenario debug logging for the DNS servers is not enabled. However, the
debug log location was preconfigured to be stored on a separate disk in anticipation of
potential future use of this logging functionality.
XTo move the DNS zone data files
1. Start Regedit.exe, and browse to
HKLM\System\CurrentControlSet\Services\DNS\Parameters.
2. Select the Edit menu, choose New, String Value, and give it the name
"DatabaseDirectory."
3. Double-click the new DatabaseDirectory value entry, and then in the Value data
textbox, type the full path to the folder under which you want to store the zone data
files.
Note: DNS will not move or maintain the original database when you make this
change in the Registry.
4. Stop the DNS Server.
5. If you already have a DNS database in the Systemroot\System32\Dns folder, you
must move it to the new location manually. Move the files and folders in the
directory %systemroot%\system32\dns to the new drive folder (for example,
d:\DNS).
6. Start the DNS Server.
XTo move the DNS debug log files
1. Start Regedit.exe, and browse to
HKLM\System\CurrentControlSet\Services\DNS\Parameters.
2. Select the Edit menu, choose New, String Value, and give it the name
"LogFilePath."
3. Double-click the new LogFilePath value, and then in the Value data textbox, type
the full path to the folder and file name under which you want to store the debug
log files.
4. Restart the DNS Server.
225
Limit Zone Transfers to Authorized Systems
Vulnerability
In addition to Active Directory integrated DNS servers, there also are DNS Servers that
act as primary or secondary servers. Secondary servers typically transfer the entire zone
file from the primary server to synchronize its contents.
A DNS Server that is not configured to limit who can request zone transfers will allow the
entire DNS zone to be transferred to anyone who requests it. This can be easily
accomplished using tools such as nslookup.exe. This would expose the entire domain's
DNS dataset, including such things as which hosts are serving as domain controllers,
directory-integrated Web servers, or SQL Server 2000 databases.
Countermeasure
Configure the DNS Servers to allow zone transfers only to known computers (that is,
only to secondary DNS servers).
Alternatively, you may want to not allow zone transfers. However, this may be difficult to
justify in a large, distributed network if you have or plan to set up a hierarchy of DNS
servers and configure secondary DNS servers closer to large, remote populations of
computing users.
Potential Impact
This configuration could limit services that require the ability to request the entire DNS
zone at once. It could also slow down the response times for DNS clients that might have
to query alternative DNS servers. It could also cause some DNS queries to fail,
depending on your DNS infrastructure.
Contoso Scenario
In the Contoso Scenario there are secondary DNS zones configured on the child
domain's domain controllers, which cache the root domain's _msdcs.corp.contoso.com
zone. The root domain’s domain controllers were configured to only allow zone transfers
for this zone to the child domain's domain controllers, according to the IP addresses of
the authorized DNS servers. All other Active Directory-integrated zones were left with
default configurations that do not allow zone transfers.
XTo limit zone transfers to known servers
1. Start the DNS administrative tool, right-click the zone for which you want to
configure zone transfers, and select Properties.
2. Confirm that Allow zone transfers is enabled, and select either Only to the
following servers or Only to servers listed on the Name Servers tab.
a. If you chose Only to the following servers, fill in the IP addresses of those
authorized DNS servers in the dialog box. (This is the setting chosen for
Contoso — the IP addresses of the child domain's domain controllers were
added.)
b. If you chose Only to servers listed on the Name Servers tab, select the
Name Servers tab and fill in the information for the Name Servers (DNS
servers) that are authorized to request secondary zone transfers from this DNS
server, as well as being authoritative for this zone.
226
Blocking Ports with IPSec Filters
Vulnerability
Reducing the number of ports that are open and actively listening on the servers in your
organization will greatly reduce the attack surface of each machine. The attack surface is
the exposed area of the client/server machines in your environment that is vulnerable to
attack.
Open ports can provide an attacker with a launching pad to attack another server in the
organization — for example, a worm and Trojan horse may install applications that bind to
unauthorized ports on the server, and listen for incoming commands.
Countermeasure
Configure IPSec blocking filters that allow only the network traffic specified below. This
will reduce the number of unexpected and unauthorized applications that could
successfully receive requests or that could be attacked.
Domain Controllers require RPC traffic for several functions including client logon as
shown in the traffic map. Because of this, a range of RPC ports will need to be opened as
shown in the map below.
Each service is divided into client and server functionality. This does not necessarily refer
to a client workstation and the server. Instead, it shows the corresponding IPSec filter
that would need to be created to either utilize or provide the noted service.
For example, the DNS client policy should be applied on any machine that requires name
services functionality. The DNS server rules would only be applied on a machine that
provides DNS services. Other services, such as Simple Network Management Protocol
(SNMP) may be a bit confusing, because ports for SNMP server are permitted, but not
ports for the SNMP client. However, due to the nature of SNMP in which a remote station
contacts individual machines for information, SNMP acts as a server service on the
domain controller to provide this information to the remote station.
Before implementing IPSec filters, you must have a full understanding of the capabilities
and limitations of this technology. IPSec filters are very powerful, but can greatly impact
the manageability and usability of systems. For more information, refer to Chapter 11 of
Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows
XP at http://go.microsoft.com/fwlink/?LinkId=15159.
227
Domain Controller IPSec Network Traffic Map
Table 7.5: Domain Controller IPSec Network Traffic Map
Service
Protocol
Source
Port
Destination
Port
Source
Address
Destination
Address
Action
Domain
Member
ANY
ANY
ANY
0
ALL DC's
ALLOW
CIFS/SMB
Server
TCP
ANY
445
ANY
0
ALLOW
UDP
ANY
445
ANY
0
ALLOW
TCP
ANY
135
ANY
0
ALLOW
UDP
ANY
135
ANY
0
ALLOW
TCP
ANY
137
ANY
0
ALLOW
UDP
ANY
137
ANY
0
ALLOW
TCP
ANY
139
ANY
0
ALLOW
RPC Server
NetBIOS
Server
UDP
ANY
138
ANY
0
ALLOW
Monitoring
Client
ANY
ANY
ANY
0
MOM Server
ALLOW
Terminal
Services
TCP
ANY
3389
ANY
0
ALLOW
Global
Catalog
Server
TCP
ANY
3268
ANY
0
ALLOW
TCP
ANY
3269
ANY
0
ALLOW
DNS Server
TCP
ANY
53
ANY
0
ALLOW
UDP
ANY
53
ANY
0
ALLOW
Kerberos
Server
TCP
ANY
88
ANY
0
ALLOW
UDP
ANY
88
ANY
0
ALLOW
TCP
ANY
389
ANY
0
ALLOW
UDP
ANY
389
ANY
0
ALLOW
TCP
ANY
636
ANY
0
ALLOW
UDP
ANY
636
ANY
0
ALLOW
TCP
ANY
123
ANY
0
ALLOW
UDP
ANY
123
ANY
0
ALLOW
RPC Ports
TCP
ANY
RPC Range
ANY
0
ALLOW
ICMP
ICMP
ANY
ANY
0
ANY
ALLOW
All Inbound
Traffic
ANY
ANY
ANY
ANY
0
BLOCK
LDAP
Server
NTP Server
Note: It is important to note that the Kerberos filter is necessary if you have
implemented the NoDefaultExempt setting that is specified in Knowledge Base article
Q254728, "IPSec Does Not Secure Kerberos Traffic Between Domain Controllers."
228
All rules listed above should be mirrored when they are implemented. This ensures that
any traffic coming in to the domain controller will also be allowed to return to the
originating server.
As seen above, there are a number of ports and services that have been opened on the
domain controller. Configuring the tightest security on the domain controller would allow
you to block additional ports. However, additional ports were opened because of the
downstream client requirements for network basic input/output system (NetBIOS), as well
as to provide additional usability for the administration of the machines.
To support the client logon process, a range of ports should be designated specifically for
the use of RPC. When limiting RPC traffic in your environment to a certain number of
ports, the port range chosen should include ports over 50,000. This can be configured by
setting the following registry settings:
The HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet key should be created if
it does not already exist.
The HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\Ports should be created
and configured as a REG_MULTI_SZ with a value that represents the range of ports to
be opened.
The HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\PortsInternetAvailable
should be created and configured as REG_SZ with a value of Y.
The HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\UseInternetPorts should
be created and configured as REG_SZ with a value of Y.
After making the above changes to the Registry, the server should be restarted.
These changes could affect performance and should be tested prior to implementing in
production. The exact number of ports that will be opened will depend on the use and
functionality of the server.
Finally, note that Contoso has implemented a MOM server in their environment. Because
of the large interaction between the MOM server and the OnePoint client – the client
application that reports to the MOM console – all network traffic is allowed between the
server and the MOM server.
Scripting Commands
IPSecPol is limited in the fact that it can only add ports one at a time. Because RPC will
require a range of ports to be opened, the easiest way to address this is through the use
of a script to automatically generate a batch file with all commands necessary based on
the number of ports that will be opened.
The sample code below will generate a file called c:\ipsec.bat that contains a separate
listing for each port to be added into the IPSec policy. The PORT_START variable
defines the first port in the RPC range and PORT_END, defines the end of the range.
POLICY_NAME is the name of the IPSec Policy to which the port filters will be added.
The IP_ADDR value should be modified to reflect the IP address of the server on which
the policy will be implemented.
229
PORT_START = 57901
PORT_END = 57950
POLICY_NAME = "Packet Filter"
RULE_NAME = "RPC Ports"
BATCH_FILE = "c:\ipsec.bat"
Dim fso
Dim tf
Const ForWriting = 2
Set fso = CreateObject("Scripting.FileSystemObject")
Set tf = fso.OpenTextFile(BATCH_FILE, ForWriting, True)
tf.Write "ipsecpol -w REG -p " & chr(34) & POLICY_NAME & chr(34) & " -r " &
chr(34) & RULE_NAME & chr(34)
For i = PORT_START TO PORT_END
tf.Write " -f *+0:" & i & ":TCP"
Next
tf.WriteLine " -n PASS"
tf.Close
Similar code could be used to generate a batch file to run and establish the IPSec
policies with little manual effort. The batch file will address the areas in the tables above
marked "RPC Range." The remainder of the ports will need to be addressed with similar
methods as discussed for the other server roles.
After a range of ports is decided upon and the IPSecPol statements to implement the
filters are created, the combination of these and the remaining commands should be
executed on the server.
230
This set of commands is also included in a batch file that accompanies this guide.
ipsecpol -w REG -p "Packet Filter" -r "Domain Member"
-f 0+192.168.100.10:: -f 0+192.168.100.11:: -f 0+192.168.100.12:: -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Server"
-f *+0:445:TCP -f *+0:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Server"
-f *+0:135:TCP -f *+0:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"
-f *+0:137:TCP -f *+0:137:UDP -f *+0:139:TCP -f *+0:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring" -f 0+192.168.100.73 -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server" -f *+0:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Server"
-f *+0:3268:TCP -f *+0:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "DNS Server"
-f *+0:53:TCP -f *+0:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Server"
-f *+0:88:TCP -f *+0:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Server"
-f *+0:389:TCP -f *+0:389:UDP -f *+0:636:TCP -f *+0:636:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Server"
-f *+0:123:TCP -f *+0:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Ports"
-f *+0:57901:TCP -f *+0:57902:TCP -f *+0:57903:TCP -f *+0:57904:TCP
-f *+0:57905:TCP -f *+0:57906:TCP -f *+0:57907:TCP -f *+0:57908:TCP
-f *+0:57909:TCP -f *+0:57910:TCP -f *+0:57911:TCP -f *+0:57912:TCP
-f *+0:57913:TCP -f *+0:57914:TCP -f *+0:57915:TCP -f *+0:57916:TCP
-f *+0:57917:TCP -f *+0:57918:TCP -f *+0:57919:TCP -f *+0:57920:TCP
-f *+0:57921:TCP -f *+0:57922:TCP -f *+0:57923:TCP -f *+0:57924:TCP
-f *+0:57925:TCP -f *+0:57926:TCP -f *+0:57927:TCP -f *+0:57928:TCP
-f *+0:57929:TCP -f *+0:57930:TCP -f *+0:57931:TCP -f *+0:57932:TCP
-f *+0:57933:TCP -f *+0:57934:TCP -f *+0:57935:TCP -f *+0:57936:TCP
-f *+0:57937:TCP -f *+0:57938:TCP -f *+0:57939:TCP -f *+0:57940:TCP
-f *+0:57941:TCP -f *+0:57942:TCP -f *+0:57943:TCP -f *+0:57944:TCP
-f *+0:57945:TCP -f *+0:57946:TCP -f *+0:57947:TCP -f *+0:57948:TCP
-f *+0:57949:TCP -f *+0:57950:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP" -f 0+*:*:ICMP -f *+0:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic" -f *+0 -n BLOCK
ipsecpol -w REG -p "Packet Filter" –x
Potential Impact
Because these settings still allow RPC traffic, this server will perform much as it would
without the settings. The major benefit of these settings is that the RPC traffic is limited to
a particular range. However, this could cause performance problems based on the
number of users connecting to the computer and the number of RPC connections that
need to be established. A large amount of testing should be performed before
implementing these filters in your environment. The policies above could be tightened to
restrict this functionality, but administration of the server may become difficult.
231
The implementation of this relatively small number of IPSec policies should not have a
noticeable impact on the performance of the server. However, a large amount of testing
should be performed before implementing these filters in your environment to verify the
necessary functionality and performance. Additional rules also may need to be added to
support other applications in your environment.
Contoso Scenario
In the Contoso scenario, the IPSec filters specified above were implemented in the
company's domain controllers. The listed IP address was substituted in the scripts and
command lines as appropriate for each domain controller.
Discussion of Active Directory Security Issues
Use of Syskey
Syskey is enabled on all Windows 2000 servers in mode 1 (obfuscated key). There are
many recommendations that recommend Syskey in mode 3 (floppy storage of Syskey
password) or mode 2 (console password) for any domain controller that is exposed to
physical security threats. You can also create a Repair disk for your domain controller,
and store that floppy disk in a secure location to provide an additional backup of the
mode 2 Syskey password.
For example, Syskey mode 2 or mode 3 is often recommended for domain controllers in
branch offices that do not offer strong physical storage security for the domain controller
system. From a security standpoint, this at first appears sensible as the domain controller
would be vulnerable to being restarted by an attacker with physical access to the domain
controller, which in mode 1 would allow the attacker to read and alter the contents of the
directory.
However, the operational requirements for ensuring that the domain controllers can be
made available through restarts tend to make Syskey modes 2 or 3 difficult to support. To
take advantage of the added protection provided by Syskey, you should be prepared to
implement additional operational processes in your environment to meet the availability
requirements for your domain controllers.
First, the logistics of Syskey password or floppy disk management can be quite complex,
especially in branch offices. For example, requiring one of your branch managers or local
administrative staff to come to the office at 3 A.M. to enter the passwords, or insert a
floppy to enable other users to use the system is expensive and makes it very
challenging to achieve high availability service line agreements (SLAs).
Alternatively, allowing your centralized IT operations personnel to provide the Syskey
password remotely requires additional hardware — some hardware vendors make add-on
hardware solutions available to remotely access the console of the server, which would
be required.
Secondly, the loss of the Syskey password or floppy disk leaves your domain controller in
a state where it cannot be restarted. There is no method for you to recover a domain
controller if the Syskey password or floppy disk is lost. If this happens, the domain
controller must be rebuilt.
232
Infrastructure Server Role
The Infrastructure Server role in the Contoso scenario is either a DHCP or Windows
Internet Name Service (WINS) server.
One difference between the Infrastructure Server definition in this guide and the
Infrastructure Server role presented in the Microsoft Systems Architecture Enterprise
Data Center (MSA EDC) guide is that the role here does not include DNS. This is
because in the Contoso scenario, all DNS server functionality is configured as Active
Directory-integrated DNS and is hosted on domain controllers.
There may be companies, however, that do not want to integrate their DNS with Active
Directory, or that want to host a primary or secondary zone on a server separate from
their domain controllers. If your environment fits into one of these cases, take note of the
advice in the preceding section of this chapter, "Additional Security Settings — Active
Directory integrated DNS," and utilize the alternatives and notes provided for
organizations implementing non-integrated DNS.
Infrastructure Server Incremental Policy
The Incremental Infrastructure Policy includes settings for system services that are
required on the Infrastructure server.
System Services
The following table provides a summary of the prescribed system services that should be
disabled or enabled on a Windows 2000 Infrastructure Server. The services are
configured in the MSS Infrastructure Role.inf policy template, which is then imported into
the Infrastructure Policy GPO.
Table 7.6: Infrastructure Server Incremental Policy Service Settings
Service Setting in UI
Startup Type
Comment
DHCPServer
Automatic
To provide DHCP services to clients
NTLMSSP
Automatic
To provide security to RPC programs that use
transports other than named pipes
WINS
Automatic
To provide WINS services to clients
Note: The DNS Server is disabled for the Infrastructure Server role in the Contoso
Scenario because it runs on the domain controllers.
Some organizations that may not use Active Directory-integrated DNS may want to run
their primary and secondary DNS Server on an Infrastructure server.
In this case, the Incremental Infrastructure Group Policy template has to be altered to
enable the DNS Server service Startup Type to be set to Automatic.
If this is necessary in your organization, see the section "Additional Security Settings —
Active Directory Integrated DNS" in this chapter for recommendations on securing a
Windows 2000 DNS server.
233
Additional Security Settings — WINS
Blocking Ports with IPSec Filters
Vulnerability
As mentioned previously, reducing the number of ports that are open and actively
listening on the servers in your organization will greatly reduce the attack surface of each
machine. Open ports can provide an attacker with a launching pad to attack another
server in the organization — for example, a worm and Trojan horse may install
applications that bind to unauthorized ports on the server and listen for incoming
commands.
Countermeasure
Configure IPSec blocking filters that allow only the specified network traffic below. This
will reduce the number of unexpected and unauthorized applications that could
successfully receive requests or that could be attacked.
Before implementing IPSec filters, you must have a full understanding of the capabilities
and limitations of this technology. IPSec filters are very powerful, but can greatly impact
the management and usability of systems. For more information, refer to Chapter 11 of
Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows
XP at http://go.microsoft.com/fwlink/?LinkId=15159.
WINS Server IPSec Network Traffic Map
Table 7.7: WINS Server IPSec Network Traffic Map
234
Service
Protocol
Source
Port
Destination
Port
Source
Address
Destination
Address
Action
Domain
Member
ANY
ANY
ANY
0
ALL DC's
ALLOW
Monitoring
Client
ANY
ANY
ANY
0
MOM Server
ALLOW
Terminal
Services
TCP
ANY
3389
ANY
0
ALLOW
WINS
Resolution
Server
TCP
ANY
1512
ANY
0
ALLOW
UDP
ANY
1512
ANY
0
ALLOW
WINS
Replication
Client
TCP
ANY
42
0
WINS Server
ALLOW
UDP
ANY
42
0
WINS Server
ALLOW
WINS
Replication
Server
TCP
ANY
42
ANY
0
ALLOW
UDP
ANY
42
ANY
0
ALLOW
ICMP
ICMP
ANY
ANY
0
ANY
ALLOW
All Inbound
Traffic
ANY
ANY
ANY
ANY
0
BLOCK
Note: The Host IP destination address listed in Table 7.7 should be set to the IP
address configured on your server.
All rules listed above should be mirrored when they are implemented. This ensures that
any traffic coming in to the server will also be allowed to return to the originating server.
As seen above, there are a small number of ports and services that have been opened
on the WINS server. With this additional level of security, all WINS management and
management of the servers will need to be performed through the use of Terminal
Services.
Also note that Contoso has implemented a MOM server in their environment. Because of
the large interaction between the MOM server and the OnePoint client – the client
application that reports to the MOM console – all network traffic is allowed between the
server and the MOM server.
Scripting Commands
Implementation of the following commands should be executed on the server. These
commands will block all network traffic except what is specifically allowed. This set of
commands is also included in a batch file that accompanies this guide.
ipsecpol -w REG -p "Packet Filter" -r "Domain Member"
-f 0+<INSERT DC IP>:: -f 0+<INSERT DC IP>::
-f 0+<INSERT DC IP AND REPEAT AS NECESSARY>:: -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring"
-f 0+<INSERT MOM SERVER IP> -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server" -f *+0:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Resolution Server"
-f *+0:1512:TCP -f *+0:1512:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Replication Client"
-f 0+<INSERT WINS Replication Partner>:42:TCP
-f 0+<INSERT WINS Replication Partner>:42:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Replication Server"
-f <INSERT WINS Replication Partner>+0:42:TCP
-f <INSERT WINS Replication Partner>+0:42:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP" -f 0+*:*:ICMP -f *+0:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic" -f *+0 -n BLOCK
ipsecpol -w REG -p "Packet Filter" –x
235
Potential Impact
Because these settings do not allow network traffic through random high ports, RPC
traffic will not be allowed. This can make management of the server difficult. However,
with the use of terminal services, a large amount of usability is regained.
The implementation of this relatively small number of IPSec policies should not have a
noticeable impact on the performance of the server. However, a large amount of testing
should be performed before implementing these filters in your environment to verify
functionality and performance required for your organization. Additional rules may need
to be added to support other applications in your environment.
Contoso Scenario
Contoso implemented the IPSec filters as specified above for their WINS servers.
Additional Security Settings — DHCP
Configure Logging
Vulnerability
DHCP clients are often difficult to track down in log entries because the only information
that is stored in most event logs are computer names, not IP addresses. The DHCP audit
logs can provide one more tool in your forensic arsenal to track down the sources of
internal attacks or inadvertent activities.
However, the information in these logs is not by any means foolproof, since both
hostnames and media access control (MAC) addresses can be forged or spoofed. In any
case, there is greater benefit than cost to collecting this information to help fill the gap
between having only an IP address and a record to track down how the IP address was
used in a short time.
Because by default the DHCP audit logging function is not enabled, this information
would not be collected.
Countermeasure
Set the value for DHCP audit logging to Enable.
Potential Impact
This information could be misused or altered by those with privileged access to the log
files. The permissions on these files also should be limited.
While the DHCP audit logs could in theory fill the disk on which they are stored, the
default configuration of DHCP audit log disk space checking is sufficient to prevent this
from occurring. Check the settings to ensure there is sufficient free disc space for your
other applications. For more information about the DhcpLogMinSpaceOnDisk setting, see
the entry on it in the Windows 2000 Server Resource Kit at:
http://www.microsoft.com/windows2000/techinfo/reskit/en-us/regentry/46692.asp.
236
Contoso Scenario
In the Contoso scenario, this information was not considered harmful and of potential use
to provide an additional avenue for auditing user activity.
XTo enable DHCP audit logging
1. Start the DHCP Manager snap-in.
2. Right-click the name of the server, click Properties, and then click the General
tab.
3. Select the Enable Audit Log check box to enable it.
4. Restart the DHCP Server.
Protect Against Denial of Service Attacks on DHCP
Vulnerability
DHCP servers are a central resource, and DoS attacks against DHCP servers can have
widespread consequences. If a DHCP Server is attacked and is no longer able to service
DHCP requests, DHCP clients would eventually not be able to acquire leases. Those
clients would lose their existing IP lease and would lose the ability to access network
resources.
It would not be very difficult to write an attack tool script to request all available addresses
on a DHCP server. This would exhaust the pool of available IP addresses for
subsequent, legitimate requests from DHCP clients. It is also possible for a malicious
user to configure all DHCP IP addresses on the network adapter of a computer they
administer, thus causing the DHCP server to detect IP address conflicts for all addresses
in its scope and to refuse to allocate DHCP leases.
In addition, as with all other network services, a DoS attack (for example, CPU
exhaustion or filling the request buffer of the DHCP listener) that exhausts the DHCP
server's ability to respond to legitimate traffic, could make it impossible for clients to
requests leases and renewals. For recommendations on mitigating the risk of networkbased DoS attacks, see the Security Considerations for Network Attacks section in
Chapter 6, "Hardening the Base Windows 2000 Server."
Fortunately, the DHCP client behaviors are such that periodic outages can often be
tolerated, except during client startup when it does not have a valid lease. If the DHCP
server does not respond when one of the early DHCP renewal messages is sent, the
client will retry at a later time, and will repeat trying until it finally acquires a renewal or
fresh lease.
Generally, DoS attacks against a DHCP server are only possible from internal attackers,
who may be less likely to attack infrastructure servers than systems with sensitive data to
be stolen.
Countermeasure
Configure DHCP servers in pairs and split allocated IP addresses across the servers
according to the best practice 80/20 rule. For details on the 80/20 rule and the DHCP
protocol, see: http://www.microsoft.com/windows2000/techinfo/reskit/
en-us/cnet/cncb_dhc_ogjw.asp.
237
Alternatively, you could increase the lease time on DHCP scopes so that if an outage
were to occur, more clients would be able to tolerate the outage for longer periods of
time. However, this does not directly protect against server outages if a client required an
immediate DHCP lease, such as when a new computer is restarted on the LAN.
You could also monitor for performance and availability of the Windows 2000 server and
the DHCP service.
You could configure DHCP clustering, which would help alleviate DoS attacks if one of
the individual hosts themselves were attacked, and not the clustered DHCP resource.
Finally, you could implement multiple, separate DHCP servers that each allocate IP
addresses to separate subnets in your environment. Each DHCP server would allocate
all IP addresses for any one subnet. This approach fully isolates each subnet from
problems another subnet's DHCP server may have, but does not provide the fault
tolerance necessary in most enterprise environments.
Potential Impact
The potential impact is the added overhead of managing additional servers. In addition, if
you were not careful in configuring the 80/20 allocations of IP addresses among multiple
DHCP servers, incorrectly configured servers could allocate the same IP address to more
than one client. The increased DHCP lease time could also lead to periods when the
DHCP address space has been exhausted, which is simply another type of DoS attack.
Contoso Scenario
In the Contoso scenario, each site has two DHCP servers configured according to the
80/20 rule to allocate IP addresses. The default lease time of eight days was considered
sufficient to provide for even long outages of the DHCP service.
XTo change the DHCP lease time
1. Start the DHCP Manager snap-in.
2. Right-click the scope whose lease duration you want to change and click
Properties.
3. Under the Lease duration for DHCP clients dialog box on the General tab,
change the Limited to values to the time span you want to implement.
You may also select the Unlimited lease duration option, but this setting is only
advisable in limited circumstances, and not generally for enterprise DHCP
deployments.
Blocking Ports with IPSec Filters
Vulnerability
As mentioned previously, reducing the number of ports that are open and actively
listening on the servers in your organization will greatly reduce the attack surface of each
machine. Open ports can provide an attacker with a launching pad to attack another
server in the organization — for example, a worm and Trojan horse may install
applications that bind to unauthorized ports on the server and listen for incoming
commands.
Countermeasure
Configure IPSec blocking filters that allow only the traffic specified below. This will reduce
the number of unexpected and unauthorized applications that could successfully receive
requests or that could be attacked.
238
Before implementing IPSec filters, you should gain a full understanding of the capabilities
and limitations of this technology. IPSec filters are very powerful, but can greatly impact
the management and usability of systems. For more information, refer to Chapter 11 of
Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows
XP at http://go.microsoft.com/fwlink/?LinkId=15159.
DHCP Server IPSec Network Traffic Map
Table 7.8: DHCP Server IPSec Network Traffic Map
Service
Protocol
Source
Port
Destination
Port
Source
Address
Destination
Address
Domain
Member
ANY
ANY
ANY
0
ALL DC's
Action
ALLOW
Monitoring
Client
ANY
ANY
ANY
0
MOM Server
ALLOW
Terminal
Services
TCP
ANY
3389
ANY
0
ALLOW
DHCP
Server
UDP
68
67
ANY
0
ALLOW
ICMP
ICMP
ANY
ANY
0
ANY
ALLOW
All Inbound
Traffic
ANY
ANY
ANY
ANY
0
BLOCK
All rules listed above should be mirrored when they are implemented. This ensures that
any traffic coming in to the server will also be allowed to return to the originating server.
As seen above, there are a small number of ports and services that have been opened
on the DHCP server. Because of the increased level of security, management of the
servers will need to be performed via Terminal Services.
Also note that Contoso has implemented a MOM server in their environment. Because of
the large interaction between the MOM server and the OnePoint client – the client
application that reports to the MOM console – all network traffic is allowed between the
server and the MOM server.
239
Scripting Commands
Implementation of the following commands should be executed on the server. These
commands will block all network traffic except what is specifically allowed.
This set of commands is also included in a batch file that accompanies this guide.
ipsecpol -w REG -p "Packet Filter" -r "Domain Member"
-f 0+<INSERT DC IP>:: -f 0+<INSERT DC IP>::
-f 0+<INSERT DC IP AND REPEAT AS NECESSARY>:: -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring"
-f 0+<INSERT MOM SERVER IP> -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server" -f *+0:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "DHCP Server" -f *:68:UDP+0:67:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP" -f 0+*:*:ICMP -f *+0:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic" -f *+0 -n BLOCK
ipsecpol -w REG -p "Packet Filter" –x
Potential Impact
Because these settings do not allow network traffic through random high ports, RPC
traffic will not be allowed. This can make management of the server difficult.
Administrators should be able to connect with a Terminal Services client to perform
remote administration.
The implementation of this relatively small number of IPSec policies should not have a
noticeable impact on the performance of the server. However, a large amount of testing
should be performed before implementing these filters in your environment to verify
functionality and performance required for your organization. Additional rules may need
to be added to support other applications in your environment.
Contoso Scenario
Contoso implemented the IPSec filters as specified above for their DHCP servers.
240
File and Print Server Role
The servers in the file and print server role can be difficult to harden, since the most
essential services on these servers are the ones that require the Windows NetBIOSrelated protocols. The protocols for SMB and CIFS can provide rich information to
unauthenticated users and are often recommended to be disabled in high-security
Windows environments.
File and Print Incremental Group Policy
The File and Print Incremental Group Policy does the following two things:
●
Enables the Spooler service, which is used for printing.
●
Disables the security options setting: Digitally sign server communication
(always). If this setting is not disabled, clients will be able to print, but will not be
able to view the print queue. When attempting to view the print queue they will
receive the message: "Unable to connect. Access denied."
Note: For print clients to support viewing print queues on a Windows 2000 file and print
server, the client computers should have the configuration for Digitally sign client
communication (always) set to Disabled.
System Services
Any service or application is a potential point of attack, and therefore any unneeded
services or executable files should be disabled or removed. In the MSBP, these optional
services as well as all other unnecessary services are disabled. However, the File and
Print server role relies on one of these disabled services: the Print Spooler. Therefore,
the startup mode for it is set to Automatic in the File and Print Policy.
Note: The Spooler service is also used on any client system that sends, or initiates a
print job to a print server. Because the MSBP disables the Spooler service, you will not
be able to issue print jobs from any server but the File and Print servers. If you want to
print from other servers, you must enable the Spooler service in its corresponding
Group Policy.
There are additional Services that are often enabled on Windows 2000 File and Print
servers, but they are not essential. These services are disabled in the Contoso scenario,
but the use and security of these services is frequently the subject of debate. For this
reason, recommendations on this server role in this guide may not be applicable to your
environment. Adjust these File and Print Group Policy recommendations as needed to
meet the requirements of your organization.
241
Distributed File System
The Distributed File System (DFS) is a service that integrates disparate file shares into a
single logical namespace. DFS manages logical volumes distributed across a local or
wide area network (WAN) and is required for the Active Directory SYSVOL share.
This namespace is a logical representation of the network storage resources that are
available to users on the network. If the DFS service is turned off, users will be unable to
access network data through the logical namespace. In order to access the data, users
will need to know the names of all the servers and shares in the namespace, and access
each of these targets independently.
DFS is not supported in the File and Print role in the Contoso scenario. For this reason,
DFS service is disabled in the File and Print Group Policy. If your organization uses DFS
on file servers to simplify accessing distributed resources, you will need to either modify
the File and Print Server Group Policy or create a new GPO to enable this service, and
then apply it to the file servers that need DFS enabled.
NT File Replication Service
The NT File Replication Service (NTFRS) maintains synchronization of file directory
contents among multiple servers. NTFRS is the automatic file replication service in
Windows 2000. The service maintains copies of files on multiple servers simultaneously
and also replicates the Windows 2000 system volume SYSVOL on all domain controllers.
NTFRS can be configured to replicate files among alternate targets associated with the
fault-tolerant DFS. If this service is disabled, file replication will not occur and server data
will not be synchronized.
NTFRS is not supported in the File and Print role in the Contoso scenario. For this
reason, the NTFRS service is disabled in the File and Print Policy. If your organization
uses NTFRS on file servers to replicate data across multiple servers, either modify the
File and Print Server Group Policy or create a new GPO to enable this service, and then
apply it to the file servers that need it.
Additional Security Settings
Reset the Default File Share Permissions
Vulnerability
By default, members of the local Administrators, Power Users, and Server Operators
groups are able to create new file shares and printer shares. New file shares have a
default share permission of Full Control for the special built-in group called Everyone.
This creates a potential vulnerability because forgetful IT team members may
accidentally create new shares allowing anyone who can connect to the folder share to
gain full control access to objects within it.
Note: The built-in Power Users group is not available on Domain Controllers, but a
group with similar privileges is present on domain controllers called the Server
Operators group.
Countermeasure
Train all administrators who are able to create new file shares to manually configure the
share permissions so that only users who need access to the shares can use them, and
then ensure to set these permissions as restrictively as possible.
242
Potential Impact
Users who create and manage shared folders will need to manually configure
permissions on those shares.
Contoso Scenario
All files shares created on the File and Print Server were configured to allow
Authenticated Users: Modify permissions, and the shared folders and files were
appropriately secured as well using NTFS permissions.
XTo manually change share permissions for new shares
1. Start the Computer Management MMC snap-in, and browse to the Shared
Folders, then the Shares node.
2. Right-click Shares, choose New File Share, and click the Browse button to find
the Folder to Share (for example, E:\Users). Give the share a name in the Share
name dialog box.
3. On the Create Shared Folder window, choose the Customize share and folder
permission radio button, and click the Custom button.
4. Click the Remove button to remove the Everyone listing. Click the Add button,
type Authenticated Users in the lower text area (where it says << Type names
separated by semicolons or choose from list >>) and click the OK button.
5. Select the Change checkbox under the Allow column, click OK, and then the
Finish button. Choose No when prompted.
Audit the Existing File Share Permissions
Vulnerability
As described above, new file shares have a default share permission of Full Control for
the special built-in group called Everyone. This means that there may be existing shared
folders on your network that grant full control to the Everyone group.
Countermeasure
Audit all shared folders in your organization to verify that appropriate permissions are
assigned to each one. This can be done manually by visiting each file server, or by using
commands such as net view or third-party tools to automatically document the
permissions on all file shares.
Potential Impact
The process of correcting permissions on shared folders could lead to some legitimate
users losing access to those resources. These situations will have to be addressed as
they arise.
This could especially affect users whose access is made possible through permissions
that still allow access to Security IDs (SIDs) stored in their SIDHistory. A SID is a value
that uniquely identifies each user, group, computer account, and logon session on a
network.
When Windows user accounts are migrated from older Windows NT 4.0 domains or
Windows 2000 domains that are not part of the current Active Directory forest, often the
migration is performed with tools that preserve users' permissions by using the
SIDHistory attribute of the new domain user account. The SIDHistory attribute records
the former SIDs from the migrated account to preserve access to existing secured
resources.
243
The most common use of SIDHistory is to preserve existing access to file and printer
shares without having to update all their ACLs.
The permissions on existing file and printer shares may not have been updated yet to
allow access for the current user account or groups, and users may still unknowingly rely
upon the permissions that allow the SIDs in the users' SIDHistory attributes.
To administrators with no knowledge of migrated accounts and SIDHistory, the ACLs on
pre-existing file or printer shares may appear to have unnecessary entries, or entries that
do not resolve to existing users and groups in the domain. However, if these entries are
deleted, users reliant on SIDHistory to provide access will lose access, and they can
potentially lose all access to these file and printer shares.
If your environment includes file and print servers that were in production before a user
account migration from old Windows domains, you should carefully document the
permissions that currently exist on the file and printer shares before making any changes
to the ACLs. Be prepared to create new ACLs that will provide the same access, or to
restore the file and print server from backup media to preserve the deleted ACL entries.
Contoso Scenario
Since the Contoso environment does not include any pre-existing file servers, there was
no need to update existing file share permissions. All new file shares were manually
configured to provide only the minimum necessary permissions for users.
Blocking Ports with IPSec Filters
Vulnerability
As mentioned previously, reducing the number of ports that are open and actively
listening on the servers in your organization will greatly reduce the attack surface of each
computer. Open ports can provide an attacker with a launching pad to attack another
server in the organization — for example, a worm and Trojan horse may install
applications that bind to unauthorized ports on the server and listen for incoming
commands.
Countermeasure
Configure IPSec blocking filters that allow only the network traffic specified below. This
will reduce the number of unexpected and unauthorized applications that could
successfully receive requests or that could be attacked.
Before implementing IPSec filters, you must have a full understanding of the capabilities
and limitations of this technology. IPSec filters are very powerful, but can greatly impact
the management and usability of systems. For more information, refer to Chapter 11 of
Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows
XP at http://go.microsoft.com/fwlink/?LinkId=15159.
244
File and Print Server IPSec Network Traffic Map
Table 7.9: File and Print Server IPSec Network Traffic Map
Service
Protocol
Source
Port
Destination
Port
Source
Address
Destination
Address
Action
Domain
Member
ANY
ANY
ANY
0
ALL DC's
ALLOW
CIFS Server
TCP
ANY
445
ANY
0
ALLOW
UDP
ANY
445
ANY
0
ALLOW
NetBIOS
Server
TCP
ANY
137
ANY
0
ALLOW
UDP
ANY
137
ANY
0
ALLOW
TCP
ANY
139
ANY
0
ALLOW
UDP
ANY
138
ANY
0
ALLOW
Monitoring
Client
ANY
ANY
ANY
0
MOM Server
ALLOW
Terminal
Services
TCP
ANY
3389
ANY
0
ALLOW
ICMP
ICMP
ANY
ANY
0
ANY
ALLOW
All Inbound
Traffic
ANY
ANY
ANY
ANY
0
BLOCK
All rules listed above should be mirrored when they are implemented. This ensures that
any traffic coming in to the server will also be allowed to return to the originating server.
As seen above, there are a small number of ports and services that have been opened
on the File and Print server. Because of this additional level of security, all management
of the servers will be performed through the use of Terminal Services.
Also note that Contoso has implemented a MOM server in their environment. Because of
the large interaction between the MOM server and the OnePoint client – the client
application that reports to the MOM console – all network traffic is allowed between the
server and the MOM server.
245
Scripting Commands
Below is a sample of the complete set of commands. This set of commands is also
included in a batch file that accompanies this guide.
ipsecpol -w REG -p "Packet Filter" -r "Domain Member" -f 0+<INSERT DC IP>::
-f 0+<INSERT DC IP>:: -f 0+<INSERT DC IP AND REPEAT AS NECESSARY>::
-n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Server"
-f *+0:445:TCP -f *+0:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"
-f *+0:137:TCP -f *+0:137:UDP -f *+0:139:TCP -f *+0:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring"
-f 0+<INSERT MOM SERVER IP> -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"
-f *+0:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP"
-f 0+*:*:ICMP -f *+0:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"
-f *+0 -n BLOCK
ipsecpol -w REG -p "Packet Filter" –x
Potential Impact
As mentioned before, the implementation of this relatively small number of IPSec policies
should not have a noticeable impact in the performance of the server. However, thorough
testing should be performed before implementing these filters in your environment to
verify necessary functionality and performance. Additional rules may need to be added to
support other applications in your environment.
Contoso Scenario
Contoso implemented the IPSec filters as specified above for their File and Print servers.
246
IIS Server Role
Recent reports have suggested that one out of every nine IIS servers is susceptible to
some form of attack. Internet Information Services (IIS) 5.0 is installed by default on all
Windows 2000 servers. IIS 5.0 enables a variety of application features out of the box,
and is an example of an application service that achieved good usability at the expense
of sufficient security safeguards. This vulnerability was exploited by the Nimda worm.
In order to increase security it is likely that some level of IIS usability could be lost. IIS 5.0
is extremely flexible, meaning it contains a large number of features enabled as part of
the default installation. As with any server, every service and feature that is enabled
increases the attack surface of that asset.
However, IIS can be significantly locked down and still provide the vast majority of its
essential functionality. The once time-consuming task of locking down IIS servers has
become much easier with the use of tools such as IISLockDown and URLScan.
The IIS Lockdown Tool is a Microsoft utility that turns off features you are not using in IISdependent Microsoft products, reducing the attack surface available to attackers.
URLScan is an Internet Server Application Programming Interface (ISAPI) filter that
analyzes incoming Hypertext Transfer Protocol (HTTP) packets and can reject Web
requests based on rules you set.
These tools can be combined with a well architected server and the use of IPSec filters
on the client-facing network interface of the IIS Server to produce an extremely secure
solution.
Patching the Server
As the first step in hardening IIS servers in your environment, it is imperative is to apply
all service packs and security hotfixes. These procedures are further described in
Chapter 8, "Patch Management."
By patching the server immediately, even prior to its introduction to the network, the risk
of the server being infected by a worm or other exploit such as Code Red or Nimda is
greatly reduced. Therefore, the server should be completely patched and hardened as
much as possible before being introduced on the network.
IIS Lockdown
After applying the necessary patches, the second step in hardening an IIS server is to
configure the server using recommended automated tools such as IISLockdown and
URLScan.
Overview
IIS servers can provide a great deal of functionality. However, to secure IIS servers the
functionality of these servers should be limited to only what is required. The easiest way
to accomplish this is with the IIS Lockdown Tool.
247
The IIS Lockdown Tool is a configurable utility that asks you to specify the application
role played by your IIS server (for example, Dynamic Web Server or Exchange Server). It
will then remove any functionality that is not required for the particular Web server role.
You should thoroughly test any changes before implementing them in a production
environment.
Note: The IIS Lockdown Tool is available as part of the Security Toolkit and on the
Microsoft Security Web site. Further details can be found in the "More Information"
section at the end of this chapter.
The IIS Lockdown Tool can perform many steps to help secure Web servers. These
include:
●
Disabling services and components.
●
Installing URLScan.
●
Removing unneeded ISAPI DLL script mappings.
●
Removing unneeded directories.
●
Changing file and folder ACLs.
IIS Lockdown can be used to secure many types of IIS server roles. You should select
the role that is most appropriate for the type of application being hosted on each IIS
server in your environment.
IIS Lockdown Installation
In Contoso's environment, IIS is most typical used as a Dynamic Web Server to support
the use of Active Server Pages (ASP). Version 2.1 of the IIS Lockdown Tool was used to
secure the servers in the Contoso environment. This was the latest version of the tool at
the time of writing. Older versions may not work as well, and future versions may support
new features unavailable in this guide.
XTo manually secure a Dynamic Web Server with the IIS Lockdown Tool
1. Start iislockd.exe.
2. Click Next.
3. Select I agree, and then click Next.
4. Select Dynamic Web server (ASP enabled), and then click Next.
5. Ensure Install URLScan filter on the server is selected and click Next.
6. Click Next.
7. If the Digital Signature Not Found dialog box appears, click Yes.
8. Click Next.
9. Click Finish.
Note: The IIS Lockdown tool can also be run in unattended mode to automate the
deployment of the settings you choose. See the RunLockdUnattended.doc help file that
is included in the iislockd.exe self-extracting zip file for more details.
248
Following the steps above configures the IIS Server as a Dynamic Web Server. The
configuration process results in the following changes:
●
The FTP Service is disabled.
●
The E-mail (SMTP) Service is disabled.
●
The Network News Transfer Protocol (NNTP) Service is disabled.
●
The Index Server Web Interface (.idq, .htw, .ida) script map is disabled.
●
The Server side includes (.shtml, .shtm, .stm) script map is disabled.
●
The Internet Data Connector (.idc) script map is disabled.
●
The .HTR scripting (.htr) script map is disabled.
●
The Internet printing (.printer) script map is disabled.
●
The printer virtual directory is removed.
●
The IIS Samples virtual directory is removed.
●
The Scripts virtual directory is removed.
●
The MSADC virtual directory is removed.
●
The IISAdmin virtual directory is removed.
●
The IISAdmin Web site is removed.
●
The IISHelp virtual directory is removed.
●
File permissions are configured to prevent anonymous IIS users from running
system utilities.
●
File permissions are configured to prevent anonymous IIS users from writing to
content directories.
●
Web Distributed Authoring and Versioning (WebDAV) is disabled.
●
The URLScan filter is installed on the server.
Note: If a different IIS Lockdown security template is required, or if it is necessary to
customize the chosen settings, additional services may need to be re-enabled that are
disabled by the MSBP. These may include SMTP, NNTP, or FTP.
However, simply running the IIS Lockdown Tool and selecting one of these services
will not permanently re-enable it, because the IIS Group Policy will disable those
services upon the next Group Policy refresh. The services must be manually enabled
in the IIS Group Policy that you have deployed in the Web OU.
Services
Vulnerability
Any running service or application is a potential point of attack — any services and
components that are not running cannot effectively be attacked. Therefore, to create
more secure systems, a best practice is to turn off unused features to reduce the attack
surface of the IIS servers in your environment.
Countermeasure
Use the IISLockdown Tool to disable the SMTP and FTP services that are installed by
default. NNTP also should be disabled if it was installed with IIS.
Alternatively, the IISLockdown Tool can be used to uninstall these services.
249
Potential Impact
The UninstallServices setting in the iislockd.ini file must be carefully considered. This
setting is set to FALSE for all preconfigured templates that come with version 2.1 of the
IIS Lockdown Tool. If the iislockd.ini file is modified to enable this setting to TRUE, those
services will no longer be installed on the server on which IIS Lockdown has been
applied. To re-enable one of those services on a server, it will have to be manually reinstalled via Add/Remove Programs or the server will need to be rebuilt according to the
server deployment methodology.
Contoso Scenario
The IIS Lockdown Tool was used in the Contoso scenario to disable the NNTP, FTP, and
SMTP services on the organization's IIS servers, but not to uninstall the services.
XTo uninstall the NNTP, FTP and SMTP services from IIS Servers using a
custom IISLockd.ini file
1. Open the IISLockd.exe file with a decompression utility such as WinZip, and
extract all the files to your hard drive.
2. Open the iislockd.ini in Notepad.exe.
3. Find the section corresponding to the role you want to configure (for example,
[dynamicweb] for the Dynamic Web Server role), and change the
UninstallServices setting under that section to the value TRUE.
4. Under the [Info] section, configure the UnattendedServerType setting by typing
the name that matches the server template you want to use. For example, if you
want to apply the dynamicweb template, change UnattendedServerType to equal
dynamicweb.
5. Change the Unattended setting to the value TRUE.
6. Save the iislockd.ini file.
7. Run iislockd.exe from a command line, or from within a script.
250
Disabling Script Mappings
Vulnerability
The IIS-related script mappings are an excellent illustration of the principle that an
increase in functionality can cause a decrease in security. While the script mappings are
very powerful and can provide a great deal of value to a Web site, nearly all of the
mappings have been exploited by security threats at some point since the release of
Windows 2000.
●
The .ida and .idq script mappings are ISAPI extensions that provide extended
functionality for the Index server. Among other vulnerabilities, an unchecked buffer
in the idq.dll file introduced a vulnerability that could allow an attacker to gain
complete control of the server. This vulnerability was most famously exploited by
the Code Red worm. See Microsoft Security Bulletin MS01-033 for further details.
●
The .htw ISAPI filter provides additional functionality to Microsoft Index Server. A
vulnerability in the related webhits.dll file created the potential for a user to
inadvertently open a hostile link through a browser or Hypertext Markup Language
(HTML) compliant e-mail client, which could cause active content such as
Javascript to be executed. See Microsoft Security Bulletin MS01-025 for further
details.
●
The .shtml mapping is the Smart HTML interpreter, which is part of the
Microsoft® FrontPage® Server Extensions used to support server side includes
The ssiinc.dll file contained a vulnerability that could be exploited to return attackerspecified content located on the Web server to the browser. See Microsoft Security
Bulletin MS00-060 for further details.
●
The .idc mapping can be exploited using a cross site scripting vulnerability to
return the entire URL in an error page, allowing attackers to run arbitrary script
code at the server. This issue was resolved in Windows 2000 SP3.
●
The .htr ISAPI extension was a first generation scripting technology available for
ASP developers but never widely adopted. A vulnerability in the ism.dll file could
be exploited to reveal the source code of ASP files. See Microsoft Security
Bulletins MS00-031 and MS01-014 for further details.
●
The .printer ISAPI extension was created for the use of printing over internet
protocols. A vulnerability in msw3prt.dll could be exploited to provide an attacker
with a remote console on the target IIS system. See Microsoft Security Bulletin
MS01-023 for further details.
Countermeasure
All unnecessary mappings and ISAPI filters should be removed from the system.
Unneeded script mappings should be redirected to the 404.dll file. The 404.dll file is an
ISAPI filter that responds with a simple 404 error page to requests that are intercepted by
one of these unused script mappings.
Note: Mapping an unused extension to 404.dll is better than just deleting the mapping.
With a deleted mapping, if a file is mistakenly left on the server (or put there by
mistake) it will be displayed in cleartext when requested, or could be inadvertently remapped.
The related files and folders of each script mapping should also be deleted from the file
system. This is not done by the IISLockdown Tool, but is detailed in the "Virtual Directory
and Sample Applications Removal" section below.
251
Potential Impact
The potential impact of remapping these script mappings would be to disable whatever
functionality those script mappings make available. If Web-based applications require the
script mappings to function, then these applications could be inadvertently disabled.
Contoso Scenario
The IIS Lockdown Tool was used in the Contoso scenario to remove all unnecessary
ISAPI filters from the organization's IIS servers. Only .asp files and static content remain
enabled on the IIS servers. Each script mapping was automatically mapped to the 404.dll
filter.
Performing script mappings to 404.dll can also be done manually for either new
extensions or in case the IIS Lockdown Tool is not used.
XTo manually map extensions to 404.dll
1. Start the Internet Services Manager MMC snap-in.
2. Right-click your server (a.k.a. the Master site) in the left hand window and click
Properties.
3. Ensure that the WWWService is selected in the Master Properties drop down list
box, and click the adjacent Edit button.
4. Click the Home Directory tab.
5. Click Configuration.
6. Select one of the extensions from the list of mappings and then click Edit.
7. Click Browse and navigate to c:\winnt\system32\inetsrv\404.dll.
8. Click Open and then OK.
9. Repeat steps 6, 7 and 8 for all of the remaining file extensions.
Internet Printing
Windows 2000 Server provides the ability to print from the Internet. Printers are attached
to the server by means of a Web page and administration of these printers is also
accessed from a Web page.
Vulnerability
The Internet printing feature increases the attack surface of an IIS server. In addition, if
Internet printing is disabled from the Internet Service Manager, and an administrator
restarts the server or logs out, the GPO that enables Internet printing will restart this
functionality.
It is important to ensure that Internet printing is disabled through a GPO that controls the
server before deploying the server. The default Group Policy neither enables nor disables
Internet printing.
252
Countermeasure
Disable Internet printing through Group Policy using the procedure for the Contoso
scenario.
Alternatively, Internet printing can also be disabled via the Internet Services Manager. If
there is a conflict between the Group Policy settings and those in the Internet Services
Manager, the Group Policy settings take precedence.
If Internet printing is removed via the Internet Services Manager, verify that it will not be
re-enabled by either the local or domain Group Policies. See the Contoso scenario
procedure for the details on how to do this.
Potential Impact
Any clients printing to printers shared from that IIS server via the Internet Printing
Protocol (IPP) would lose the ability to use IPP to print from Web-shared printers.
Contoso Scenario
The IIS Lockdown Tool was used in Contoso's environment to disable Internet printing.
No printers are shared from the IIS servers.
XTo disable Internet Printing using Group Policy
1. Start Active Directory Users and Computers as a user with permission to edit
the GPO in which you will disable IPP.
2. Right-click the OU where the GPO is stored and choose Properties.
3. Select the Group Policy tab, click the GPO to be edited, and then click the Edit
button.
4. Double-click the Computer Configuration folder, then Administrative
Templates, and Printers.
5. Double-click the Web-based Printing setting, select the Disabled radio button and
click OK.
Virtual Directory and Sample Applications Removal
Vulnerability
IIS 5.0 included a number of sample applications that are not installed by default, but that
are available as part of the full installation of IIS. In addition, several virtual directories
were included in IIS 5.0 that contain samples IIS applications.
The sample applications that were included in the default installation of IIS 5.0 were not
developed to be hosted on high-security production IIS servers. It is possible that a
hacker could exploit an inherent weakness in a sample application or in its configuration
to attack a Web site. By removing the sample applications, the attack surface of the Web
server can be decreased.
In addition, the virtual directories themselves are not configured for high security. For
example, the default \Scripts directory provides anyone with the ability to run programs in
this directory and potentially others.
253
Countermeasure
The virtual directories should be removed from IIS either manually or with the IIS
Lockdown Tool. The underlying files and folders of the virtual directories also should be
manually deleted.
XTo delete a sample application
1. Use the IIS MMC snap-in to delete the appropriate virtual directory.
2. Use Windows Explorer to physically delete the underlying folder.
XTo delete the remote IIS administration application
1. Use the IIS MMC snap-in to stop the administration Web site.
2. Use the snap-in to delete the virtual directory.
3. Use Windows Explorer to physically delete the underlying folder.
Potential Impact
There should be no impact, unless for some unlikely reason you have employed one of
the sample applications in a production environment.
Contoso Scenario
The IIS Lockdown tool was used in the Contoso scenario to remove all sample virtual
directories.
The sample applications and other unnecessary files were deleted manually, including
the following directories:
●
C:\inetpub\scripts
●
C:\inetpub\iissamples
●
C:\Program Files\Common files\system\msadc
●
C:\winnt\help\iishelp
●
C:\Winnt\system32\inetsrv\iisadmin
File Permissions Lockdown of IIS Users
Vulnerability
After gaining unauthorized access to a system, it may be possible for a hacker to utilize
system commands to perform actions or view data on a remote Web server. Using these
same system commands, an attacker could upload and execute additional applications
on the server.
254
Countermeasure
Perform the following two countermeasures:
●
Add an Access Control Entry (ACE) to all executable files in C:\WINNT and all
subfolders (that is, add the ACE to the existing ACL). The ACE should deny
execute privileges to all anonymous user accounts that have been configured on
the computer (including IUSR_computername), as well as all user accounts on the
server that are used for running Web applications (including
IWAM_computername).
●
Add an ACE to the existing ACL on all files and folders referenced by virtual
directories, and include the files and folders that are located on remote
computers. The ACE should deny write privileges to all anonymous user accounts
that have been configured on the computer (including IUSR_computername), as
well as all user accounts on the server that are used for running Web applications
(including IWAM_computername).
Both of these actions can be performed automatically with the IIS Lockdown Tool.
Potential Impact
No Microsoft Web applications would experience any impact from the countermeasures
above, but it is possible that a custom application relies on the permissions that have
been denied. All custom applications should be tested in a lab environment after these
changes before making the same changes on production IIS servers.
Contoso Scenario
The IIS Lockdown Tool was used in the Contoso scenario to configure the necessary
Deny ACE settings on the specified files and directories.
Disable WebDAV
Vulnerability
A vulnerability of WebDAV is that it could be exploited to run a script that would execute
in the current security context of the WebDAV thread. This means that an attacker could
browse inside the intranet of your organization and potentially access restricted
information that is only available to the WebDAV service account. See Microsoft Security
Bulletin MS01-022 for further details.
Countermeasure
Disable this WebDAV feature. Configure an ACE on the DLL that implements WebDAV
functionality (Httpext.Dll) to prevent the DLL from being loaded into the IIS process.
The IIS Lockdown Tool can perform this task automatically.
Certain applications such as Exchange 2000 and Microsoft® SharePoint™ Portal Server
2001 require WebDAV for functionality within the product. In these cases it is best to
apply the latest service pack to ensure that the WebDAV functionality is fully patched.
Potential Impact
Any applications reliant on WebDAV would be disabled by this action. Test all Web
applications that you believe may contain WebDAV functionality in a lab environment
after making these changes and before making the same changes on the production IIS
servers in your environment.
255
Contoso Scenario
The IIS Lockdown Tool was used in the Contoso scenario to remove the WebDAV
functionality from all servers, since there were no WebDAV applications deployed.
URLScan
URLScan is an ISAPI filter that is either installed when you run the IIS Lockdown Tool or
is installed separately by extracting the files from the IIS Lockdown Tool. URLScan allows
Web site administrators to restrict the kind of HTTP requests that the server will process.
By blocking specific HTTP requests, the URLScan filter prevents potentially harmful
requests from reaching the server and causing damage.
Overview
URLScan blocks many types of unusual or potentially malicious HTTP requests,
especially those that contain characters that have been used to exploit vulnerabilities in
the past, such as "..", which is used for directory traversal attacks. These requests will be
logged in the %systemroot%\system32\inetsrv\urlscan directory.
Even if a legitimate Web application URL includes any of these characters in the path,
URLScan will reject the request and a 404 Not Found error response will be returned to
the client. If these characters must be allowed to support your Web application, set the
AllowDotInPath parameter to the value 1 in the urlscan.ini configuration file (located in
%systemroot%\system32\inetsrv\urlscan\ folder). It is important to realize that altering the
default character set allowed by URLScan may reduce the security of the system.
URLScan Configuration
The majority of the configuration for URLScan is performed through manipulation of the
URLScan.ini file that is located in the %systemroot%\system32\inetsrv\urlscan directory.
This file contains several sections of parameters that are listed below.
256
Options
The Options section of the urlscan.ini file contains 16 settings that URLScan uses. Some
of these settings refer to configurations for subsettings in the urlscan.ini file. These
settings are:
●
UseAllowVerbs
●
UseAllowExtensions
●
NormalizeUrlBeforeScan
●
VerifyNormalization
●
AllowHighBitCharacters
●
AllowDotInPath
●
RemoveServerHeader
●
AlternateServerName
●
EnableLogging
●
PerProcessLogging
●
PerDayLogging
●
LogLongUrls
●
LoggingDirectory
●
AllowLateScanning
●
RejectResponseUrl
●
UseFastPathReject.
Most of these settings are either configured to 1 (true) or 0 (false). There are a few that
require further configuration, which is detailed below. For more information, see
Knowledge Base article Q326444, "How TO: Configure the URLScan Tool."
Allow Verbs and Deny Verbs
Verbs are a critical component of HTTP requests. GET and HEAD are the most common
verbs used by Web browsers for simple browsing. For example, a Web browser will use a
GET command to retrieve information from the specified URL.
Browsers can use other verbs, such as PUT, POST, and REPLY to modify Web site
content. For example, FrontPage Server Extensions utilize the POST and OPTIONS
verbs to publish Web content.
The UseAllowVerbs setting in the options section determines if the Allow Verbs section of
the .ini file will be processed. If the value for UseAllowVerbs is set to 1, URLScan will only
examine the AllowVerbs section and ignore the DenyVerbs portion of the .ini file.
If the value for UseAllowVerbs is set to 0, URLScan looks at the DenyVerbs section and
ignores any entry in AllowVerbs. IIS is most secure when all HTTP verbs are denied and
only specific exceptions are listed, which is the default setting for URLScan
(UseAllowVerbs = 1).
This feature is useful to restrict the activities you want to allow users to perform on your
Web site.
257
Allow Extensions and Deny Extensions
The AllowExtensions and DenyExtensions portions of the URLScan.ini file work like the
AllowVerbs and DenyVerbs sections. However, these areas of the urlscan.ini file control
the specific file extensions that incoming requests are permitted to access.
This setting allows administrators to enable access to common Web file types but to deny
users the ability to run any executable or script files.
The most secure setting is to set UseAllowExtensions to 1 and list the permitted
extensions in the AllowExtensions section. This configuration will block all other
extensions. The default setting is UseAllowExtensions = 0, which only denies specified
extensions.
Deny Headers
The DenyHeaders portion of the file lets you specify which client request headers
URLScan will permit or deny. For example, this section could be used to deny the
Translate: header, which enables a specific vulnerability to be exploited in a version of IIS
5.0 that has not been patched.
URLScan Implementation
Vulnerability
URLScan addresses a list of vulnerabilities that is too large to discuss in detail in this
section. However, one of the most common vulnerabilities that it addresses is IIS file
system traversal. In the Contoso scenario, this was identified as one of the most
significant risks in their environment.
File System traversal can allow an attacker to view not only the file system layout on an
IIS server, but also to potentially view data within the files or gain unauthorized access to
the server. This could even lead to an attacker gaining the ability to execute commands
remotely on the machine.
Countermeasure
The primary countermeasure for this vulnerability is to move the directories that contain
the virtual server roots to a drive other than the system drive. There is currently no
known way for a hacker to traverse across system partitions to execute commands. By
moving the Web application data files to a drive where no system command executables
exist, the attacker would be restricted from performing such actions.
Alternatively, URLScan can be implemented to restrict the special characters that will be
allowed in requested URLs. URLScan has the ability to specify the normalization of the
URL before it is processed. This eliminates many of the most common file system
traversal exploits.
Potential Impact
There is no known impact to Microsoft applications by installing their data files to
nonsystem drives. However, custom applications may encounter unexpected problems if
their files are installed in nondefault locations. Most applications require some additional
reconfiguration if their files are moved after installation as well.
All applications should be thoroughly tested in a lab environment after making these
changes before making the same changes on production IIS servers.
258
Contoso Scenario
In the Contoso scenario, the inetpub directories and all virtual directories were installed
on disk partitions other than the system partition.
Contoso also implemented URLScan to limit the URLs and executables that were
allowed to be executed on the system.
Incremental IIS Group Policy
The baseline security policy discussed in Chapter 6, "Hardening the Base Windows 2000
Server," ensures that the servers are significantly more secure than after a default
installation. However, as with the other server roles, additional settings are required to
add some functionality to the server role while increasing the security for other aspects of
the computer.
System Services
The IIS server role adds Web server functionality to the baseline Windows 2000 server
policy. No matter what other services are being hosted on an IIS Server, the following two
services must be enabled to support any Web server functionality. The IISAdmin service
is necessary not just to administer IIS Web sites, but also because this service actually is
the initial contact point for all Web-related traffic on an IIS server. Thus disabling this
service would disable all Web sites, FTP, SMTP, and NNTP in your environment.
These services have been enabled in the Incremental IIS Policy.
Table 7.10: Incremental IIS Policy Service Settings
Service Setting
Startup Type
Policy Justification
IISAdmin
Automatic
Administration of the Web Server
W3SVC
Automatic
Provides Web Server functionality
Manual Security Configuration
In addition to the Incremental IIS Policy, there are some remediation steps that must be
implemented manually. These include the following:
●
Relocating the Web content directories.
●
Relocating and securing log files.
●
Hardening Metabase permissions.
●
Disabling content location in HTTP response.
●
Disabling detailed ASP error messages.
●
Removing FrontPage 2000 server extensions.
●
Deleting additional virtual servers.
●
Configuring IPSec Filters.
259
Relocating the Web Content Directories
Vulnerability
IIS in its default installation has historically been vulnerable to directory traversals. A
directory traversal occurs when an attacker escapes the Web root folder and requests or
uploads files outside of the Web folders. When IIS applications are vulnerable to directory
traversal, the default IIS installation allows attackers to access folders and files in the
system partition, including many useful system commands and writeable folders.
There is no method using known HTTP syntax to request files across system partitions.
Countermeasure
To prevent directory traversal attacks from succeeding, relocate the \inetpub directory
and all virtual directories to a drive partition other than the system partition.
This step will ensure that an attacker is not able to access even basic system commands
such as cmd.exe if the attacker is exploiting an unforeseen canonicalization issue, and
could not write to any writeable folders on the system partition, for example, the
\inetpub\Scripts folder.
Potential Impact
Minimal. The Web server administrator must ensure that the configuration of IIS is
recorded to ensure that the virtual sites are re-registered in the new location.
Contoso Scenario
The Contoso Research Web site was used to provide an example for this. The Web site
virtual root was C:\Inetpub\wwwroot\research on the Research Web server. To move its
files to a nonsystem partition such as E:, the following steps were performed:
XTo move all content directories of the Research Web site:
1. Start the IIS MMC snap-in.
2. Right-click the Web site and choose Stop. (This will unlock any locked files.)
3. Start a command prompt.
4. Type the following command: xcopy c:\inetpub\wwwroot\research
d:\wwwroot\research /s /i /o
5. Go back to IIS MMC snap-in.
6. Right-click the Web site and choose Properties.
7. Click the Home Directory tab, then click the Browse button, and choose the new
directory to which the files were just copied (for example, d:\wwwroot\research).
8. Right-click the Web site and choose Start.
260
Relocating and Securing the Log Files
Vulnerability
Moving and securing the IIS log files can make it much more difficult for attackers to
cover their tracks by deleting these logs or individual entries in the logs.
Countermeasure
Relocate the IIS log file directory to a different disk partition from the Web site data files
and the system partition. Then, set stronger NTFS permissions to better secure the log
files. Finally, ensure that the recommended logging fields are configured.
Additional Log File options:
●
In order to facilitate the offline analysis of IIS log files, you could use a script to
automate secure removal of log files from each IIS server. Log files should be
removed at least every 24 hours and placed on a central server.
●
An automated script may be created to use the FTP, SMTP, HTTP, or SMB
protocols to transfer log files off a machine, but this must be done securely to
prevent opening any additional attack opportunities. An IPSec policy can be used
to secure ports and allowed hosts for these protocols.
●
The IIS log files could be stored on CD-R, using modern CD-RW drives with the
ability to write multiple times to the same media. This would enable you to log IIS
entries to a storage location that cannot be deleted after it has been written. Thus,
attackers would not be able to cover their tracks.
●
The IIS log files could also be stored on a central Universal Naming Convention
(UNC) share (for example, the Log file directory could be \\server\share\iislogs
rather than %Windir%\system32\logfiles). This would enable you to back up these
log files daily from one central repository.
●
Finally, the IIS log entries could be stored in a database that is compliant with
Open Database Connectivity (ODBC). This would allow you to store the IIS log
entries in a central location, in which more granular permissions could be enabled
(for example, read/write, but not delete). The log entries would already be stored in
a format that is ideal for analysis.
Potential Impact
None.
Contoso Scenario
The IIS log files on the Contoso Web servers were moved to a nonsystem partition in
which secured and extended logging was enabled.
261
XTo move the location of the IIS log files to a nonsystem partition
1. Start the IIS MMC snap-in.
2. Right-click the Web site and choose Properties.
3. Click the Properties button in the Enable Logging frame on the Web Site tab.
4. On the General Properties tab, click the Browse button, and select the drive and
folder where you want to store the IIS log files (for example, E:\IISLogs).
Note: Ensure you have already created the folder in order to select it as part of this
step.
5. Click OK, then OK again.
Note: If you already have IIS log files in the original location
(%Windir%\System32\logfiles), you must move these files to the new location
manually. IIS will not automatically move those files for you.
XTo set recommended permissions on the IIS log files location (for example,
E:\IISLogs)
1. Open a command prompt.
2. Type the following command: cacls e:\iislogs /t /g administrators:F system:F
3. When prompted, type Y to proceed.
XTo configure IIS W3C Extended Log File Format auditing:
1. Start the IIS Manager MMC snap-in.
2. Right-click your server in the left hand window and click Properties.
3. Ensure that WWWService is selected in the Master Properties drop down list
box, and click the adjacent Edit button.
4. Select Enable Logging and ensure the Active log format drop down list box is
set to W3C Extended Log File Format.
5. Click Properties.
6. Select the When file size reaches radio button and specify a log file size of 500
MB.
7. Change the default Log file directory. It is recommended to use a different
nonsystem partition from your Web sites.
8. Click the Extended Properties tab.
9. In addition to the default fields selected by IIS, also select the Win32 status entry.
10. Click OK three times to close the properties dialog list boxes.
Note: Such auditing does not prevent system attacks, but it is a vital aid in
identifying intruders, attacks in progress, and for diagnosing attack footprints.
262
Hardening Metabase Permissions
Vulnerability
Security and other IIS configuration settings are maintained in the IIS metabase file. The
default file permissions could allow an attacker to directly edit the metabase file. The
NTFS permissions on the IIS metabase file (and the backup metabase file) should be
hardened to ensure that attackers cannot modify the IIS configuration in any way. For
example, an attacker might attempt to disable authentication for a particular virtual
directory by modifying appropriate metabase settings.
Countermeasure
Secure the metabase files so that Full Control permissions are granted only to
Administrators and SYSTEM.
Potential Impact
The only potential impact would be in setting permissions on the metabase files that are
too restrictive, which would prevent the system or administrators from reading and
updating the file.
Contoso Scenario
The IIS Incremental Policy was applied to secure the metabase files, in which the
appropriate metabase file permissions were stored.
XTo manually harden metabase NTFS permissions
1. Open a command prompt.
2. Type the following command: cacls
%systemroot%\system32\inetsrv\metabase.bin /g administrators:F system:F.
3. When prompted, type Y to proceed.
4. Type the following command: cacls %systemroot%\system32\inetsrv\metaback
/g administrators:F system:F.
5. When prompted, type Y to proceed.
These settings are included in the MSS IIS Role.inf policy template with this guide.
263
Disabling Content Location in HTTP Response
Vulnerability
When a static .HTML page, that is a non–ASP page, is retrieved, a content location
header is added to the response by IIS. By default, this content header refers to the IP
address, and not the fully qualified domain name (FQDN) of the current Web site. This
creates a vulnerability in which your internal IP address is unwittingly exposed.
Countermeasure
Hide the content location returned by default in the HTTP Response Headers. This can
be done by modifying the UseHostName value in the IIS metabase to change the default
behavior from exposing IP addresses to sending the FQDN instead.
Potential Impact
None.
Contoso Scenario
In the Contoso scenario, the UseHostName setting was reconfigured to the value True
using the Adsutil.vbs script. The syntax for performing this step is:
cscript Adsutil.vbs set w3svc/UseHostName True
The ADSUtil.vbs script can be found in the IIS Adminscripts directory on the IIS server,
which is by default C:\Inetpub\Adminscripts.
Note: For more information about the manual process required for this step, see
Knowledge Base article Q218180, "Internet Information Server Returns IP Address in
HTTP Header (Content-Location)."
Disabling Detailed ASP Error Messages
Vulnerability
By default, IIS sends detailed ASP error messages to the client browser whenever there
are internal application errors. While this is very helpful for application debugging, it can
expose internal details of how the application works, giving an attacker a better
understanding of how to attack the application.
Countermeasure
Disable detailed ASP error messages on the production IIS servers in your
environment.
Potential Impact
Responding to issues of the Web applications can be more difficult, since the errors that
IIS logs in the Application event log are not nearly as informative as the detailed ASP
error messages. If you are experiencing reproducible ASP errors, there are two
alternatives: set up a mirror development environment to test fixes (and configure
detailed ASP error messages in that environment), or enable detailed ASP error
messages in production for a temporary period while you resolve the issue.
264
Contoso Scenario
The production IIS servers in Research and HR were reconfigured to disable detailed
ASP error messages using the adsutil.vbs script parameters detailed below.
XTo disable detailed ASP error messages
1. Start the Internet Services Manager MMC snap-in.
2. Right-click your server (a.k.a. the Master site) in the left hand window and click
Properties.
3. Ensure that the WWWService is selected in the Master Properties drop down list
box and then click the adjacent Edit button.
4. Click the Home Directory tab.
5. Click Configuration.
6. Select one of the extensions from the list and then click Edit.
7. Click Browse and navigate to c:\winnt\system32\inetsrv\404.dll
8. Click Open and then OK.
9. Repeat steps 6, 7 and 8 for all of the remaining file extensions.
Alternatively, this process can be completed by using the Adsutil.vbs script. The syntax
for performing this step is:
cscript Adsutil.vbs set w3svc/AspScriptErrorSentToBrowser False
Removing FrontPage 2000 Server Extensions
Vulnerability
FrontPage 2000 server extensions provide convenient methods to collaborate among
teams of Office users and to remotely manipulate Web page content. These remote
management capabilities are not generally necessary for Web sites with only one
administrator, and the extensions can be used as a point of attack on Web sites by skilled
attackers.
Countermeasure
Disable FrontPage 2000 server extensions on all production IIS servers.
Potential Impact
If you have a need to delegate the management of certain virtual Web sites to nonadministrator staff, then you may require FrontPage 2000 server extensions. In this case,
make absolutely sure that you have deployed all current FrontPage 2000 server
extension hotfixes to the IIS Web servers.
265
Contoso Scenario
In the Contoso environment, the IIS Web sites were all administered by small teams of IT
staff. The teams had the ability to use the Internet Services Manager MMC snap-in either
at the console, via Terminal Services, or over the network. Thus, FrontPage 2000 server
extensions were disabled manually on all production IIS servers.
XTo manually remove FrontPage 2000 server extensions
1. Start the Add/Remove Programs applet, then select Add/Remove Windows
Components.
2. Select Internet Information Services (IIS) and click the Details button.
3. Clear the FrontPage 2000 Server Extensions checkbox, click OK, and then click
Next.
4. If the Terminal Services Setup dialog box appears, click Next.
– Or –
If the Files Needed dialog box appears, Browse to the location from which you
originally installed Windows 2000, and click OK.
5. When prompted, click Finish.
6. If necessary, delete the FrontPage server directories including:
●
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\40
●
C:\Inetpub\wwwroot\_private
●
C:\Inetpub\wwwroot\_vti_cnf
●
C:\Inetpub\wwwroot\_vti_log
●
C:\Inetpub\wwwroot\_vti_pvt
●
C:\Inetpub\wwwroot\_vti_script
Deleting Additional Virtual Servers
Vulnerability
The default installation of IIS creates Default FTP Site, Default Web Site, and
Administration Web Site. These sites often contain sample code, and are also a potential
site from which to launch remote attacks that would require an unsecured instance of
these services. When they are not required for your production environment, it is a best
practice to remove or disable these default sites.
Countermeasure
Remove the Default FTP Site and the Administration Web Site, and stop the Default
Web Site from responding to Web requests.
Potential Impact
You may have installed certain Web applications in one of the default Web sites. Before
deleting these sites, ensure that you have migrated these applications to new Web sites
on the IIS Web server. If you cannot delete these sites for some reason, you should at
least delete the sample code from these Web sites. Use the IISLockdown Tool to do this.
266
Contoso Scenario
In the Contoso environment, the default Web sites were not necessary to support any
production functionality — each of the production Web sites were installed into new virtual
Web sites. Thus the default sites were deleted or stopped.
XTo manually remove the Default FTP Site
1. Start the Internet Services Manager MMC snap-in.
2. Right-click the Default FTP Site, choose Delete, and click Yes.
XTo manually remove the Administration Web Site
1. Start the Internet Services Manager MMC snap-in.
2. Right-click the Administration Web site, choose Delete, and click Yes.
XTo manually stop the Default Web Site
1. Start the Internet Services Manager MMC snap-in.
2. Right-click the Default Web Site and choose Stop.
Additional IIS Server Setting Considerations
Disable the IUSR Account
As part of the default IIS installation, a Windows account used to represent anonymous
Internet users called IUSR_MACHINE is created. MACHINE is the NetBIOS name of
your server when IIS is installed. If you do not allow anonymous access to your Web site,
then you should disable this Anonymous user account.
Anonymous access can be granted with any other account, not just this one — this
account just happens to be the one created by default when IIS is installed. Conversely,
disabling or removing this account does not remove Anonymous access capabilities from
IIS, because IIS can be configured to use any other account to provide anonymous
access to Web users.
This account is used by the majority of public Web sites where either anonymous access
to content is supported, or where the application performs its own authentication by using
Forms authentication for example.
Note: If your Web server hosts multiple Web applications, you may want to use
multiple anonymous accounts (one per application) to secure and audit the operations
of each application independently.
Conduct Regular Group Membership Audits
Keep track of user group membership, particularly for privileged groups such as
Administrators. The number of members of the Administrators group should be kept to a
minimum, and individuals — particularly new recruits — should be fully trained prior to
being added to the Administrators group.
267
Additional Recommendations for Securing Users and Groups
●
Create specific groups for specific administrative tasks, and:
●
Catalog authorized members of privileged groups such as Server Operators.
●
Periodically monitor group membership.
●
Apply strict hiring policies and interviews before adding anyone to the
administrators group.
Disable ASP Parent Paths Setting
This IIS metabase setting prevents the use of ".." (two periods) in script and application
calls to functions such as MapPath. This helps guard against potential directory traversal
attacks.
XTo manually disable the parent paths setting
1. Right-click the root of the Web site that you want to secure, and click Properties.
2. Click the Home Directory tab.
3. Click Configuration.
4. Click the App Options tab.
5. Clear the Enable parent paths checkbox.
Note: If you are using the Application Center 2002 Admin Site, refer to Knowledge
Base article Q288309, "PRB: Disabling Parent Paths Breaks User Interface."
Blocking Ports with IPSec Filters
Vulnerability
As mentioned previously, reducing the number of ports that are open and actively
listening on the servers in your organization will greatly reduce the attack surface of each
machine. Open ports can provide an attacker with a launching pad to attack another
server in the organization — for example, a worm and Trojan horse may install
applications that bind to unauthorized ports on the server and listen for incoming
commands.
268
Countermeasure
Configure IPSec blocking filters that allow only the network traffic specified below. This
will reduce the number of unexpected and unauthorized applications that could
successfully receive requests or that could be attacked.
Before implementing IPSec filters, you must have a full understanding of the capabilities
and limitations of this technology. IPSec filters are very powerful, but can greatly impact
the management and usability of systems. For more information, refer to Chapter 11 of
Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows
XP at http://go.microsoft.com/fwlink/?LinkId=15159.
Incremental IIS Server IPSec Network Traffic Map
Table 7.11: Incremental IIS Server IPSec Network Traffic Map
Service
Protocol
Source
Port
Destination
Port
Source
Address
Destination
Address
Domain
Member
ANY
ANY
ANY
0
ALL DC's
Action
ALLOW
Monitoring
Client
ANY
ANY
ANY
0
MOM Server
ALLOW
Terminal
Services
TCP
ANY
3389
ANY
0
ALLOW
HTTP
Server
TCP
ANY
80
ANY
Host IP
ALLOW
HTTPS
Server
TCP
ANY
443
ANY
Host IP
ALLOW
ICMP
ICMP
ANY
ANY
0
ANY
ALLOW
All Inbound
Traffic
ANY
ANY
ANY
ANY
0
BLOCK
All rules listed above should be mirrored when they are implemented. This ensures that
any traffic coming in to the server will also be allowed to return to the originating server.
As seen above, there are a small number of ports and services that have been opened
on the IIS server. With this additional level of security, all IIS management and
management of the servers will need to be performed through the use of Terminal
Services.
Also note that Contoso has implemented a MOM server in their environment. Because of
the large interaction between the MOM server and the OnePoint client – the client
application that reports to the MOM console – all network traffic is allowed between the
server and the MOM server.
269
Scripting Commands
Implementation of the following commands should be executed on the server. These
commands will block all network traffic except what is specifically allowed.
This set of commands is also included in a batch file that accompanies this guide.
ipsecpol -w REG -p "Packet Filter" -r "Domain Member"
-f 0+<INSERT DC IP>:: -f 0+<INSERT DC IP>::
-f 0+<INSERT DC IP AND REPEAT AS NECESSARY>:: -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring"
-f 0+<INSERT MOM SERVER IP> -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"
-f *+0:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "HTTP Server"
-f *+0:80:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "HTTPS Server"
-f *+0:443:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP" -f 0+*:*:ICMP
-f *+0:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"
-f *+0 -n BLOCK
ipsecpol -w REG -p "Packet Filter" -x
Potential Impact
Because these settings do not allow traffic through random high ports, RPC traffic will not
be allowed. This can make management of the server difficult. Administrators should be
able to connect with a Terminal Services client to perform remote administration.
These policies still allow any necessary authentication network traffic to work on any Web
sites that require basic or NTLM authentication.
The implementation of this relatively small number of IPSec policies should not have a
noticeable impact in the performance of the server. However, thorough testing should be
performed before implementing these filters in your environment to verify necessary
functionality and performance. Additional rules may need to be added to support other
applications in your environment.
Contoso Scenario
In the Contoso scenario, the IPSec filters were implemented as specified above for their
IIS servers.
270
General IIS Best Practices
The following is a set of general best practices for implementing and securing IIS Server:
●
Do not install IIS on a domain controller.
●
Do not connect an IIS Server to the network until it has been fully patched and
hardened as much as possible, except for Group Policy changes (that must come
from the domain controllers on your network).
●
Use a dedicated machine as a Web server.
●
Physically protect the Web server machine in a secure machine room.
●
Do not allow anyone to locally log on to the machine apart from the administrator.
●
Do not allow administrators to log on to the machine over the network. Adopt a
policy of local administration.
271
Summary
This chapter explains the server hardening procedures applied to each of the separate
server roles in the Contoso scenario. Most of these procedures were accomplished by
creating a variety of security templates and then importing them into a Group Policy
object (GPO) linked to the appropriate organizational unit (OU) for each server role.
Some hardening procedures could not be applied through Group Policy. In these cases,
details on configuring the procedures manually have been provided.
Now that you have secured your Windows 2000 servers for deployment, your next step is
to determine how to continue to apply security patches in your organization's
environment, how to monitor the security of your systems, and how to respond to security
incidents that may involve the servers in the future.
More Information
For information about the Microsoft Systems Architecture: Enterprise Data Center
prescriptive architecture guides see:
http://www.microsoft.com/technet/itsolutions/edc/default.asp
For information about enabling anonymous access to Active Directory, see Knowledge
Base article Q257988, "Description of Dcpromo Permissions Choices."
For information about Windows NT 4.0 RAS, RRAS, and Active Directory, see
Knowledge Base article Q254311, "Enable Windows NT 4.0-Based RAS Servers in a
Windows 2000-Based Domain."
For information about Windows 2000 DNS, see the "Windows 2000 DNS White Paper"
at:
http://www.microsoft.com/windows2000/techinfo/howitworks/communications/
nameadrmgmt/w2kdns.asp
For more information about Windows 2000 DNS, see Chapter 6 of the online version of
"TCP/IP Core Networking Guide" at:
http://www.microsoft.com/windows2000/techinfo/reskit/samplechapters/cncf/
cncf_imp_vsin.asp
For information about the 80/20 Rule Model for DHCP, see:
http://www.microsoft.com/windows2000/techinfo/reskit/en-us/cnet/cncb_dhc_ogjw.asp
For information about the IIS Lockdown Tool version 2.1 that includes information about
URLScan, see: http://www.microsoft.com/technet/security/tools/tools/locktool.asp
For information about IIS 5.0, see the white paper "From Blueprint to Fortress: A Guide to
Securing IIS 5.0" at:
http://www.microsoft.com/technet/prodtechnol/iis/deploy/depovg/securiis.asp
For information about managing security for IIS Web services, see "Manage Security of
Your Windows IIS Web Services," at:
http://www.microsoft.com/technet/security/bestprac/mcswebbp.asp
272
For information about a checklist for securing IIS services, see the "Secure Internet
Information Services 5 Checklist" at:
http://www.microsoft.com/technet/security/tools/chklist/iis5chk.asp
For information about the IIS 5.0 Baseline Security Checklist, which is a subset of the
Secure IIS 5 Checklist, see:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/chklist/
iis5cl.asp
For information about setting appropriate file system permissions for IIS content and log
files, see Knowledge Base article Q310361, "HOW TO: Set Secure NTFS Permissions on
IIS 5.0 Log Files and Virtual."
For information about Advanced Programmatic Administration for IIS 5.1, see:
http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/abgu26y6.asp
For information about SYN attack protections, see the Knowledge Base article Q315669,
"HOW TO: Harden the TCP/IP Stack Against Denial of Service Attacks in Windows
2000":
For more information about securing and maintaining IIS, see the IIS Answers site at:
http://www.iisanswers.com
273
8
Patch Management
Operating systems and applications are often immensely complex. They can consist of
millions of lines of code, written by many different programmers. For these reasons, it is
essential that the software works reliably and does not compromise the security or
stability of your information technology (IT) environment. To minimize any problems,
programs are tested thoroughly before release. However, attackers continually strive to
find weaknesses in software, making it impossible to comprehensively anticipate all
attacks in the future.
Software companies release patches to resolve weaknesses in code or implementation
that become apparent after the release of the product. A patch is a piece of object code
that is inserted in an executable program as a temporary fix of a bug.
Increasingly, these problems are security related; as the number of attacks increase, the
methods of attackers become more sophisticated, and new malicious code — executable
code that either intentionally or unintentionally causes damage to a new work
environment — is created to take advantage of security vulnerabilities. However,
deploying patches can also be simply related to adding functionality to a product that is
desirable.
Security patch management presents a specific challenge to most organizations. Once a
weakness has been exposed in software, attackers will generally spread information
about it quickly throughout their community. Software companies strive to release a
security patch to address the vulnerability as soon as possible. But until you deploy the
patch, the security that you depend on and expect may be severely compromised.
Whether your company has thousands of computers or just a few, managing all available
patches, determining which are relevant to your environment, and evaluating how much
testing you can afford to do before deploying them can be a difficult and time consuming
task. After applying the latest service pack available for Microsoft® Windows® 2000
(Service Pack 3) on all of the Contoso systems, we examined each server to see what
hotfixes were available and installed those as well. We found that all of the servers
required the same handful of patches, but that there were a few additional ones
specifically for Internet Information Service (IIS) that we only installed on the Web
servers.
This chapter is designed to help you keep your Windows 2000-based servers secure, but
the processes described here can also be applied to your patch management processes
for all software updates. You should contact specific manufacturers for details on how
they deploy updates to their software.
275
Terminology
In this guide, the terms patch, service pack, and hotfix are used interchangeably to mean
changes to software after its release. This is because the process for deploying them is
the same in each case. However, each term has the following more specific definitions.
Service Packs
Service packs keep the product current, correct known problems, and may also extend
the functionality of your computer network. They are conveniently packaged for easy
downloading and include tools, drivers, and updates, including enhancements developed
after the product is released.
Service packs are product specific, so there are separate service packs for each product.
However, the same service pack will generally be used for different versions of the same
product. For example, the same service pack is used to update Windows 2000 Server
and Windows 2000 Professional.
Service packs are also cumulative — each new service pack contains all of the fixes in
previous service packs, as well as any new fixes and system modifications that have
been recommended since. You do not need to install a previous service pack before you
install the latest one. Service packs may also contain a limited number of customer
requested design changes or features, and because they are broadly distributed, they are
tested heavily.
Hotfixes or QFEs
Quick Fix Engineering (QFE ) is a team within Microsoft that produces hotfixes — code
patches for products. Most of these teams now refer to themselves as Sustained
Engineering teams. Hotfixes or QFEs are provided to individual customers when they
experience critical problems for which no feasible workaround is available. Occasionally
you will see technical documentation refer to hotfixes as QFEs.
Hotfixes do not undergo extensive regression testing and are very issue specific — you
should apply one only if you experience the exact issue that it addresses and are using
the current software version with the latest service pack.
Groups of hotfixes are periodically incorporated into service packs, at which time they
undergo more rigorous testing and are made available to all customers.
Security Patches
Security patches are designed to eliminate security vulnerabilities. Attackers wanting to
break into systems can exploit these vulnerabilities. These are analogous to hotfixes but
are deemed mandatory, if the circumstances match, and need to be deployed quickly.
Many security updates released are for client-side (often browser) issues. They may or
may not be relevant to a server installation. You need to obtain the client patch to update
your current client base and the admin patch to update the client build area on your
server.
276
Patch Management in Your Organization
Exactly how you implement patch management will depend a great deal on the size and
complexity of your organization. However, it is vital that you understand the importance of
patch management and how it fits into the overall risk management strategy for your
company.
For example, if you decide that risk must be minimized at all costs, you could follow a
strategy of shutting down all production systems every time a new vulnerability appears
in your software. You may then choose to not start the systems again until extensive
testing has been done on the security patch and it has been deployed throughout your
organization. This is a very time consuming and expensive process and will be
completely impractical for many organizations.
Throughout the patch management process, you will need to evaluate the risks against
the costs of deploying the appropriate countermeasures. After a security vulnerability has
been disclosed, there may be a short period before a patch is released. You will need to
evaluate the increased risk caused by the vulnerability and determine measures to take
prior to testing and deploying a patch.
These measures may include disabling services, taking systems offline, or restricting
access to internal users or other groups as necessary. Once a patch is released, you
need to determine the risk of deploying it immediately against the cost of keeping
services down or unprotected while you test and make sure that the patch does not
negatively affect the system. If you decide to test, you need to determine how much
testing you can afford to do before the risks of not deploying outweigh those of deploying.
Note: Your organization should implement a change management process. Microsoft
Operations Framework (MOF) includes a change management process that can serve
as this foundation process for your organization. For details on MOF, see the "More
Information" section at the end of this chapter.
277
Assessing Your Current Environment
Often, patches are applied inconsistently throughout an organization, and there is no
documentation on why, when, and where they have been deployed. Before you can
manage the security of your environment properly, you must know in detail its current
state. At a minimum for patch management purposes, you must know:
●
What systems are in your environment, including:
●
Operating systems and their versions.
●
Patch levels in use (service pack versions, hotfixes, and other modifications).
●
Function.
●
Applications in use throughout your environment.
●
Contact information on the individuals or groups responsible for maintaining
each system.
●
What assets are present in your environment and their relative value.
●
What are the known threats, and the processes you have for identifying new ones
or changes in threat level.
●
What are the known vulnerabilities, and the processes you have for identifying new
ones or changes in vulnerability level.
●
What countermeasures have been deployed in your environment.
It is highly recommended that you keep this information available to all those involved in
your patch management process and ensure that it is kept up to date.
Once you know your assets, vulnerabilities, threats, and how your environment is
configured, you can determine and prioritize which of the threats and vulnerabilities are
going to be of concern to your company.
Software Update Service
In many environments, it can be beneficial to have specialized computers from which you
perform many of the steps of the patch management process. These systems provide
specialized locations for storing security tools, patches, hotfixes, service packs, and
documentation. You can use these systems as a place to perform patch analysis,
retrieval, and deployment. In this guide, such systems are referred to as a Software
Update Service (SUS).
You should ensure that your security update systems are on one or more dedicated
computers that can be tightly controlled and secured, as these systems will be used for
deploying and maintaining security patches for all systems in your environment.
Security update systems do not generally need to be high powered servers, as the load
on them will typically be very light. However, high availability is very important, as these
computers will form the basis of keeping your environment up to date with the latest
patches.
To properly deploy a security update system, the computer will need direct or indirect
Internet access to download the latest patch information from trusted sources, as well as
access to each computer that it is responsible for keeping current.
Examples and sample scripts that should be run from the SUS are provided later in this
chapter.
Note: MOF discusses update systems as part of the release management process.
278
Communication
If your company is small, then only one person may need to be put in charge of keeping
patches up to date, testing and installing them, and reading the various log files that they
generate. However, in larger environments there will generally be several people in
charge of different aspects of security patch management.
It is very important that all those involved in patch management communicate effectively.
This will help ensure that decisions are made without duplicating effort, and that no steps
of the process are missed.
Patch Management and Change Management
Patch management is really just a subset of change management. If you already have a
change management procedure in your organization, you will not have to create an
entirely new process for patch management. This chapter provides information specific to
the patch management process that can be used to greatly improve your existing change
management process.
A good change control procedure has an identified owner, a path for customer input, an
audit trail to account for all changes, a clear announcement and review period, testing
procedures, and a well understood rollback plan.
Microsoft Security Tool Kit
The Microsoft Security Tool Kit can be useful when it comes to obtaining the service
packs and hotfixes needed to keep your servers current. The toolkit contains important
security information, current service packs, critical security patches for Microsoft®
Windows NT® version 4.0, Windows 2000, Internet Information Services (IIS), and
Microsoft® Internet Explorer. It also includes the Critical Update notification tool. This tool
ties back to the Windows Update site to ensure that all the latest patches are installed on
your computers. The Security Tool Kit is available from TechNet.
279
Patch Management Process
The patch management process is represented in the following flowchart.
Figure 8.1
Patch management process
280
It is worth examining these steps in more detail:
●
Analyze. Look at the current environment and potential threats. Determine the
patches that you must deploy to reduce the threats to your environment.
●
Plan. Determine which patches should be deployed to deter the potential threats
and vulnerabilities that you have identified. Identify who will perform testing and
deployment and the steps involved.
●
Testing. Review the available patches and categorize them for your environment.
Test all patches that have been identified to make sure that they will work within
your environment without any negative side effects. Understand what the patch
does and how it affects your environment. Verify that it performs as planned.
●
Deploy. Deploy the right patches to make your environment secure.
●
Monitor. Check all systems after deploying patches to make sure that there are no
undesired side effects.
●
Review. As part of the ongoing process, you need to routinely review new patches
that have been released, your environment, and which patches are needed for
your organization. If during the review you find that new patches are needed, start
again at the first step.
Important: It is highly recommended that you back up all production systems prior to
deploying patches.
Analyze Your Environment for Missing Patches
As an ongoing process, you need to ensure that you are up to date on patches. In some
cases, a new patch will be released that you will need to install on all your servers. In
others, a new server brought online will need to be patched appropriately. You should
continue to analyze all of your servers to ensure that they are completely up to date with
all of the latest patches. There are a number of tools that you can use to help you with
this.
Microsoft Baseline Security Analyzer
The Microsoft Baseline Security Analyzer (MBSA) has been designed to scan computers
that are running Windows NT 4.0, Windows 2000, Windows XP Professional, and
Windows XP Home Edition. The MBSA can be executed from any computer that is
running Windows 2000 Professional, Windows 2000 Server, Windows XP Home, or
Windows XP Professional.
One particularly important element of operating a secure system is staying up to date on
security patches. It is critical to know which patches have been applied to your system
and, more importantly, which have not. The MBSA tool does this by referring to an
Extensible Markup Language (XML) database that Microsoft constantly updates. The
MBSA uses the popular “HFNetChk” tool that Microsoft released in August 2001 to
achieve this goal.
The XML file contains information about which hotfixes are available for each Microsoft
product. This file contains security bulletin name and title and detailed data about
product-specific security hotfixes, including files in each hotfix package and their file
versions and checksums, registry keys that were applied by the hotfix installation
package, information about which patches supersede other patches, related Microsoft
Knowledge Base article numbers, and much more.
281
When you run the MBSA tool for the first time, the tool must obtain a copy of this XML file
so that it can find the hotfixes that are available for each product. The XML file is
available on the Microsoft Download Center Web site in compressed form (digitally
signed .cab file). MBSA downloads the .cab file, verifies the signature, and then
decompresses the .cab file to the local computer on which MBSA is running. Note that a
.cab file is a compressed file that is similar to a WinZip (.zip) file.
Note: Each time MBSA is run it will attempt to connect to the Internet to download the
XML file from Microsoft. If an Internet connection is not available, the tool will look for a
local copy of the XML file in the tool installation folder. Each time the file is successfully
downloaded during a scan, a local copy will be stored on the computer in the event that
subsequent scans fail to connect to the Internet. Otherwise, for computers that never
connect to the Internet, users can separately download this file from the Microsoft
Download Center site and copy it onto the computers running the tool.
After the .CAB file is decompressed, MBSA scans your computer (or the selected
computers) to determine the operating system, service packs, and programs that you are
running. MBSA then parses the XML file and identifies security patches that are available
for your combination of installed software.
For the MBSA to determine whether a specific patch is installed on a given computer,
three items are evaluated: the registry key that is installed by the patch, the file version,
and the checksum for each file that is installed by the patch.
In the default configuration, MBSA compares both file details and registry keys from the
resulting XML subset to the files and registry details on the computer that is being
scanned. If any of the file or registry key details on the computer do not match the
information that is stored in the XML file, the associated security patch is identified as not
installed and the results are displayed in the security report. The specific Knowledge
Base article number that relates to the patch is also displayed on the screen.
In general, the MBSA scans for security issues in the Windows operating systems
(Windows NT 4.0, Windows 2000, and Windows XP), such as “Guest” account status, file
system type, available file shares, members of the Administrators group, and so on.
Descriptions of each operating system check are shown in the security reports with
instructions on fixing any issues found.
Note: To use MBSA, you must have either local administrator or domain administrator
access to the computer being checked for patches.
The tool has a number of command line switches, listed in the following tables. The
MBSA-style scan will store results, as was done in MBSA version 1.0, in individual XML
files to later be viewed in the MBSA user interface. MBSA-style scans include the full set
of available Windows, IIS, Microsoft® SQL Server™, desktop application, and security
update checks.
282
Table 8.1: MBSA-Style Command Line Switches
Switch
Function
Selecting computer to scan
<no option>
Scan the local computer
/c
<domainname>\<com
putername>
Scan the named computer
/i <xxx.xxx.xxx.xxx>
Scan the named IP
/r <xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx>
Scan range of IP addresses
/d <domainname>
scan named domain
Selecting which scan options NOT to perform (can concatenate like /n OS+IIS+Updates)
/n IIS
Skip IIS checks
/n OS
Skip Windows Operating System (OS) checks
/n Password
Skip password checks
/n SQL
Skip SQL checks
/n Updates
Skip security update checks
Security update scan options
/sus <SUS server>
Check only for security updates approved at the specified SUS server
/s 1
Suppress security update check notes
/s 2
Suppress security update check notes and warnings
/nosum
Security update checks will not test file checksums
Specifying output file name template
/o %domain%
%computername% (%date%)
Displaying results and details
/e
List errors from latest scan
/l
List all reports available
/ls
List of reports from latest scan
/lr <report name>
Display overview report
/ld <report name>
Display detailed report
Miscellaneous options
/?
Usage help
/qp
Don't display progress
/qe
Don't display error list
/qr
Don't display report list
The HFNetChk-style scan will check for missing security updates and will display scan
results as text in the command line window, as is done in the standalone HFNetChk tool.
MBSA 1.1 includes the "/hf" flag that will indicate an HFNetChk scan to the MBSA
engine. The HFNetChk switches listed below can be used after the "/hf" flag is specified
on the command line.
Note: The MBSA-style scan parameters listed above cannot be combined with the /hf
flag option.
283
Table 8.2: HFNetChk-Style Command Line Switches
Switch
Function
Selecting computer to scan
-h <hostname>
Scan the named NetBIOS computer name. Default location is the
local host. Multiple hosts can be scanned by separating host
names with a comma.
-fh <filename>
Scans the network basic input/output system (NetBIOS) computer
names specified in the named text file. Specify one computer
name on each line in the .txt file, with a 256-name maximum.
-i <xxx.xxx.xxx.xxx>
Scans the named IP address. Multiple IP address can be scanned
by separating each entry with a comma.
-fip <filename>
Scans the IP addresses specified in the named text file. Specify
one IP address on each line in the .txt file, with a 256-entry
maximum.
-r <xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx>
Specifies IP address range to be scanned.
-d <domainname>
Specifies the domain name to be scanned.
-n
Specifies that all computers on the local network should be
scanned. All computers from all domains in Network
Neighborhood are scanned.
Specifying which scan options should/should not be performed or displayed
284
-sus <SUS filename
| SUS server>
Specify a SUS text file or a SUS URL from which to obtain the
SUS file. If a file or server is not specified, then the engine will try
to use the value stored in the local computer registry.
-b
Scans a computer only for those updates that are marked as
baseline critical by the Microsoft Security Response Center.
-fq <filename>
Specifies the name of a file that contains Qnumbers to suppress
on output. Specify one Qnumber per line. This switch only
suppresses the specified item(s) from being displayed in the
output; it does not remove the item(s) from consideration during
the course of a scan.
-s
Suppresses NOTE and WARNING messages. The default is not
to suppress either of these message types. The following options
are used with this switch:
(1) Suppresses NOTE messages only.
(2) Suppresses both NOTE and WARNING messages.
-nosum
Specifies to not perform checksum validation for the security
update files. You do not need to use this switch under typical
circumstances.
-sum
Forces a checksum scan when scanning a non-English language
system. Use this switch only if you have a custom XML file with
language-specific checksums.
-z
Specifies to not perform registry checks.
(continued)
-history
Displays updates that have been explicitly installed, explicitly not
installed, or both. This switch is not necessary for normal
operation; you do not need to use it except under very specific
circumstances. The following options are used with this switch:
(1) Displays those updates that have been explicitly installed.
(2) Displays those updates that have been explicitly not installed.
(3) Displays those updates that have explicitly been installed and
not installed.
-v
Displays the reason why a test did not work in wrap mode. You
can use this switch to display the reason why a security update is
considered "not found" or if you receive a NOTE or WARNING
message.
Specifying output format and file names
-o
Specifies the desired output format. The following options are
used with this switch:
(tab) Displays output in tab-delimited format.
(wrap) Displays output in word-wrapped format.
-f <filename>
Specifies the name of a file in which to store the results. You can
use the switch in both wrap and tab output.
Miscellaneous options
-t
Displays the number of threads that are used to run the scan.
Possible values are 1 to 128, with the default value being 64. This
switch can be used to throttle down (or up) the scanner speed.
-u <username>
Specifies the user name to use when scanning a local or remote
computer or groups of computers. You must use this switch with
the -p (password) switch.
-p <password>
Specifies the password to use when scanning a local or remote
computer or groups of computers. You must use this switch with
the -u (username) switch. For security purposes, the password is
not sent over the network in clear text. Instead, MBSA uses the
challenge-response mechanism that is built into Windows NT 4.0
and later to secure the authentication process.
-x
Specifies the XML data source that contains the available security
update information. The location may be an XML file name, a
compressed XML .cab file, or a Uniform Resource Locator (URL).
The default file is the Mssecure.cab file from the Microsoft Web
site. When this switch is not used, the mssecure.xml file will be
downloaded from the Microsoft Web site.
-ver
Checks whether you are running the latest available version of
MBSA.
-trace
Creates a debug log to assist with troubleshooting (hf.log in the
local directory). This switch must be the first switch specified in
the command line and may be used in conjunction with other
switches.
-about
Displays information about MBSA.
285
If you are using MBSA to verify your patch status, you should ensure that it is run
regularly. In most environments, the best way to do this is to schedule it to run at pre-set
intervals.
Note: For more information about using MBSA, see
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/
Tools/mbsahome.asp.
Patch Management Script
This guide includes a patch management script, MBSAPatchCheck.cmd, which will check
multiple servers for missing patches and record the results to a log file that is saved in a
date-based folder. The script uses MBSA to scan servers and another script,
movelog.vbs, to move the files into the appropriate folders. Over time these folders make
up a history that you can review as part of your analysis and review phases, helping you
to keep your environment more secure.
Note: The script included with this guide requires MBSA version 1.1 or later.
After downloading and extracting the scripts included with this guide, you will have the
following folder structure for the patch management script.
Table 8.3: Folder Structure for the Patch Management Script
Folder
Description
C:\SecurityOps
This is the root folder for all of the files included
with this guide.
C:\SecurityOps\PatchMgmt
This folder contains the patch management script,
MBSAPatchCheck.cmd, the movelog.vbs script,
and the subfolders for the support files and logs.
This folder is also where the mssecure.xml file
must be placed.
C:\Program Files\Microsoft Baseline
Security Analyzer\
This folder is where the MBSA utility must be
placed after being downloaded from the Microsoft
Web site. See below for more detailed instructions.
C:\SecurityOps\PatchMgmt\ServerLists
This folder is where you create and keep text files
listing groups of servers to be scanned for missing
patches.
C:\SecurityOps\PatchMgmt\Logs
This folder is where the log files are created after
MBSAPatchCheck.cmd is run. The script creates a
subfolder with the current date in which the log file
is stored, for example
\SecurityOps\PatchMgmt\Logs\2002117.
Important: If you install the files included with this guide on a partition other than drive
C, you will need to edit the paths in the MBSAPatchCheck.cmd file to use that partition.
286
XTo set up and use the MBSAPatchCheck.cmd script on SUS
1. Run SecurityOps.exe to extract the script files included with this guide to create the
folder structure listed in Table 8.3. By default this file is located in C:\SCI\Scripts
when you extract the files from the self-extracting executable called SecWin2k.exe.
2. Download the MBSA utility from
http://www.microsoft.com/technet/security/tools/tools/mbsahome.asp and install the
tool in the default folder (C:\Program Files\Microsoft Baseline Security Analyzer).
3. If the computer that is running the script is not connected to the Internet, you will
also need to download and extract the Mssecure.xml file from
http://download.microsoft.com/download/xml/security/1.0/nt5/
en-us/mssecure.cab. Mssecure.xml should be placed in the MBSA folder.
4. Create a server list text file in C:\SecurityOps\PatchMgmt\ServerLists.
This is a text file containing the NetBIOS names of the servers that you want to check,
separated by carriage returns.
5. Open a command prompt, change to the C:\SecurityOps\PatchMgmt folder, and
start the script using the following command line.
MBSAPatchCheck.cmd serverlist.txt
Where serverlist.txt is the name of the server list text file.
Note: If you receive a dialog box asking whether you want to download the
mssecure.xml file, click Yes.
6. Change to the C:\SecurityOps\PatchMgmt\Logs folder, open the folder with the
current date, and open the file with the same name as the serverlist.txt file.
7. Examine the log file to determine what patches are missing on your servers.
Note: If the patch management script is run twice in a single day, the log file from
the first time the script was run will be overwritten.
Working with Multiple Server Lists
In a large scale network, you will have many different server types. As part of your risk
management process, you may determine that you need to monitor some of your servers
more often than others for missing patches.
If you use multiple server lists, you can schedule the patch management script to scan
different types of servers at different intervals. Multiple server lists are also useful if you
have different administrators responsible for different groups of servers. Using multiple
lists, you will be able to create separate reports of missing patches for each group of
administrators.
287
As an example, you could create five server list files to provide patch reports to different
groups of administrators for the Contoso network shown in the following figure.
Figure 8.2
Server list files for a simple network
In this example, the server list files for each type of server would contain the names of
those servers. For example, File&Print.txt simply contains:
FP01
FP02
FP03
The fifth server list file, Servers.txt, contains all of the servers in the environment. The
results of this scan could be used by the security team to ensure that each group is
keeping their servers up to date with the latest patches.
Scheduling the Patch Management Script
To ensure that MBSAPatchCheck.cmd runs at set intervals, you should consider
scheduling the tool to run regularly. This could be done using the task scheduler or the
AT command. By using multiple server lists, you could ensure that different servers are
checked at different times.
Note: By default, the schedule service is disabled in the Member Server and Domain
Controller Baseline policies. You will need to enable the service if you want to schedule
the Patch Management Script.
288
Other Methods for Determining Hotfix Levels
If you do not want or are unable to use the MBSA tool in some parts of your environment,
there are other ways that you can determine whether hotfixes have been installed.
The easiest way to do this is to look in the registry under the
HKLM\Software\Microsoft\Windows Nt\Currentversion\hotfix key. Every new hotfix
installed should have a key with a Q name that corresponds to the article in the
Knowledge Base discussing the hotfix. However, this is not the case for some older
hotfixes and hotfixes for some applications.
Other Tools for Determining Hotfix Levels
There are two other free tools from Microsoft that that you can use to gather this
information. These tools are:
●
Qfecheck.exe /v. This tool informs you of service pack levels and hotfix versions
installed on your servers. Qfecheck will also tell you if a patch was not correctly
installed in your environment.
●
Hotfix.exe -l. This tool displays the number and versions of hotfixes installed on
your servers.
Plan
Not every threat or vulnerability poses a significant risk to your environment. As you read
notifications of potential new operating system or application vulnerabilities, you should
assess whether these vulnerabilities apply to your particular environment.
For example, if the vulnerability applies to the File Transfer Protocol (FTP) service in
Windows 2000 and you never enable this service, then the vulnerability does not apply to
you. Likewise, if you learn that there is an increased chance of hurricanes this year, but
your IT environment is inland, then this threat is minimal.
If you respond to threats and vulnerabilities that do not apply to your environment, you
will use up valuable resources and, potentially, adversely affect the stability of your
environment with no corresponding benefit.
As new threats and vulnerabilities emerge, you should read any supporting information
about them. This will allow you to make an informed decision on the level of significant
risk to your environment and then determine the appropriate response. Your primary
alternatives will be to take no action, to disable the service at risk, or to deploy a patch.
Important: When creating the plan for deploying a new patch, you should also create a
rollback plan.
To ensure that you stay current on new patches, make sure that you receive regular
security bulletins from Microsoft. To sign up to receive the update bulletins, go to the
Microsoft Security Web site. For details, see the More Information section at the end of
this chapter.
289
Categorizing Patches
As each new patch becomes available, you should determine its importance to your
environment. This will then determine how soon you will need to deploy it and how much
testing you can afford.
Microsoft provides ratings for each vulnerability that is the subject of a security bulletin.
The rating levels are shown in the following table.
Table 8.4: Vulnerability Ratings, as Defined by Microsoft
Computer Type
Critical
Rating Level
Moderate
Internet servers
Web site defacement,
denial-of-service
(DoS), or full control.
Difficult to exploit, unusual
configuration, or transient
effect.
Limited impact such as
disclosure of scripts.
Internal servers
Elevation of privilege,
data disclosure, or
modification. Auditing
difficult.
Auditable data disclosure,
modification, or DoS.
Untargeted or
fragmentary data theft
or modification, limited
DoS.
Client systems
Run arbitrary code
without user action;
remote escalation of
privilege.
Local escalation of
privilege, untargeted data
disclosure or DoS, use
action exploitation.
Limited or fragmentary
data theft or
modification, hostile
Web site attacks.
Low
The rating system categorizes vulnerabilities, according to their potential impact if the
vulnerability is exploited and the likelihood of that happening.
You can use this rating system as a guide for categorizing patches. However, the
Microsoft rating system is just an overall estimate of potential impact in the context of
millions of customers worldwide; the severity ratings are based on past experience and
subjective judgment. For these reasons, they may not be accurate predictors of impact
for your environment. Ultimately, you will need to categorize patches based on your own
environment.
Testing the Patches
As with any software, patches may not work perfectly in every environment. Ideally, you
should thoroughly test any patches that you are going to install in your environment.
However, many security patches need to be installed quickly in order to fix potentially
serious problems.
In many cases, you will find your testing procedure is a compromise between the need to
solve a security issue and the need to ensure that your patch is stable in your
environment.
How much testing is appropriate will depend on how you have categorized the patch.
Using the Microsoft categorizations, the following table shows the minimum level of
testing that you should perform for each patch type. For the Contoso scenario, we
wanted to be sure that each of the server roles still functioned properly after the
recommended hotfixes were installed. We did so by verifying that various client
computers could still connect to the network services running on each server role and
performing other basic test procedures to confirm that everything was still working as
expected.
290
Table 8.5: Minimum Testing for Patches
Patch Type
Critical severity patches
Testing Phases
Assessing the patch
Assessing server operations (Limited)
Moderate severity patches
Assessing the patch
Installing the patch in a test environment
Assessing server operations (Full)
Checking the uninstall procedure
Low severity patches
Assessing the patch
Installing the patch in a test environment
Assessing server operations (Full)
Assessing application operations
Checking the uninstall procedure
As part of your risk management procedure, you will need to determine how thoroughly to
perform each step. If you skip some phases due to urgency, you should still continue to
complete them in a test lab to find potential problems before they occur on already
deployed systems.
All testing should occur on servers that resemble your production servers as closely as
possible.
Assessing the Patch
At a minimum, your patch assessment should consist of the following steps:
●
Identifying the patch owner. For all patches, you should have an identified owner
who is responsible for the evaluation of the patch.
●
Reviewing all documentation. Before applying any service pack, hotfix, or
security patch, all relevant documentation should be read and peer reviewed. The
peer review process is critical as it mitigates the risk of a single person missing
critical and relevant points when evaluating the update.
●
Verifying the patch category. After further assessment of the patch, you may
need to change its category. This will affect other aspects of your testing.
As you read the documentation, look for answers to the following questions:
●
Is the update relevant, and will it resolve an outstanding issue?
●
Will adopting the update cause other problems resulting in a compromise of the
production system?
●
Are there dependencies relating to the update? (For example, do certain features
need to be enabled or disabled for the update to be effective?)
●
Do you need to perform any actions prior to deploying the update?
As well as examining the documentation released with the updates, you should search
the Microsoft support Web site for any additional post-release information on the update.
TechNet also provides security bulletins in a searchable (by product name and service
pack) database on its Web site. These materials supply critical information that must be
referenced.
291
Installing
You should make sure that the patch installs correctly, understand whether the patch
requires a restart, know how much space it takes up (including an uninstall folder),
understand what options are available to you, and so on. You also should read any
supporting documentation for additional information evaluate the pros and cons of
applying the patch.
Server Operations
Once the patch is installed, you need to make sure that the server continues to work
normally. It is also a good idea to monitor the Event Log and System Monitor for any
unexpected results.
Test all of the server functions and make sure that everything operates normally. How
much risk you can handle on the particular server, for the particular vulnerability, will
determine how long you should allow the server to run before determining whether
everything is running normally. If there are any problems, you need to make sure that
these are documented and they should be reported to Microsoft as soon as possible.
Note: You can use Microsoft Operations Manager (MOM) to collect Event Log and
System Monitor information.
Application Operations
As part of your testing procedure, it is important to test the patch with any applications
that coexist on the servers and make sure that you identify any issues with
dependencies. After installing the patch, you should check that all applications continue
to work as before.
Uninstall
It is possible that despite your testing, after installing the patch you will run into problems
that result in your needing to uninstall the patch. It is important, therefore, to test that the
uninstall works. After uninstalling, you should check that the server continues to run as
expected and continue to watch the Event Log and System Monitor counters.
Creating a Rollback Plan
Even if your testing proceeds entirely without incident, it is still possible that there will be
problems as you deploy the patch throughout your organization. You need a plan of
action to restore the system to its original state before the patch was deployed.
In some cases, this consists of taking a snapshot backup of a server before the install
occurs, so that if there are problems the server can be restored very quickly. Whatever
rollback plan your organization comes up with should be thoroughly tested.
292
Deploying the Patches
Assuming the testing proceeds smoothly, you should now be ready to deploy the patch
across your organization. There are a number of ways to do this, including the following
methods and processes:
●
Manual deployment
●
Group Policy
●
Scripts
Note: For additional information on deploying patches, see the TechNet article, "Best
Practices for Applying Service Packs, Hotfixes and Security Patches" referenced in the
More Information section at the end of this chapter.
Manual
Manual hotfix installation is the most common installation method for most organizations.
This consists of simply running the executable corresponding to the hotfix on each
server. If your organization has many servers, though, this may be an impractical option.
The name of most hotfixes will tell you important information about the fix. For example, a
typical name for a hotfix is Q292435_W2K_SP3_x86_en.EXE.
In this case:
●
Q292435 is the Knowledge Base article number where you can find out more
information about the hotfix.
●
W2K is the product it is intended for (Microsoft Windows 2000).
●
SP3 is the Service Pack that it will be included in.
●
x86 is the processor architecture that it is meant for.
●
en is the language that the hotfix is released in (English in this case).
Note: Hotfixes that have a file name of QXXXXXX.exe and do not have W2K_SP3_x86
appended to the file name are specific to applications such as Internet Explorer.
293
Hotfixes also support several command line switches that can be used to control the
behavior of the hotfix installation process.
Table 8.6: Switches for Hotfix Executables
Switch
Description
-y
Perform uninstall
-f
Force applications to close at shutdown
-n
Do not create an uninstall directory
-z
Do not restart when update completes
-q
Quiet mode — no user interface (UI)
-m
Unattended mode
-l
List installed hotfixes
Note: Application specific hotfixes with file names of QXXXXXX.exe typically do not
support all of the above switches.
If you script the installation of multiple hotfixes, you will want to use the -q and -z
switches so that the hotfix is installed without a user interface and does not force a
restart.
Normally when you install multiple hotfixes you need to restart the computer between
each one. This is because any files that are locked, or in use, cannot be replaced, so
they are placed in a queue to be replaced after the system restarts.
QChain is a tool that allows you to string together several hotfixes with only a single
restart, instead of restarting between each install. To use QChain, run the hotfix installer
with the -z switch to instruct the installer not to restart after the installation. Then run
QChain.exe and restart the computer.
Note: QChain is available on TechNet. For further details, see the More Information
section at the end of this chapter.
If additional components, such as Domain Name System (DNS), are added after applying
a service pack and patches, it is necessary to reapply the service pack and patches to
ensure that the new component is properly patched.
Group Policy
Windows 2000 natively supports software distribution using Group Policy. Patches do not
normally come in the form of a Windows Installer package. However, you can use such
an executable in conjunction with a .zap file.
Applications that do not use Windows Installer packages must use a .zap file to describe
their existing setup program. A .zap file is a text file (similar to an .ini file) that provides
information about how to install a program, the application properties, and the entry
points that the application should install.
294
A .zap file can only be assigned to a user, which means that once you set up Group
Policy to distribute the hotfix, you still need to log on to the computer with the user
account to which the .zap file was assigned.
Note: For more information about creating a .zap file and assigning it using Group
Policy, see the Knowledge Base article Q231747, "How to Publish non-MSI Programs
with .zap Files."
Scripts
You may want to create your own scripts using the Microsoft® Visual Basic® Scripting
Edition (VBScript) language or batch files to roll out patches. These could be in the form
of logon or startup scripts, which check to see the current patch status and then check
updates from a centralized server.
Your scripts can include QChain, to ensure that if more than one hotfix is required, only a
single restart is needed.
Monitoring
After you have installed the patches into your production environment, you need to
continue to monitor your servers. Make sure that you watch the Event Log and System
Monitor counters for problems. If you see any other errors on the computers for the next
couple of weeks, you should test to make sure that they are not related to the patch that
you deployed. Also, if you implemented a patch without thorough lab testing because it
was time-critical, you should continue testing the patch in a lab environment afterwards to
make sure that nothing was missed.
As well as monitoring existing servers, it is very important that you monitor the
environment as a whole to ensure that new servers are not brought onto the network and
left without installing the current patches on them. There should always be a latest build
that new servers receive. The monitoring policy for your organization should ensure that
this happens.
Reviewing
You can only be sure that any process is working properly if you review it. As you
complete the patch management process for each patch, you should review to ensure
that each one was deployed correctly, and that all procedures ran correctly. This will help
to ensure that your patch management process continues to function as it should. As you
review the process, you should continue to analyze the environment for further changes.
If any occur, you will need to start the patch management process again.
295
Other Tools
By following the recommendations outlined so far in this chapter, you are well on your
way to managing patches effectively within your organization. However, there are a
number of additional tools that you can use to further automate the process of patch
management.
Microsoft Systems Management Server
If you have Microsoft® Systems Management Server (SMS) deployed in your
organization, you can use it to help you with many of the phases discussed above.
The Microsoft Security Tool Kit contains an SMS import utility that can be used to
automate the distribution and installation of recommended IIS security fixes. SMS can
help you determine which computers need the security fixes, and then deploy them.
The software deployment features of SMS can be used to roll out patches in your
environment to all computers that have the SMS client. If you create a software package
for the patch, you can force an upgrade to all or any collection of computers in your
environment. One of the main advantages of this flexibility is that you can monitor which
computers have the patch installed. However, in most cases you will need an SMS
administrator or someone with knowledge of creating SMS packages to correctly roll out
these types of upgrades.
Third-Party Tools
A number of third-party tools described below are available to help with patch
management. These tools offer some features not currently available with the free tools
from Microsoft, such as the ability to deploy fixes and have the status reported back,
create computer groupings with similar update needs, support other products not covered
by the tools described above, and have graphical user interface (GUI) command areas
for administrative tasks. You should evaluate these features and determine whether they
are needed within your environment.
Polaris Group Hotfix/Service Pack Utility
This tool has an easy to use GUI, supports any Microsoft product, and can automate the
process of deploying service packs and hotfixes so that all computers run on a corporate
standard that you specify.
http://www.polarisgroup.com/products.asp
296
Shavlik Hfnetchkpro
This tool is built on HFNetChk technology. It has a GUI option that the command line
version does not which allows you to keep a scan history.
http://www.shavlik.com/nshc.htm
Bindview Security Advisor
The Bindview tool has a GUI to help simplify the process of checking for noncompliant
computers. It also has an update service that lets you know when new patches have
been released.
http://www.bindview.com/Solutions/Security/SecAdvisor_bvCtrlW2k.cfm
Pedestal Software’s Security Expressions
This tool allows administrators to implement security lock down policies on Windows- and
UNIX-based computers. It also has the capability to check for hotfixes and automatically
download and install them if needed.
http://www.pedestalsoftware.com/secexp/index.htm
297
Summary
The vast majority of breaches in IT security come from the exploitation of system
environments that are not fully up to date with security patches. Good patch management
is essential to minimizing the security risks that you face. Take patch management
seriously and you are likely to dramatically reduce the costs associated with security
breaches. For the Contoso scenario, we recognized that patch management is an
ongoing process and we made sure that the servers remained up -to -date with securityrelated hotfixes throughout the project.
More Information
For further information about the Microsoft Baseline Security Analyzer, see:
http://www.microsoft.com/technet/security/tools/tools/mbsahome.asp
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q320454&ID=KB;ENUS;Q320454
To view the technical white paper on the Microsoft Baseline Security Analyzer, see:
http://www.microsoft.com/technet/security/tools/tools/mbsawp.asp
To download mssecure.cab, go to:
http://download.microsoft.com/download/xml/security/1.0/nt5/en-us/mssecure.cab
For further information about how to create a .zap file for use with Group Policy, see:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q231747
– or –
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnexnt00/html/
ewn0085.asp
To download Qfecheck.exe information, go to:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q282784
To download Hotfix.exe information, go to:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q184305
To download information about Qchain and the executable for it, go to:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q296861
For further information about the Microsoft Security Rating system, see:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/policy/
rating.asp
To receive regular Microsoft Security Bulletins, go to:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/current.asp
298
For further information about the Microsoft Security Tool Kit, see:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/tools/
stkintro.asp
For further information about the Microsoft Operations Framework (MOF), see:
http://www.microsoft.com/business/services/mcsmof.asp
For the article, Best Practices for Applying Service Packs, Hotfixes and Security Patches,
see:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bestprac/
bpsp.asp
Related Topics
Microsoft TechNet Security site:
http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/itsolutions/security/
bestprac/secthret.asp
Microsoft Security Best Practices:www.microsoft.com/security/business
How to Publish non-MSI Programs with .zap Files (Q231747):
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q231747
299
9
Auditing and Intrusion
Detection
In any secure environment, you should actively monitor for intrusion and attack. It would
be counterproductive to put secure systems in place and then not perform any auditing,
based on the assumption that you will not be attacked.
There are a number of reasons why monitoring and auditing for intrusion are very
important. These include:
●
Any functional computer environment is potentially open to attack. No matter how
high your level of security, there is a risk that you may be attacked.
●
Successful attacks often follow a series of unsuccessful ones. If you do not monitor
for attacks you will not detect others before they are successful.
●
Once a successful attack occurs, the earlier you find out, the easier it will be to
contain the damage.
●
In order to recover from an attack, you need to know what damage has been done.
●
Auditing and intrusion detection helps you determine who was responsible for the
attack.
●
The combination of auditing and intrusion detection helps correlate information to
identify attack patterns.
●
Regular review of security logs helps identify unknown security configuration
issues, such as incorrect permissions, or lax account lockout settings.
●
After an attack is detected, auditing can assist in determining what network
resources are compromised.
This chapter shows how to audit your environment to give you the best chances of
spotting and tracing an attack, and looks at monitoring for intrusion — including the use of
intrusion detection systems — software specifically designed to spot behavior that
indicates an attack is occurring.
301
Auditing
As part of your overall security strategy, you should determine the level of auditing
appropriate for your environment. Auditing should identify attacks, either successful or
not, that pose a threat to your network, or against resources that you have determined to
be valuable in your risk assessment.
When deciding how much to audit, you should bear in mind that the more you audit, the
more events you generate, and the more difficult it can be to spot critical events. If you
are doing extensive auditing, you should strongly consider using additional tools, such as
Microsoft® Operations Manager (MOM), to help you filter events that are of greater
importance.
Audit events can be split into two categories: success events and failure events. A
success event indicates that a user has successfully gained access to a resource,
whereas a failure event shows that they tried, but failed.
Failure events are very useful in tracking attempted attacks on your environment, but
success events are much more difficult to interpret. While the vast majority of successful
audit events are simply indications of normal activity, an attacker who manages to gain
access to a system will also generate a success event. Often, a pattern of events is as
important as the events themselves. For example, a series of failures followed by a
success may indicate an attempted attack that was eventually successful.
Wherever possible you should combine audit events with other information you have
about your users. For example, if users leave on vacation, you may choose to disable
their accounts while they are away, and audit for them when they are re-enabled.
How to Enable Auditing
Auditing is enabled using Group Policy, at the site, domain, organizational unit (OU), or
local computer level. You will find the audit policy settings in:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy
Generally, you should implement auditing at a high level in the
Microsoft® Active Directory® directory service hierarchy, because this will help to
maintain consistency in your auditing settings. Contoso implemented auditing at both the
Member Server and Domain Controller OU levels. For details on this, see Chapter 6,
"Hardening the Base Windows 2000 Server."
You may have servers that you have chosen to keep separate from the domain. Auditing
can be configured on these computers by editing Group Policy for the local computer, or
by using the Auditpol.exe utility in the Windows 2000 Server Resource Kit.
Note: To access Group Policy for a local computer, start the Microsoft Management
Console (MMC) and then add the Group Policy snap-in, which will make the Local
Computer the focus of the snap-in.
302
Defining Event Log Settings
Every event generated by auditing will appear in Event Viewer. You should determine
how event logs will store the events that are generated. Each of the settings can be
defined directly in Event Viewer, or in Group Policy. For this guide, we have defined
Event Viewer settings in Group Policy. For details of recommended settings, see Chapter
6, "Hardening the Base Windows 2000 Server."
If you remove the Event Viewer settings from Group Policy, you can instead define them
directly in Event Viewer. However, it is recommended that you define your Event Viewer
settings in Group Policy to ensure consistent settings across similar computers.
In Contoso's environment, Group Policy is not configured to shut down the systems in the
organization if the security log reaches capacity. Rather, the systems are configured to
overwrite event logs as needed.
Events to Audit
Microsoft® Windows® 2000 provides several categories of auditing for security events.
When designing your enterprise audit strategy, you will need to decide whether to include
the following categories of security audit events:
●
Logon events
●
Account logon events
●
Object access events
●
Directory Service access events
●
Privilege use events
●
Process tracking events
●
System events
●
Policy change events
The following sections detail some of the more common event IDs that are returned when
auditing is enabled for specific categories.
Note: Tools used to search and collect event log information are discussed in the
Passive Detection Methods section later in this chapter.
Logon Events
If you audit for logon events — every time that a user logs on or off a computer — an
event is generated in the security log of the computer where the logon attempt occurs.
Also, when a user connects to a remote server, a logon event is generated in the security
log of the remote server. Logon events are created when the logon session and token are
created or destroyed respectively.
303
Logon events can be useful to track attempts to logon interactively at servers or to
investigate attacks launched from a particular computer. Success audits generate an
audit entry when a logon attempt succeeds. Failure audits generate an audit entry when
a logon attempt fails.
Note: Logon events include both computer and user logon events. You will see
separate security event log entries for both the computer account and the user account
if a network connection is attempted from a Microsoft® Windows NT®- or
Windows 2000-based computer. Windows 9x-based computers do not have computer
accounts in the directory and do not generate computer logon event entries for network
logon events.
As part of the Member Server and Domain Controller Baseline Policies, auditing for
success and failure logon events is enabled. You should therefore expect to see the
following event IDs for interactive logons, and Terminal Services logons connecting to
computers running Terminal Services in the Security Event Log.
Table 9.1: Logon Events That Appear in the Security Event Log
304
Event ID
Description
528
A user successfully logged on to a computer.
529
The logon attempt was made with an unknown user name or a known user name
with a bad password.
530
An attempt was made to log on with the user account outside of the allowed time.
531
A logon attempt was made using a disabled account.
532
A logon attempt was made using an expired account.
533
The user is not allowed to log on at this computer.
534
The user attempted to log on with a logon type that is not allowed, such as
network, interactive, batch, service, or remote interactive.
535
The password for the specified account has expired.
536
The Net Logon service is not active.
537
The logon attempt failed for other reasons.
538
A user logged off.
539
The account was locked out at the time the logon attempt was made. This event
can indicate that a password attack was launched unsuccessfully resulting in the
account being locked out.
540
Successful Network Logon. This event indicates that a remote user has
successfully connected from the network to a local resource on the server,
generating a token for the network user.
682
A user has reconnected to a disconnected Terminal Services session. This event
indicates that a previous Terminal Services session was connected to.
683
A user disconnected a Terminal Services session without logging off. This event is
generated when a user is connected to a Terminal Services session over the
network. It appears on the terminal server.
The following security events can be diagnosed using logon event entries:
●
Local logon attempt failures. Any of the following Event IDs indicates failed
logon attempts: 529, 530, 531, 532, 533, 534, and 537. You will see events 529
and 534 if an attacker tries and fails to guess a username and password
combination for a local account. However, these events can also occur when a
user forgets their password, or starts browsing the network through My Network
Places.
In a large scale environment it can be difficult to interpret these events effectively.
As a rule, you should investigate these patterns if they occur repeatedly or coincide
with other unusual factors. For example, a number of 529 events followed by a 528
event in the middle of the night could indicate a successful password attack (or a
very tired administrator).
●
Account Misuse. Events 530, 531, 532, and 533 can all represent misuse of a
user account. The events indicate that the account/password combination was
correctly entered, but other restrictions are preventing a successful log on.
Wherever possible, you should investigate these events to determine whether
misuse occurred, or if the current restriction needs to be modified. For example,
you may need to extend the logon hours of certain accounts.
●
Account Lockouts. Event 539 indicates that an account was locked out. This can
indicate that a password attack has failed. You should look for earlier 529 events
by the same user account to try and discern the pattern of logon attempts.
●
Terminal Services attacks. Terminal Services sessions can be left in a connected
state that allows processes to continue running after the session is ended. Event
ID 683 indicates when a user does not log out from the Terminal Services session,
and Event ID 682 indicates when a connection to a previously disconnected
session has occurred.
Contoso is monitoring for large numbers of logon attempt failures and large numbers of
account lockouts. It is not uncommon in their environment for users to leave terminal
services sessions disconnected for legitimate reasons.
Account Logon Events
When a user logs on to a domain, the log on is processed at a domain controller. If you
audit Account Logon events at domain controllers, you will see this logon attempt
recorded at the domain controller that validates the account. Account Logon events are
created when an authentication package validates a user's credentials. When domain
credentials are used, Account Logon events are only generated in the domain controllers'
event logs. If the credentials presented are local Security Accounts Manager (SAM)
database credentials, then the account logon events are created in the server's security
event log.
Because the Account Logon event can be recorded in any valid domain controller in the
domain, you must ensure that you consolidate the security log across domain controllers
to analyze all Account Logon events in the domain.
Note: As with Logon events, Account Logon events include both computer and user
logon events.
305
As part of the Member Server and Domain Controller Baseline Policies, auditing for
success and failure Account Logon events is enabled. You should therefore expect to
see the following event IDs for network logons and Terminal Services authentication.
Table 9.2: Account Logon Events That Appear in the Event Log
Event ID
Description
672
An authentication service (AS) ticket was successfully issued and validated.
673
A ticket granting service (TGS) ticket was granted.
674
A security principal renewed an AS ticket or TGS ticket.
675
Pre-authentication failed.
676
Authentication Ticket Request failed.
677
A TGS ticket was not granted.
678
An account was successfully mapped to a domain account.
680
Identifies the account used for the successful logon attempt. This event also
indicates the authentication package used to authenticate the account.
681
A domain account logon was attempted.
682
A user has reconnected to a disconnected Terminal Services session.
683
A user disconnected a Terminal Services session without logging off.
For each of these events, the event log shows detailed information about each specific
log on. The following security events can be diagnosed using account logon event
entries:
●
Domain logon attempt failures. Event IDs 675 and 677 indicate failed attempts to
logon to the domain.
●
Time Synchronization issues. If a client computer's time differs from the
authenticating domain controller's by more than five minutes (by default), Event ID
675 will appear in the security log.
●
Terminal Services attacks. Terminal Services sessions can be left in a connected
state that allows processes to continue running after the terminal server session is
ended. Event ID 683 indicates when a user does not log out from the Terminal
Services session, and Event ID 682 indicates when a connection to a previously
disconnected session has occurred. To prevent disconnections, or to terminate
these disconnected sessions, define the time interval to end disconnected
session in the Terminal Services Configuration console, in the properties of the
RDP-TCP protocol.
Contoso is currently monitoring for uncommon numbers of domain logon attempt failures.
Based on their environment, the other events are not relevant. When configuring these
settings, they determined that the best approach was to start with a relatively tight setting
and continue to reduce it until the number of false positive alerts was reduced. Currently,
they are monitoring for any cases where 10 failed logins occur in a 10 minute period.
These numbers may be different in all environments.
306
Account Management
Account Management auditing is used to determine when users or groups are created,
changed, or deleted. This audit can be used to determine when a security principal was
created, and who performed the task.
As part of the Member Server and Domain Controller Baseline Policies, auditing for
success and failure in Account Management is enabled. You should therefore expect to
see the following event IDs recorded in the security log.
Table 9.3: Account Management Events That Appear in the Event Log
Event ID
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
641
642
643
644
Description
User Account Created
User Account Type Change
User Account Enabled
Password Change Attempted
User Account Password Set
User Account Disabled
User Account Deleted
Security Enabled Global Group Created
Security Enabled Global Group Member Added
Security Enabled Global Group Member Removed
Security Enabled Global Group Deleted
Security Disabled Local Group Created
Security Enabled Local Group Member Added
Security Enabled Local Group Member Removed
Security Enabled Local Group Deleted
Security Enabled Local Group Changed
Security Enabled Global Group Changed
User Account Changed
Domain Policy Changed
User Account Locked Out
The following Account Management events can be diagnosed using security log entries:
●
Creation of a user account. Event IDs 624 and 626 identify when user accounts
are created and enabled. If account creation is limited to specific individuals in the
organization, you can use these events to identify whether unauthorized personnel
have created user accounts.
●
User account password changed. The modification of a password by someone
other than the user can indicate that an account has been taken over by another
user. Look for Event IDs 627 and 628 which indicate that a password change is
attempted and is successful. Review the details to determine whether a different
account performed the change, and whether the account is a member of the help
desk or other service team that resets user account passwords.
307
●
User account status changed. An attacker may attempt to cover their tracks by
disabling or deleting the account used during an attack. All occurrences of Event
IDs 629 and 630 should be investigated to ensure that these are authorized
transactions. Also look for occurrences of Event ID 626 followed by Event ID 629 a
short time later. This can indicate that a disabled account was enabled, used, and
then disabled again.
●
Modification of Security Groups. Membership changes to Domain
Adminstrators, Administrators, any of the operator groups, or to custom global,
universal, or domain local groups that are delegated administrative functions
should be reviewed. For global group membership modifications, look for Event
IDs 632 and 633. For domain local group membership modifications, look for Event
IDs 636 and 637.
●
Account Lockout. When an account is locked out, two events will be logged at
the primary domain controller (PDC) emulator operations master. A 644 event will
indicate that the account name was locked out, and then a 642 event is recorded,
indicating that the user account is changed to indicate that the account is now
locked out. This event is only logged at the PDC emulator.
Because Contoso is a fairly large enterprise, they have a great deal of account
maintenance that occurs on a daily basis. Monitoring for all of these events would cause
too many alerts to be reasonably addressed in their environment.
Object Access
Auditing can be enabled for all objects in a Windows 2000-based network with a system
access control list (SACL). A SACL contains a list of users and groups for which actions
on the object are to be audited. Almost any object that a user can manipulate in
Windows 2000 has a SACL. This includes files and folders on NTFS file system drives,
printers and registry keys.
A SACL is comprised of access control entries (ACEs). Each ACE contains three pieces
of information:
●
The security principal to be audited.
●
The specific access types to be audited, called an access mask.
●
A flag to indicate whether to audit failed access, successful access, or both.
If you want events to appear in the security log, you must first enable Auditing for
Object Access and then define the SACL for each object you wish to audit.
308
Audits in Windows 2000 are generated when a handle to an object is opened.
Windows 2000 uses a kernel-mode security subsystem that only allows programs to
access objects through the kernel. This prevents programs from attempting to bypass the
security system. Since the kernel memory space is isolated from user mode programs, a
program refers to an object through a data structure called a handle. The following is a
typical access attempt:
1. A user instructs a program to access an object (for example, File/Open).
2. The program requests a handle from the system, specifying what kind of access
(read, write, and so on) is desired.
3. The security subsystem compares the Discretionary Access Control List (DACL) on
the requested object to the user’s token, looking for entries in the DACL that match
either the user or a group the user belongs to and that has the access rights the
program requested.
4. The system compares the SACL on the requested object to the user’s token,
looking for entries in the SACL that match either the effective rights being returned
to the program, or the rights requested by the program. If a matching failure audit
ACE matches an access that was requested but not granted, a failure audit event
is generated. If a matching success audit ACE matches an access that was
granted, a success audit event is generated.
5. If any access is granted, the system returns a handle to the program, which can
then use the handle to access the object.
It is very important to note that when auditing occurs and the event is generated, nothing
has happened to the object yet. This is critical to interpreting audit events. Write audits
are generated before a file is written to, and read audits are generated before a file is
read.
As with all auditing, it is very important to take a targeted approach to auditing object
access. In your auditing plan, decide on the type of objects that you must audit and then
determine what type of access attempts (success, failure, or both) you wish to monitor for
each type of audited object. An overly broad approach to auditing will have a significant
impact on your system’s performance and will result in the collection of much more data
than is necessary or useful.
Generally you will want to audit all access to your chosen objects, including from
nontrusted accounts. To achieve this, add the Everyone Group to the SACL on the
objects you wish to audit. You should be wary of auditing for success on object access as
this can create a very large number of audit entries in the security log. However, for
example, if you are investigating the deletion of a critical file, you will need to examine
success audit events to determine which user account deleted the file.
The Member Server and Domain Controller Baseline Policies are set to audit for both
success and failure on object access. However, no SACLs are set on the objects
themselves and you will need to set these according to the needs of your environment.
The SACLs can be defined directly at the objects, or using Group Policy. If the object that
requires auditing exists on multiple computers, you should define the SACLs in Group
Policy.
309
Auditing for Object Access will cause the following events to appear in the security log.
Table 9.4: Object Access Events That Appear in the Event Log
Event ID
Description
560
Access was granted to an already existing object.
562
A handle to an object was closed.
563
An attempt was made to open an object with the intent to delete it. (This is
used by file systems when the FILE_DELETE_ON_CLOSE flag is
specified.)
564
A protected object was deleted.
565
Access was granted to an already existing object type.
If you are looking for specific object access events, you will primarily need to research
Event ID 560 events. The useful information is within the event details and you will need
to search the event details to find the specific events you are searching for. The following
table shows some actions you may need to perform and how to perform them.
Table 9.5: How to Perform Key Auditing Actions for Object Access Event 560
Auditing Action
How It Is Achieved
Find a specific file, folder or object
In the Event 560 details, search for the full
path of the file or folder you wish to review
actions for.
Determine actions by a specific user
Define a filter that identifies the specific
user in a 560 event.
Determine actions performed at a specific
computer
Define a filter that identifies the specific
computer account where the task was
performed in a 560 event.
Contoso is not specifically monitoring for any object access events, but is auditing object
access for some files. This information can be extremely helpful when responding to a
security incident.
Directory Service Access
Active Directory objects have SACLs associated with them and so can be audited. As
previously mentioned, you audit Active Directory user and group accounts by auditing
Account Management. However, if you want to audit the modification of objects in other
naming contexts, such as the Configuration and Schema naming contexts, you must
audit for object access, and then define the SACL for the specific containers you wish to
audit. Audit entries are generated when users listed on the SACL of an Active Directory
object attempt to access that object.
You can modify the SACL for containers and objects in the Configuration naming context
(and other naming contexts) using the ADSIEDIT MMC snap-in. This is accomplished by
displaying the required context in the ADSIEDIT console, and then modifying the SACL
for the object in the Advanced Security Settings dialog box.
It is very difficult to find specific events for directory service access due to the large
volume of (generally innocuous) events that take place. For this reason, the Member
Server and Domain Controller Baseline Policies only audit failed events for directory
service access. This will help you identify when an attacker attempts unauthorized
access to Active Directory.
310
Attempted directory access will show as a directory service event with the ID 565 in the
security log. Only by looking at the details of the security event can you determine which
object the event corresponds to.
Contoso is not specifically monitoring for any directory service access events, but is
auditing object access for some files. This information can be extremely helpful when
responding to a security incident.
Privilege Use
As users work in an information technology (IT) environment, they exercise defined user
rights. If you audit Privilege Use for success and failure, an event will be generated each
time a user attempts to exercise a user right.
Even if you do audit Privilege Use not all user rights are audited. By default, the following
user rights are excluded:
●
Bypass traverse checking
●
Debug programs
●
Create a token object
●
Replace process level token
●
Generate security audits
●
Backup files and directories
●
Restore files and directories
You can override the default behavior of not auditing Backup and Restore user rights by
enabling the Audit use of Backup and Restore Privilege security option in Group
Policy.
Auditing for success on Privilege Use will create a very large number of entries in the
security log. For this reason, the Member Server and Domain Controller Baseline Policies
only audit for failure on Privilege Use.
The following events are generated if auditing for Privilege Use is enabled.
Table 9.6: Privilege Use Events That Appear in the Event Log
Event ID
Description
576
Specified privileges were added to a user's access token. (This event is
generated when the user logs on.)
577
A user attempted to perform a privileged system service operation.
578
Privileges were used on an already open handle to a protected object.
311
Here are examples of some of the event log entries that can exist when specific user
rights are used:
●
Act as part of the operating system. Look for Event ID 577 or 578 with the
SeTcbPrivilege access privilege indicated. The user account that made use of
the user right is identified in the event details. This event can indicate a user's
attempt to elevate security privileges by acting as part of the operating system. For
example, the GetAdmin attack, where a user attempts to add their account to the
Administrators group uses this privilege. The only entries for this event should be
for the System account, and any service accounts assigned this user right.
●
Change the system time. Look for Event ID 577 or 578 with the
SeSystemtimePrivilege access privilege indicated. The user account that
used the user right is identified in the event details. This event can indicate a user's
attempt to change the system time to hide the true time that an event takes place.
●
Force shutdown from a remote system. Look for Event IDs 577 and 578 with
user right SeRemoteShutdownPrivilege access privilege indicated. The
specific security identifier (SID) the user right is assigned to and the user name of
the security principal that assigned the right are included in the event details.
●
Load and unload device drivers. Look for Event ID 577 or 578 with the
SeLoadDriverPrivilege access privilege indicated. The user account that
made use of this user right is identified in the event details. This event can indicate
a user's attempt to load an unauthorized or Trojan horse (a type of malicious code)
version of a device driver.
●
Manage auditing and security log. Look for Event ID 577 or 578 with the
SeSecurityPrivilege access privilege indicated. The user account that made
use of this user right is identified in the event details. This event will occur both
when the event log is cleared and when events for privilege use are written to the
security log.
●
Shut down the system. Look for Event ID 577 with the SeShutdownPrivilege
access privilege indicated. The user account that made use of this user right is
identified in the event details. This event will occur when an attempt to shut down
the computer takes place.
●
Take ownership of files or other objects. Look for Event ID 577 or 578 with the
SeTakeOwnershipPrivilege access privilege indicated. The user account that
used the user right is identified in the event details. This event can indicate that an
attacker is attempting to bypass current security settings by taking ownership of an
object.
Contoso is specifically monitoring for any events that indicate a normal shutdown or a
forced shutdown from a remote system as well as any events indicating the auditing and
security log has been modified.
Process Tracking
If you audit detailed tracking information for processes running on Windows 2000-based
computers, the event log will show attempts to create processes and end processes. It
will also record when a process attempts to generate a handle to an object or obtain
indirect access to an object.
Due to the very large number of audit entries created, the Member Server and Domain
Controller Baseline Policies do not enable auditing for process tracking. However, if you
choose to audit for success and failure, the following event IDs will be recorded in the
event log.
312
Table 9.7: Process Tracking Events That Appear in the Event Log
Event ID
Description
592
A new process was created.
593
A process exited.
594
A handle to an object was duplicated.
595
Indirect access to an object was obtained.
Contoso is not monitoring for any process tracking events and has not enabled them in
any of the server policies.
System Events
System events are generated when a user or process alters aspects of the computer
environment. You can audit for attempts to make changes to the system, such as
shutting down the computer or altering the system time.
If you audit system events, you also should audit when the security log is cleared. This is
very important, because attackers will often attempt to clear their tracks after making
changes in an environment.
The Member Server and Domain Controller Baseline Policies audit system events for
success and failure. This will lead to the following event IDs in the event log.
Table 9.8: System Events That Appear in the Event Log
Event ID
Description
512
Windows is starting up.
513
Windows is shutting down.
514
An authentication package was loaded by the Local Security Authority.
515
A trusted logon process has registered with the Local Security Authority.
516
Internal resources allocated for the queuing of security event messages
have been exhausted, leading to the loss of some security event
messages.
517
The security log was cleared.
518
A notification package was loaded by the Security Accounts Manager.
313
You can use these event IDs to capture a number of security issues:
●
Computer Shutdown/Restart. Event ID 513 shows each instance of when
Windows was shut down. It is important to know when servers have been shut
down or restarted. There are a number of legitimate reasons, such as a driver or
application was installed requiring a restart, or the server was shut down or
restarted for maintenance. However, an attacker may also force a restart of a
server in order to gain access to the system during startup. All cases where the
computer is shut down should be noted for comparison with the event log.
Many attacks involve the restart of a computer. By investigating the event logs, you
can determine when a server has been restarted, and whether the restart was a
planned restart, or an unplanned restart. Event ID 513 shows Windows starting up,
as will a series of other events which are automatically generated in the system
log. These would include Event ID 6005, which indicates that the Event Log
service has started.
In addition to this entry, look for the existence of one of two different event log
entries in the system log. If the previous shutdown was clean, such as when an
administrator restarts the computer, then Event ID 6006, the Event Log service
was stopped, is recorded in the system log. By examining the details of the entry,
you can determine which user initiated the shutdown.
If the restart was due to an unexpected restart, an Event ID 6008, the previous
system shutdown at <time> on <date> was unexpected is recorded in the
system log. This can be indicative of a denial of service (DoS) that caused a
shutdown of the computer. But remember, it also can be due to a power failure, or
device driver failure as well.
If the restart was made because of a stop error that resulted in a blue screen, then
Event ID 1001, with a source of Save Dump, is recorded in the system log. The
actual stop error message can be reviewed in the event details.
Note: To include the recording of Event ID 1001 entries, the check box option
Write an event to the system log must be selected to enable the recovery
settings section of the System Control Panel applet.
●
Modifying or Clearing of the Security Log. An attacker may try to modify the
security logs, disable auditing during an attack, or clear the security log to prevent
detection. If you notice large blocks of time with no entries in the security log, you
should look for Event IDs 612 and 517 to determine which user modified the audit
policy. All occurrences of Event ID 517 should be compared to a physical log
indicating all times that the security log was cleared. An unauthorized clearing of
the security log can be an attempt to hide events that existed in the previous
security log. The name of the user that cleared the log is included in the event
details.
Contoso is monitoring for both computer shutdown or restarts and the clearing of the
security log.
314
Policy Change
Your audit policy defines which changes to your environment are audited, helping you to
determine whether there have been attempts to attack your environment. However, a
determined attacker will look to alter the audit policy itself, so that any changes they
make are not audited.
If you audit for policy change, you will show attempts to alter the audit policy, alongside
changes to other policies and user rights. The Member Server and Domain Controller
Baseline Policies audit policy change for success and failure. You will see these events
recorded in the event log.
Table 9.9: Policy Change Events That Appear in the Event Log
Event ID
Description
608
A user right was assigned.
609
A user right was removed.
610
A trust relationship with another domain was created.
611
A trust relationship with another domain was removed.
612
An audit policy was changed.
768
A collision was detected between a namespace element in one forest and
a namespace element in another forest. (Occurs when a namespace
element in one forest overlaps a namespace element in another forest.)
The two most important events to look for here are Event IDs 608 and 609. A number of
attempted attacks may result in these events being recorded. The following examples will
all generate Event ID 608 if the user right is assigned or 609 if it is removed. In each case
the specific SID that the user right is assigned to, along with the user name of the
security principal that assigned the right, is included in the event details:
●
Act as part of the operating system. Look for Event IDs 608 and 609 with user
right seTcbPrivilege in the event details.
●
Add workstations to the domain. Look for the events with user right
SeMachineAccountPrivilege in the event details.
●
Back up files and directories. Look for the events with user right
SeBackupPrivilege in the event details.
●
Bypass traverse checking. Look for events with user right
SeChangeNotifyPrivilege in the event details. This user right allows users to
traverse a directory tree even if the user has no other permissions to access that
directory.
●
Change the system time. Look for events with user right
SeSystemtimePrivilege in the event details. This user right allows a security
principal to change the system time, potentially masking when an event takes
place.
●
Create permanent shared objects. Look for events with user right
SeCreatePermanentPrivilege in the event details. The holder of this user
right can create file and print shares.
●
Debug Programs. Look for events with user right SeDebugPrivilege in the
event details. A holder of this user right can attach to any process. This right is, by
default, only assigned to administrators.
●
Force shutdown from a remote system. Look for events with user right
SeRemoteShutdownPrivilege in the event details.
315
●
Increase scheduling priority. Look for events with user right
SeIncreaseBasePriorityPrivilege in the event details. A user with this
right can modify process priorities.
●
Load and unload device drivers. Look for events with user right
SeLoadDriverPrivilege in the event details. A user with this user right could
load a Trojan horse version of a device driver.
●
Manage auditing and security log. Look for events with user right
SeSecurityPrivilege in the event details. A user with this user right can view
and clear the security log.
●
Replace a process level token. Look for events with user right
SeAssignPrimaryTokenPrivilege in the event details. A user with this user
right can change the default token associated with a started subprocess.
●
Restore files and directories. Look for events with user right
SeRestorePrivilege in the event details.
●
Shut down the system. Look for events with user right SeShutdownPrivilege
in the event details. A user with this user right could shut down the system to
initialize the installation of a new device driver.
●
Take ownership of files or other objects. Look for events with user right
SeTakeOwnershipPrivilege in the event details. A user with this user right can
access any object or file on an NTFS file system disk by taking ownership of the
object or file.
Note: These audit events only identify that the user right was assigned to a specific
security principal. It does not mean that the security principal has performed a task
using the user right. The audit events do determine when the user right policy was
modified.
Contoso is not currently monitoring any policy change events. These events will be
utilized for any troubleshooting or incident response.
Monitoring changes to group policies can be very difficult and provide numerous false
alerts. This is primarily because the MMC snap-in for editing group policies, gpedit.msc,
always opens policies with both read and write privileges. Even if no changes are made
to the policy event 578 is written to the domain controller’s security log as shown below.
The Group Policy Management Console, released as a free download shortly after
Windows Server 2003 shipped, helps to overcome these issues by allowing authorized
users to view group policy settings without having to open them in gpedit.msc. For more
information about the Group Policy Management Console see:
http://www.microsoft.com/windowsserver2003/gpmc/gpmcwp.mspx.
316
Protecting Event Logs
To ensure that the event log entries are maintained for future reference, you should take
a number of steps to protect the security of the event logs. These should include:
●
Defining a policy for the storage, overwriting and maintenance of all event logs.
The policy should define all required event log settings and be enforced by Group
Policy.
●
Ensuring that the policy includes how to deal with full event logs, especially the
security log. It is recommended that a full security log require the shutdown of the
server. This may not be practical for some environments, but you should certainly
consider it.
●
Preventing guest access to the event logs by enabling the security policy settings
to prevent local guests from accessing the system, application, and security logs.
●
Ensuring that the system events are audited for both success and failure to
determine whether any attempts are made to erase the contents of the security
log.
•
Enforcing use of complex passwords or two factor authentication methods such as
smart card logon by all security principals that have the ability to view or modify
audit settings to prevent attacks against these accounts to gain access to audit
information.
Contoso implemented these settings in the Member Server and Domain Controller Group
Policy Objects. For details on these settings, see Chapter 6, "Hardening the Base
Windows 2000 Server", and Chapter 7, "Hardening Specific Server Roles."
In addition to these steps, you should take the following practical measures to ensure that
your event log information is as safe as possible:
●
Ensure that your security plan includes physical security of all servers to prevent
an attacker from gaining physical access to the computer where auditing is
performed. An attacker can remove audit entries by modifying or deleting the
physical *.evt files on the local disk subsystem.
●
Implement a method to remove or store the event logs in a location separate from
the physical server. These can include using Scheduled Tasks to write the event
logs to CD-R or write once, read many media at regular intervals, or to other
network locations separate from the server. If the backups are copied to external
media such as backup tapes, or CD-R media, the media should be removed from
the premises in the event of fire or other natural disasters.
Note: Preventing guest access to event logs only restricts non-domain members from
accessing the event logs. By default, all users in a domain can access the system and
application logs. Only access to the security log is restricted. Security principals that
are assigned the user right Manage auditing and security log can access the
security log. By default, this is only assigned to Administrators and Exchange
Enterprise Servers.
317
Other Auditing Best Practices
In addition to configuring auditing, there are other practices that should be implemented
to effectively audit the security of your server environment. These include:
●
Scheduling regular review of the event logs.
●
Reviewing other application log files.
●
Monitoring installed services and drivers.
●
Monitoring open ports.
Scheduling Regular Review of the Event Logs
As mentioned previously, the security log and potentially the other event logs should be
written to either removable material or consolidated to a central location for review.
Reviewing the logs is often the most frequently missed auditing step.
Contoso has done a great amount of work to ensure that there is either a single person or
a team responsible for reviewing the event logs as a regular task. Such a review of event
logs can be scheduled as a daily or weekly event, depending on the amount of data that
is collected in the security log. This is typically based on the level of auditing implemented
on the network. If more events are included in the audit, the volume of log entries will be
larger. If you schedule regular event log reviews you will help achieve the following:
318
●
Faster detection of security issues. If daily review of the event logs is
performed, a security event should never be older than 24 hours. This leads to
faster detection and repair of security vulnerabilities.
●
Define responsibility. If regular review of event logs is required, the person
tasked with reviewing the log files can be ultimately responsible for identifying
potential attacks.
●
Reduces the risk of events being overwritten or server down. Once an event
log is reviewed, the events in the log file can be archived for future review, and
removed from the current event log. This practice reduces the risk of the event logs
becoming full.
Reviewing other Application Log Files
In addition to reviewing the Windows 2000 event logs for security events, you should also
review the logs created by applications. The application logs may include valuable
information regarding potential attacks that can supplement the information found in the
event logs. Depending on your environment, you may need to look at one or more of
these log files:
●
Internet Information Services (IIS). IIS creates log files that track connection
attempts to Web, File Transfer Protocol (FTP), network time protocol (NTP), and
Simple Mail Transfer Protocol (SMTP) services. Each service running under IIS
maintains separate log files, and stores the log files in the World Wide Web
Consortium (W3C) Extended Log File Format in the %WinDir%\System32\Logfiles
folder. Each service maintains a separate folder to further break down the logging
information. Alternatively, you can configure IIS to store the logs into an Open
Database Connectivity (ODBC)–compliant database, such as Microsoft® SQL
Server™.
●
Microsoft® Internet Security and Acceleration (ISA) Server. ISA Server provides
logs for packet filters, the ISA Server Firewall Service, and the ISA Server Web
Proxy Service. As with IIS, the logs are stored in the W3C Extended Log File
Format by default but can be recorded to an ODBC-compliant database as an
alternative. The ISA Server log files are stored in the C:\Program Files\Microsoft
ISA Server\ISALogs folder by default.
●
Internet Authentication Service (IAS). IAS provides centralized authentication
and accounting for remote access authentication using the Remote Authentication
Dial-In User Service (RADIUS) protocol. By default, accounting requests,
authentication requests, and periodic status requests are logged to the IASlog.log
file located in the %WinDir%\System32\Logfiles folder. Alternatively, the log file
can be saved in a database compatible file format, rather than in IAS format.
●
Third-Party Applications. Several third-party applications implement local logging
functions to provide detailed information about the application. For more
information, see the specific help files for your application.
Note: All computers that maintain log files should use synchronized clocks. This allows
an administrator to compare events between computers and services to establish what
actions were taken by an attacker. For more details on time synchronization, see the
Importance of Time Synchronization section later in this chapter.
Monitoring Installed Services and Drivers
Many attacks against a computer are implemented by attacking services installed on the
target computer, or by replacing valid drivers with versions of the driver that include a
Trojan horse, allowing an attacker access to the target computer.
The following tools can be used to monitor the installed services and drivers on your
computers:
●
The Services Console. The Services MMC console is used to monitor the
services of either the local computer or a remote computer and allows an
administrator to configure, pause, stop, start, and restart all installed services. Use
this console to determine whether any services configured to start automatically
are not currently started.
●
Netsvc.exe. This command line tool, included in the Windows 2000 Server
Resource Kit, allows an administrator to remotely start, stop, pause, continue, and
query the status of services from the command line.
319
●
SvcMon.exe. The Service Monitoring Tool monitors services on local and remote
computers for changes in state (starting or stopping). To detect these changes, the
tool implements a polling system. When a monitored service stops or starts, the
tool notifies you by sending e-mail. You must configure the servers, polling
intervals, and services to monitor by using the Service Monitor Configuration Tool
(smconfig.exe).
●
Drivers.exe. This tool displays all installed device drivers at the computer where
the tool is executed. The output of the tool includes information that includes the
driver's file name, the size of the driver on disk, and the date that the driver was
linked. The link date can be used to identify any newly installed drivers. If an
updated driver was not recently installed, this can indicate a replaced driver.
Always correlate this information with a system restart event in the Event Viewer.
Note: Not all services (such as the Workstation service) can be stopped directly,
although you can query them. If the user has a lot of active connections, you cannot
force the service to shut down remotely, although you can pause or query it. Some
services have other services that are dependent on them; trying to shut down such
services will fail unless the dependent services are shut down first.
Monitoring Open Ports
Attacks are often started by performing a port scan to identify any known services
running on the target computer. You should make sure that you carefully monitor which
ports are open on your servers, which generally means scanning the ports yourself to
determine what can be accessed.
When performing port scans, you should perform them both locally at the target
computer, and from a remote computer. If the computer can be accessed from a public
network, the port scan should be performed from an external computer to ensure that
your firewall software only allows access to desired ports.
Netstat.exe is a command line utility that can show all open ports for both Transmission
Control Protocol (TCP) and User Datagram Protocol (UDP). The Netstat command uses
the following syntax:
NETSTAT [-a] [-e] [-n] [-s] [-p proto] [-r] [interval]
Where:
●
320
-a. Displays all connections and listening ports.
●
-e. Displays Ethernet statistics. This may be combined with the -s option.
●
-n. Displays addresses and port numbers in numerical form.
●
-p proto. Shows connections for the protocol specified by proto; proto may be TCP
or UDP. If used with the -s option to display per protocol statistics, proto may be
TCP, UDP, or Internet Protocol (IP).
●
-r. Displays the routing table.
●
-s. Displays per protocol statistics. By default, statistics are shown for TCP, UDP
and IP; the -p option may be used to specify a subset of the default.
●
interval. Redisplays selected statistics, pausing interval seconds between each
display. Press CTRL+C to stop redisplaying statistics. If omitted, Netstat will print
the current configuration information once.
When you list the open TCP and UDP ports at the local computer, port numbers are
translated to names based on the entries in the services file found in the
\%WinDir%\System32\Drivers\Etc\ folder. If you prefer to only see port numbers, you can
use the -n switch.
If any open ports are discovered that are not recognized, you should investigate them to
determine whether the corresponding service is needed on the computer. If it is not, you
should disable or remove the associated service to prevent the computer from listening
on that port. A number of services have been disabled in the Member Server and Domain
Controller Baseline Policies included with this guide.
Because many servers are protected by firewalls, or packet filtering routers, it is also
recommended to perform the port scan from a remote computer. Many third-party tools
(including some freeware) are available that can do remote port scans. The remote port
scan reveals which ports are available to external users when they attempt to connect to
the computer.
Note: Port scanning can also be used to test your intrusion detection system to ensure
that it detects the port scan as it is taking place. For more information about intrusion
detections systems, see the Active Detection Methods section later in this chapter.
321
Monitoring for Intrusion and Security Events
Monitoring for intrusion and security events includes both passive and active tasks. Many
intrusions are detected after the attack has taken place through the inspection of log files.
This post-attack detection is often referred to as passive intrusion detection. Only through
inspection of the log files can the attack be reviewed and reconstructed based on the log
information.
Other intrusion attempts can be detected as the attack takes place. This methodology,
known as active intrusion detection, looks for known attack patterns or commands, and
blocks the execution of those commands.
This section will look at tools that can be used to implement both forms of intrusion
detection to protect your network from attacks.
Importance of Time Synchronization
When monitoring for both intrusion and security events between multiple computers, it is
essential that the computers' clocks are synchronized. Synchronized time allows an
administrator to reconstruct what took place during an attack against multiple computers.
Without synchronized time, it is very difficult to determine exactly when specific events
took place, and how events interlace. More detailed information about time
synchronization can be found in Chapter 5, "Securing the Domain Infrastructure."
Passive Detection Methods
Passive intrusion detection systems involve the manual review of event logs and
application logs. The inspection involves analysis and detection of attack patterns in
event log data. There are several tools, utilities, and applications that can help review
event logs. This section outlines how each tool can be used to coordinate information.
322
Event Viewer
The Windows 2000 security log can of course be viewed using the Windows 2000 Event
Viewer MMC console. Event Viewer allows you to view the application, security, and
system logs. You can define filters to find specific events in the Event Viewer.
XTo define filter in the Event Viewer
1. Select the specific event log in the console tree.
2. Select Filter from the view menu.
3. Select the parameters for filtering.
In the Filter tab of the Properties dialog box, you can define the following attributes to
filter event entries:
●
Event types. The filter can be limited to information, warning, error, success
audits, failure audits, or any combination of the event types.
●
Event source. The specific service or driver that generated the event.
●
Category. The filter can be limited to specific categories of events.
●
Event ID. If you know the specific Event ID that you are searching for, the filter can
limit the listing to that specific Event ID.
●
User. You can limit the event display to events generated by a specific user.
●
Computer. You can limit the event display to events generated by a specific
computer.
●
Date Intervals. You can limit the display to events that fall between specific
beginning and ending dates.
When the filter is applied, the filtered event list can be exported to either a comma
separated or tab separated listing for import into a database application.
As mentioned previously, Contoso has several individuals for each administrative role
that are responsible for reviewing event logs. As part of this, they review the logs on a
daily basis for any security related events that were not logged by the monitoring system.
Dump Event Log Tool (Dumpel.exe)
Dump Event Log is a command-line tool, included in the Windows 2000 Server Resource
Kit, Supplement One (Microsoft Press, ISBN: 0-7356-1279-X). It will dump an event log
for a local or remote system into a tab separated text file. This file could then be imported
into a spreadsheet or database for further investigation. The tool can also be used to filter
for or filter out certain event types.
The following syntax is used by the dumpel.exe tool:
dumpel -f file [-s \\server] [-l log [-m source]] [-e n1 n2 n3...] [-r] [-t] [-d
x]
323
Where:
●
-f file. Specifies the file name for the output file. There is no default for -f, so you
must specify the file.
●
-s server. Specifies the server for which you want to dump the event log. Leading
backslashes on the server name are optional.
●
-l log. Specifies which log (system, application, security) to dump. If an invalid log
name is specified, the application log is dumped.
●
-m source. Specifies in which source (such as redirector (rdr), serial, and so on) to
dump records. Only one source can be supplied. If this switch is not used, all
events are dumped. If a source is used that is not registered in the registry, the
application log is searched for records of this type.
●
-e n1 n2 n3. Filters for event ID nn (up to 10 can be specified). If the -r switch is
not used, only records of these types are dumped; if -r is used, all records except
records of these types are dumped. If this switch is not used, all events from the
specified sourcename are selected. You cannot use this switch without the -m
switch.
●
-r. Specifies whether to filter for specific sources or records, or to filter them out.
●
-t. Specifies that individual strings are separated by tabs. If -t is not used, strings
are separated by spaces.
●
-d x. Dumps events for the past x days.
Note: Dumpel can only retrieve content from the system, application, and security log
files. You cannot use Dumpel to query content from the File Replication Service,
Domain Name System (DNS), or Directory Service event logs.
EventCombMT
EventCombMT is a multi-threaded tool that will parse event logs from many servers at
the same time, spawning a separate thread of execution for each server that is included
in the search criteria. EventCombMT is included with the Microsoft Windows Server 2003
Resource Kit Tools, for more information see:
http://www.microsoft.com/windowsserver2003/techinfo/reskit/resourcekit.mspx.
The tool allows you to:
324
●
Define either a single Event ID, or multiple Event IDs to search for. You can
include a single event ID, or multiple event IDs separated by spaces.
●
Define a range of Event IDs to search for. The endpoints are inclusive. For
example, if you want to search for all events between and including Event ID 528
and Event ID 540, you would define the range as 528 > ID < 540. This feature is
useful because most applications that write to the event log use a sequential range
of events.
●
Limit the search to specific event logs. You can choose to search the system,
application, and security logs. If executed locally at a domain controller, you can
also choose to search FRS, DNS, and AD logs.
●
Limit the search to specific event message types. You can choose to limit the
search to error, informational, warning, success audit, failure audit, or success
events.
●
Limit the search to specific event sources. You can choose to limit the search
to events from a specific event source.
●
Search for specific text within an event description. With each event, you can
search for specific text. This is useful if you are trying to track specific users or
groups.
Note: You cannot include search logic, such as AND, OR, or NOT in the specific
text. In addition, do not delimit text with quotes.
●
Define specific time intervals to scan back from the current date and time.
This allows you to limit your search to events in the past week, day, or month.
Installing the Tool
To install the tool, extract the contents of the self extracting SecWin2k.exe file included
with this guide. This will create a C:\SCI\scripts\EventComb folder. Once the files are
extracted, you can run the EventCombMT tool by double-clicking the EventCombMT.exe
file.
Running the EventComb Tool
The first step in using the EventComb tool is defining which computers will be included in
the event log search.
325
XTo add computers to the search
1. In the EventCombMT utility, ensure that the correct domain is autodetected in the
domain box. If you wish to search event logs in a different domain, then manually
type the new domain name in the Domain box.
2. To add computers to the search list, right-click the box below Select To
Search/Right Click to Add. The pop-up menu shown in the following figure:
Figure 9.1
Using the EventCombMT dialog box settings to add computers not autodetected to the search list
The following options are available:
●
Get DCs in Domain. Adds all domain controllers for the current domain to the
listing.
●
Add Single Server. Allows you to add a server or workstation by name to the
listing.
●
Add all GCs in this domain. Allows you to add all domain controllers in the
selected domain that are configured to be global catalog servers.
●
Get All Servers. Adds all servers found in the domain using the browser
service. The servers exclude all domain controllers.
●
Get Servers from File. Allows you to import a file that lists all servers to be
included in the search scope. Each server should be entered on a separate
line in the text file.
3. Once the servers are added to the list, you must select which servers to perform
the search against. When selected, the server will appear highlighted in the list.
You can choose multiple servers, using a CTRL+click combination.
326
Specifying the Event Logs and Event Types to Search
Once you have selected the servers to be included in your event log search, you can
narrow the scope of the search by selecting which event logs and event types to include.
In the EventCombMT utility, you can select from the following event logs for the search:
●
System
●
Application
●
Security
●
FRS (File Replication Service Log)
●
DNS (DNS Server log)
●
AD (Directory Service log)
You can also select the following Event types to include in the search:
●
Error. This event is recorded in the application and system logs, and also appears
in the FRS, DNS, and Directory Services logs.
●
Informational. This event is recorded in the application and system logs, and also
appears in the FRS, DNS, and Directory Services logs.
●
Warning. This event is recorded in the application and system logs, and also
appears in the FRS, DNS, and Directory Services logs.
●
Success Audit. This event occurs in the security log or in the application log if the
application registers success audits to the application log. For example, Active
Directory Migration Tool (ADMT) logs success audit events to the application log.
●
Failure Audit. This event occurs in the security log or in the application log if the
application registers failure audits to the application log. For example, ADMT logs
failure audit events to the application log.
●
Success. This event is very rare and is found in the application or system logs,
and also appears in the FRS, DNS, and Directory Services logs. In event viewer,
success events are displayed as informational event type.
Note: If you are aware of the specifics of which event log an event ID appears in, and
the event type of the event ID, always include this information in your search criteria as
it reduces the time for the search.
Saving Searches
EventCombMT allows you to save searches and reload them later. This can be useful if
you frequently use EventCombMT to search your IIS servers for one set of events and
your domain controllers for another.
Search criteria are saved in the registry under:
HKLM\Software\Microsoft\EventCombMT and can be easily edited.
Search Result Files
The results of the search are saved to the C:\Temp folder by default. The results include
a summary file named EventCombMT.txt and for each computer included in the event log
search, a separate text file named ComputerName-EventLogName_LOG.txt is
generated. These individual text files contain all the events extracted from the event logs
that match your search criteria.
327
Examples of Using EventCombMT
To show how EventCombMT can be used, we will show how the tool can be configured
to detect domain controller restarts and account lockouts.
XTo use EventCombMT to search for restarts of domain controllers
1. In the EventCombMT tool, ensure that the domain is configured to the correct
domain name.
2. In the Select to Search/Right Click to Add box below the domain name, right
click the box, and then click Get DCs in Domain.
Note: When searching for events such as Account Logon and Account
Management events, ensure that you search all domain controllers. Because
Windows 2000 uses a multimaster model for account management, an account
can be added, modified, or deleted at any domain controller in the domain.
Likewise, authentication can be validated by any domain controller in the domain.
Because of this, you cannot be sure where the specific update or authentication
attempt takes place.
3. Right-click the Select to Search/Right Click to Add box, and then click Select All
Servers in List.
4. In the Choose Log Files to search section of the tool, select the System log only.
5. In the Event Types section of the tool, select Error and Informational.
6. In the Event IDs box, type the following Event IDs: 1001 6005 6006 6008.
7. Before clicking the Search button, ensure that your search criteria is defined as
shown in the figure below, and then click Search.
Figure 9.2
Defining search criteria in the Event Comb MT dialog box
328
When the search is completed, the results can be viewed in the log directory, which
should open automatically when the search is complete.
XTo review the log entries
1. From the File menu, select Open Log Directory.
2. In the C:\Temp folder, double-click the output file for a domain controller to view the
specific events logged by the EventCombMT tool. You should see output similar to
the following:
1001,INFORMATIONAL,Save Dump,Wed Nov 28 05:45:50 2001,,The computer has
rebooted from a bugcheck. The bugcheck was: 0x000000d1 (0x00000004,
0x00000002, 0x00000000, 0x84c983dc). A dump was saved in:
C:\WINDOWS\MEMORY.DMP.
6005,INFORMATIONAL,EventLog,Wed Nov 28 05:45:46 2001,,The Event log service
was started.
6008,ERROR,EventLog,Wed Nov 28 05:45:46 2001,,The previous system shutdown at
5:33:47 AM on 11/28/2001 was unexpected.
6005,INFORMATIONAL,EventLog,Tue Nov 27 14:10:53 2001,,The Event log service
was started.
6006,INFORMATIONAL,EventLog,Tue Nov 27 14:09:26 2001,,The Event log service
was stopped.
6005,INFORMATIONAL,EventLog,Tue Nov 27 10:11:37 2001,,The Event log service
was started.
The 6006 event indicates a planned shutdown initiated by a user with the user rights to
shutdown the domain controller. The 6005 event indicate that the event log service was
started. This occurs at start up time.
The 6008 and 1001 events indicate that the computer was either powered off without
shutting down, or restarted because it locked up, or experienced a stop error. If a 1001
event exists, a stop error did occur, and the associated debug information and reference
to the debug file is included.
The events returned by the EventCombMT tool should be cross-checked with known
down time, and nonmatching events should be researched to ensure that the server has
not been attacked.
EventCombMT includes several preconfigured searches that can be used to search for
security events. For example, there is a predefined search that searches for Account
Lockout events.
329
XTo use EventCombMT to search for Account Lockouts
1. In the EventCombMT tool, ensure that the domain is configured to the correct
domain name.
2. In the Select to Search/Right Click to Add box below the domain name, right
click the box, and then click Get DCs in Domain.
3. Right-click the Select to Search/Right Click to Add box, and then click Select All
Servers in List.
4. From the Searches menu, click Built In Searches, and then click Account
Lockouts. The EventCombMT utility is configured as shown in the following figure:
5. Click Search.
6. When the search is completed, the results can be viewed in the log directory,
which should open automatically when the search is complete.
Note: Other predefined searches that are included with EventcombMT include File
Replication Services searches, Active Directory searches for duplicate SIDs and
NETLOGON DNS registration failures, Hardware disk errors, and DNS interface errors.
You can also define and save your own custom searches.
Contoso uses EventCombMT in cases where they are trying to diagnose problems or
determine causes of issues during an incident response. Additionally, they routinely
check for account lockouts or bad password across all domain controllers. Doing so helps
them manually identify any odd patterns that a monitoring system may not detect.
Event Collection
One of the main goals of auditing is to identify the actions taken by attackers on your
network. An attacker may attempt to compromise multiple computers and devices on the
network. Therefore, to understand the extent of any attack, you must be able to
coordinate and consolidate information from many computers.
If your log utilities will import into a database, it is easier to coordinate the information
from multiple logs. As long as your time is synchronized across all computers, you can
sort on time fields, and ease the tracking of events based on time intervals.
The following sections outline some of the tools and utilities that you can use to collect
event log information into a central location.
Scripting
Scripts can be written that collect event log information from remote computers and store
it in a central location. By using scripting, you can choose when to run the scripts using
Scheduled Tasks and what actions to take once the event log is successfully copied to
the central location.
A simple example would be to create a batch file that uses Dumpel.exe from the
Windows 2000 Server Resource Kit, and launch the batch file at regular intervals using
Scheduled Tasks in Control Panel.
The Windows 2000 Resource Kit, Supplement One includes Eventquery.pl. This is a Perl
script that displays events from the Event Viewer logs on local and remote computers
running Windows 2000 and offers a wide range of filters to help you find specific events.
Note: To use this script, you will need to install ActivePerl from the Windows 2000
Server Resource Kit.
330
Contoso currently does not utilize an event collection solution. However, it is expecting to
utilize the Microsoft Audit Collection System (MACS), which will be released in the
upcoming year. MACS is a security event collection tool that collects events in a secure
manner utilizing compression, signing, and encryption. After gathering the events, they
are loaded into a SQL database and optimized for analysis.
Microsoft Operations Manager
Microsoft Operations Manager (MOM) 2000 offers a comprehensive set of tools that
allow enterprises to thoroughly analyze the built-in event reporting and performance
monitoring of Windows 2000 and its applications. MOM 2000 can collect, store, and
report events and performance data to a single location through the use of Intelligent
Agents at remote computers, allowing an administrator to centrally review the collected
information.
The core MOM 2000 management pack collects events that appear in the system,
application and security event logs, and aggregates the results into a central event
repository.
Note: MOM 2000 stores its information in a SQL Server database, and offers several
methods to retrieve and analyze the archived data. Administrators can use the
Operations Manager Administrator Console, Web Console, or Operations Manager
Reporting to view, print, or publish the data. Each view includes predefined views for
analyzing the archived data, and allows for customized views and reports to be
defined.
Third-Party Solutions for Event Log Collection
Several third-party products are available that offer centralized collection and inspection
of event logs. As you evaluate third-party products, include the following features in your
criteria:
●
Support for all Windows 2000 logs. Support for the DNS Server, Directory
Service, and FRS logs, in addition to the application, security, and system logs
should be provided.
●
Use of a Database Backend. The tool should allow the event logs to be stored in
a database structure that allows inspection of previous event log entries for trend
analysis and correlation of events between multiple servers.
●
Search and Reporting Functionality. The tool should allow you to search for
specific events based on provided criteria. The results should be presented in a
readable manner.
Third-party products that provide event collection ability include:
●
Event Log Monitor — TNT Software (www.tntsoftware.com)
●
Event Archiver — Dorian Software Creations (www.doriansoft.com)
●
LogCaster — RippleTech (www.rippletech.com)
331
Active Detection Methods
Active intrusion detection systems analyze incoming network traffic at the application
layer, looking for well known attack methods or suspicious application layer payloads. If a
suspicious packet is received, the intrusion detection system will typically drop the
packet, and log an entry into a log file. Some intrusion detection systems can also alert
an administrator if a severe attack is detected.
Third-Party Solutions for Intrusion Detection
Third-party solutions exist for both network and end point intrusion detection systems.
These third-party solutions provide support for protocols other than Hypertext Transfer
Protocol (HTTP) and also scan for well known attacks against networked computers.
The common types of attacks that intrusion detection systems should identify include:
●
Reconnaissance attacks. These occur when an intruder is staking out a network,
looking for vulnerabilities. Potential attacks include ping sweeps, DNS zone
transfers, e-mail reconnaissance, port scans, and download of Web site content to
look for vulnerable scripts and sample pages.
●
Exploit attacks. These occur when intruders take advantage of hidden features or
bugs to gain access to the system. Most often, the attack points were identified by
a previous exploit attack.
●
Denial of service (DoS) attacks. These occur when an intruder attempts to crash
a service running on a computer by overloading a resource, such as network links,
the CPU, or the disk subsystem. The intruder is not trying to gain information, but
is attempting to disable your computer from usage.
A good intrusion detection system should be able to identify all three forms of attacks.
Two different methods are used to identify attacks:
●
Anomaly detection. This method takes a baseline of a computer on the network.
Deviations from the baseline can identify an intrusion attempt. For example, an
increase in logon attempts at off-peak hours can identify a compromised computer.
The advantage of anomaly detection is that it can identify attacks without
understanding exactly how the attack takes place.
●
Signature recognition. This method identifies attacks based on well known
patterns. Many Web server attacks use common patterns that are easily
identifiable. By comparing incoming application traffic to signature strings in a
database, an instruction detection system can identify these attacks. The
disadvantage of this method of intrusion detection is that the signature database
must frequently be updated to identify new attack signatures.
Some third-party products available for testing and deployment include:
332
●
BlackIce Defender (http://www.iss.net/products_services/hsoffice_protection/)
●
Cisco Secure IDS
(http://www.cisco.com/warp/public/cc/pd/sqsw/sqidsz/prodlit/netra_ds.htm)
●
eTrust Intrusion Detection (http://www3.ca.com/Solutions/Product.asp?ID=163)
●
Snort (www.snort.org)
●
Tripwire (www.tripwiresecurity.com)
●
Foundstone Attacker (www.foundstone.com)
Vulnerability Assessment
In addition to performing passive and active intrusion detection, you should also perform
periodic vulnerability assessments. Vulnerability assessments simulate an attack on your
network and detect the vulnerabilities that an attacker would find.
By performing periodic assessments you can find vulnerabilities before an attacker does
and secure the weakened portion of your network to protect against the vulnerability.
When researching vulnerability assessment tools, include the following requirements in
your decision making process:
●
Automated database update mechanism. The tool should provide an automated
method to update the signatures for vulnerabilities so that the tool is not out of date
after a short time.
●
A filter to minimize false positives. The tool should filter out false positives so
that an organization does not waste time investigating non-security events.
●
Ability to store results in a database. The tool should allow archiving of scan
results to perform trend analysis and detect changes in security over time.
●
Solutions to vulnerabilities. If a vulnerability is found, the tool should provide
documentation on how to fix the vulnerability or provide scripts that perform the
tasks to protect against it.
Several third-party tools exist to perform vulnerability assessments against a
Windows 2000 network. These tools include:
●
Symantec NetRecon 3.5 (http://enterprisesecurity.symantec.com/)
●
BindView Security Advisor (www.bindview.com)
●
eEye Digital Security. Retina Network Security Scanner (http://www.eeye.com)
●
Internet Security Systems (ISS) Internet Scanner (www.iss.net)
●
Symantec Enterprise Security Manager 5.5
(http://enterprisesecurity.symantec.com/products/products.cfm?ProductID=45)
Alternatively, it may be more appropriate to bring in a third-party consulting service to
perform the vulnerability assessment. The advantage of using a third-party service is that
they have no previous knowledge of the network and will be working from the same
starting point as an external attacker. Many times, these external assessments will
provide the most useful information, based on the neutrality of the assessment team.
333
Summary
Auditing and intrusion detection is a major part of building an effective defense for your
environment. As part of your risk management process, you should determine how much
auditing and intrusion detection is appropriate for your environment. For intrusion
detection across multiple protocols, you may wish to consider third-party tools.
More Information
For more information about the use of user rights, see Writing Secure Code by Michael
Howard and David LeBlanc (Microsoft Press, ISBN: 0-7356-1588-8).
ISA Server Partners Information: http://www.microsoft.com/isaserver/partners
ISA Server Solution Developers Kit (SDK):
http://www.microsoft.com/isaserver/techinfo/productdoc/2000/SDKdownload.asp
For more information about the Group Policy Management Console see:
http://www.microsoft.com/windowsserver2003/gpmc/gpmcwp.mspx.
334
10
Responding to Incidents
How prepared is your information technology (IT) department to handle a security
incident? Many organizations only learn how to respond to a security incident after
suffering an attack. By this time, the incident may have proved much more costly than is
necessary. Proper incident response should be an integral part of your overall security
policy and risk mitigation strategy.
There are clearly direct benefits in responding to security incidents. However, there may
also be indirect financial benefits. For example, your insurance company may offer
discounts if you can demonstrate that your organization is normally able to quickly and
cost-effectively handle attacks. Or, if you are a service provider, a formal incident
response plan might help win business, because it shows that you take seriously the
process of good information security.
This chapter will provide you with a process and procedures to use when responding to
intrusions identified in a Microsoft® Windows® 2000 Server-based environment. The
value of forming a security incident response team with explicit team member roles is
explained, as well as how to define a security incident response plan. A case study also
provides the context to help illustrate how to best apply this process and the related
procedures to your organization.
335
Minimizing the Number and Severity of Security
Incidents
In most areas of life, prevention is better than cure, and security is no exception.
Wherever possible, you will want to prevent security incidents from happening in the first
place; this has already been covered in chapters 5 through 8. However, it is impossible to
prevent all security incidents, so when a security incident does happen, you will need to
ensure that its impact is minimized. There are prudent measures that you can take to
minimize the number and impact of security incidents. These include both preventative
and responsive measures:
336
●
Clearly establishing and enforcing all policies and procedures. Many security
incidents are accidentally created by IT personnel who have not followed or
understood change management procedures or have improperly configured
security devices, such as firewalls and authentication systems. Your policies and
procedures should be thoroughly tested to ensure that they are practical and clear
and provide the appropriate level of security.
●
Gaining management support for security policies and incident handling.
●
Routinely assessing for vulnerabilities in your environment. This should be done by
a security specialist with special clearance to perform these actions.
●
Routinely checking servers to ensure that they have all of the latest patches
installed.
●
Establishing security training programs for both IT staff and end users. The largest
vulnerability in any system is the naïve user—the ILOVEYOU worm effectively
exploited that vulnerability among IT staff and end users.
●
Posting security banners that remind users of their responsibilities and restrictions,
along with a warning of potential prosecution for violation. Without such banners it
may be difficult or impossible to prosecute attackers. You should obtain legal
advice to ensure that the wording of your security banners is appropriate.
●
Developing, implementing, and enforcing a policy requiring complex passwords.
Information on complex password security options and best practices is detailed in
Chapter 5, "Securing the Domain Infrastructure."
●
Routinely monitoring and analyzing network traffic and system performance.
●
Routinely checking all logs and logging mechanisms. These would include
operating system event logs, application specific logs and intrusion detection
system logs.
●
Verifying your back up and restore procedures. You should be aware of where
backups are maintained, who can access them, and your procedures for data
restoration and system recovery. Make sure that you regularly verify backups and
media by selectively restoring data.
●
Creating a Computer Security Incident Response Team (CSIRT). This is a group of
people with responsibilities for dealing with any security incident. Your CSIRT
should consist of members whose duties are clearly defined to ensure that no area
is left uncovered in your response (more details on assembling a CSIRT can be
found later in this chapter).
●
Training members of your CSIRT on proper use and location of critical security
tools. You should also consider providing portable computers that are
preconfigured with these tools to ensure that no time is wasted installing and
configuring tools to respond to an incident. These systems and the associated
tools must be properly protected when not in use.
●
Assembling all relevant communication information. You should ensure that you
have contact names and phone numbers for people within your organization who
need to be notified (including members of the CSIRT, those responsible for
supporting all of your systems, and those in charge of media relations). You will
also need details for your Internet service provider (ISP) and local and national law
enforcement agencies. Consider contacting local law enforcement before an
incident happens. This will help you to ensure that you understand proper
procedures for communicating incidents and collecting evidence.
●
Placing all emergency system information in a central, offline location, such as a
physical notebook or an offline computer. This emergency information includes
passwords to systems, Internet Protocol (IP) addresses, router configuration
information, firewall rule set lists, copies of certificate authority keys, contact
names and phone numbers, escalation procedures, and so on. This information
must both be kept extremely physically secure and be readily available. One
method of securing and making this information readily available is to encrypt it on
a dedicated security portable computer that is placed in a secure vault and limit
access to the vault to authorized individuals such as the CSIRT leader and the CIO
or CTO.
Assembling the Core Computer Security Incident
Response Team
The CSIRT is the focal point for dealing with computer security incidents in your
environment. Its responsibilities include:
●
Monitoring systems for security breaches.
●
Serving as a central communication point, both to receive reports of security
incidents and to disseminate vital information to appropriate entities about the
incident.
●
Documenting and cataloging security incidents.
●
Promoting security awareness within the company to help prevent incidents from
occurring in your organization.
●
Supporting system and network auditing through processes such as vulnerability
assessment and penetration testing.
●
Keeping up with new vulnerabilities and attack strategies employed by attackers.
●
Keeping up with new software patches.
●
Analyzing and developing new technologies for minimizing security vulnerabilities
and risks.
●
Providing security consulting services.
●
Continually honing and updating current systems and procedures.
The ideal CSIRT membership and structure depends on the type of your organization
and your risk management strategy. However, the CSIRT should generally form part or
all of your organization's security team. Inside the core team are security professionals
responsible for coordinating a response to any incident. The number of members in the
CSIRT will typically depend on the size and complexity of your organization. However,
you should ensure that there are enough members to adequately cover all of the duties of
the team at any time.
337
CSIRT Team Leader
It is important that the CSIRT has an individual responsible for its activities. The CSIRT
Team Leader will generally be responsible for the activities of the CSIRT and will
coordinate reviews of its actions. This may lead to changes in polices and procedures for
dealing with future incidents.
CSIRT Incident Lead
In the event of an incident, there should be one individual responsible for coordinating the
response. The CSIRT Incident Lead has ownership of the particular incident or set of
related security incidents. All communication about the event is coordinated through the
Incident Lead, and when speaking with those outside the CSIRT, he or she represents
the entire CSIRT. The Incident Lead may vary depending on the nature of the incident
and is often different than the CSIRT Team Leader.
CSIRT Associate Members
Besides your core CSIRT team, you should have a number of specific individuals who
handle and respond to particular incidents. Associate members will come from a variety
of different departments in your organization, and they should specialize in areas that are
affected by security incidents but that are not dealt with directly by the core CSIRT.
Associate members may either be directly involved in an incident or serve as entry points
to delegate responsibility to a more appropriate individual within their departments. The
following table shows some suggested associate members and their roles.
Table 10.1: CSIRT Associate Members
Associate Member
Role Description
IT Contact
Primary responsibility for coordinating communication between the
CSIRT Incident Lead and the rest of the IT group. The IT Contact
may not have the particular technical expertise to respond to the
incident at hand; however, he or she will be primarily responsible
for finding people in the IT group to handle particular security
events.
Legal Representative
Typically a member of the in-house legal staff who is very familiar
with established incident response policies. The Legal
Representative determines how to proceed during an incident with
minimal legal liability and maximum ability to prosecute offenders.
Before an incident occurs, the Legal Representative should have
input on monitoring and response policies to ensure that the
organization is not being put at legal risk during a cleanup or
containment operation. It is imperative to consider the legal
implications of shutting down a system and potentially violating
service level agreements or membership agreements with your
customers, or not shutting down a comprised system and being
liable for damages caused by attacks launched from that system.
Any communication to outside law enforcement or external
investigative agencies should also be coordinated with the Legal
Representative.
338
(continued)
Communications Officer
Generally, a member of the public relations department, the
Communications Officer is responsible for protecting and
promoting the image of the organization.
This individual may not be the actual face to the media and
customers, but he or she is responsible for crafting the message
(the content and objective of the message is generally the
responsibility of management). All media inquiries should be
directed to the Communications Officer.
Management
Management involvement may range from departmental to across
the entire organization. The appropriate management individual will
vary according to the impact, location, severity, and type of
incident.
If you have a managerial point of contact, you can quickly identify
the most appropriate individual for the specific circumstances.
Management is responsible for approving and directing security
policy.
Management is also responsible for determining the total impact
(both financial and otherwise) of the incident on the organization.
Management directs the Communications Officer regarding which
information should be disclosed to the media and determines the
level of interaction between the Legal Representative and law
enforcement agencies.
339
How the CSIRT Responds to an Incident
In the event of an incident, the CSIRT will coordinate a response from the core CSIRT
and will communicate with the associate members of the CSIRT. The following table
shows the responsibilities of these individuals during the incident response process.
Table 10.2: Responsibilities of CSIRT During the Incident Response Process
Activity
340
Role
CSIRT
IT Contact
Incident Lead
Legal
Representative
Communications
Officer
Management
Initial
Assessment
Owner
Advises
None
None
None
Initial Response
Owner
Implements
Updates
Updates
Updates
Collects Forensic
Evidence
Implements
Advises
Owner
None
None
Implements
Temporary Fix
Owner
Implements
Updates
Updates
Advises
Sends
Communication
Advises
Advises
Advises
Implements
Owner
Check with Local
Law Enforcement
Updates
Updates
Implements
Updates
Owner
Implements
Permanent Fix
Owner
Implements
Updates
Updates
Updates
Determines
Financial Impact
on Business
Updates
Updates
Advises
Updates
Owner
Defining an Incident Response Plan
All members of your IT environment should be aware of what to do in the event of an
incident. While the CSIRT will perform most actions in response to an incident, all levels
of your IT staff should be aware of how to report incidents internally. End users should
report suspicious activity to the IT staff directly or through a help desk rather than directly
to the CSIRT.
The incident response plan should be reviewed in detail by all team members and easily
accessible to all IT staff. This will help to ensure that when an incident does occur, the
right procedures are followed.
Your incident response plan should include these steps:
●
Making an initial assessment.
●
Communicating the incident.
●
Containing the damage and minimizing the risk.
●
Identifying the type and severity of the compromise.
●
Protecting evidence.
●
Notifying external agencies.
●
Recovering systems.
●
Compiling and organizing incident documentation.
●
Assessing incident damage and cost.
●
Reviewing the response and updating policies.
Note: The Word document “The Incident Response Quick Reference Card” can be
used during an incident as a checklist to ensure that all phases are properly executed.
The file name for this document is JA1001.doc and it is included in the self-extracting
executable file called SecWin2k.exe that is included with this guide.
These steps are not purely sequential. Rather, they happen throughout the incident. For
example, documentation starts at the very beginning and continues throughout the entire
life cycle of the incident; communication also happens throughout the entire incident.
Other aspects of the process will work alongside each other. For example, as part of your
initial assessment, you will gain an idea of the general nature of the attack. It is important
to use this information to contain the damage and minimize risk as soon as possible. If
you act quickly, you can help to save time and money, and your organization's reputation.
However, until you understand in more detail the type and severity of the compromise,
you will not be able to be really effective in containing the damage and minimizing the
risk. An overzealous response could even cause more damage than the initial attack. By
working these steps alongside each other, you will get the best compromise between
swift and effective action.
Note: It is very important that you thoroughly test your incident response process
before an incident occurs. Without thorough testing, you cannot be confident that the
measures that you have in place will be effective in responding to incidents.
341
Making an Initial Assessment
Many activities could indicate a possible attack on your organization. For example, a
network administrator performing legitimate system maintenance will appear similar to
someone launching some form of attack. In other cases, a badly configured system may
lead to a number of false positives in an intrusion detection system, making it more
difficult to spot genuine incidents.
As part of your initial assessment, you should:
●
Take initial steps to determine whether you are dealing with an actual incident or a
false positive.
●
Gain a general idea of the type and severity of attack. This should be at least
enough information to begin communicating it for further research and to begin
containing the damage and minimizing the risk.
●
Record your actions thoroughly. These records will later be used for documenting
the incident (whether actual or false).
Note: While you would like to avoid false positives as much as possible, it is always
better to act on a false positive than fail to act on a genuine incident. Your initial
assessment should therefore be as brief as possible, yet still eliminate obvious false
positives.
Communicate the Incident
Once you suspect that there is a security incident, you should quickly communicate the
breach to the rest of the core CSIRT. The incident lead, along with the rest of the team,
should quickly identify who needs to be contacted outside of the core CSIRT. This will
help to ensure that appropriate control and coordination of the incident can be
maintained, while minimizing the extent of the damage.
Be aware that damage can come in many forms, and that a headline in the newspaper
describing a security breach can be much more destructive than many system intrusions.
For this reason, and to prevent an attacker from being tipped off, only those playing a role
in the incident response should be informed until the incident is properly controlled.
Based on the unique situation, your team will later determine who needs to be informed
of the incident. This could be anyone from specific individuals up to the entire company
and external customers.
342
Contain the Damage and Minimize the Risk
By acting quickly to reduce the actual and potential effects of an attack, you can make
the difference between a minor and a major one. RFC 2196 defines a series of priorities
for containing damage in your environment. The exact response will depend on your
organization and the nature of the attack that you face. However, the following priorities
are suggested as a starting point:
1. Protect human life and people's safety. This should, of course, always be your
first priority.
2. Protect classified and sensitive data. As part of your planning for incident
response, you should clearly define which data is classified and which is sensitive.
This will allow you to prioritize your responses in protecting the data.
3. Protect other data, including proprietary, scientific, and managerial data.
Other data in your environment may still be of great value. You should act to
protect the most valuable data first before moving on to other, less useful data.
4. Protect hardware and software against attack. This includes protecting against
loss or alteration of system files and physical damage to hardware. Damage to
systems can result in costly downtime.
5. Minimize disruption of computing resources (including processes). Although
uptime is very important in most environments, keeping systems up during an
attack may result in greater problems later on. For this reason, minimizing
disruption of computing resources should generally be a relatively low priority.
There are a number of measures that you can take to contain the damage and minimize
the risk to your environment. As a minimum, you should:
●
Try to avoid letting attackers know that you are aware of their activities. This can
be difficult, because some essential responses may alert attackers. For example, if
there is an emergency meeting of the CSIRT, or you require an immediate change
of all passwords, any internal attackers may know that you are aware of an
incident.
●
Compare the cost of taking the compromised and related systems offline against
the risk of continuing operations. In the vast majority of cases, you should
immediately take the system off the network. However, there may be service
agreements in place that may require keeping systems available even with the
possibility of further damage occurring. Under these circumstances, you may
choose to keep a system online with limited connectivity in order to gather
additional evidence during an ongoing attack.
In some cases, the damage and scope of an incident may be so extensive that you
may have to take action that invokes the penalty clauses specified in your service
level agreements. In any case, it is very important that the actions that you will take
in the event of an incident are discussed in advance and outlined in your response
plan so that immediate action can be taken when an attack occurs.
●
Determine the access point(s) used by the attacker and implement measures to
prevent future access. Measures may include disabling a modem, adding access
control entries to a router or firewall, or increasing physical security measures.
●
Consider rebuilding a fresh system with new hard disks (the existing hard disks
should be removed and put in storage as these may be used as evidence if you
decide to prosecute attackers). Ensure that you change any local passwords. You
should also change administrative and service account passwords elsewhere in
your environment.
343
Identify the Severity of the Compromise
To be able to recover effectively from an attack, you need to determine how seriously
your systems have been compromised. This will determine how to further contain and
minimize the risk, how to recover, how quickly and to whom you communicate the
incident, and whether to seek legal redress.
You should attempt to:
●
Determine the nature of the attack (this may be different than the initial
assessment suggests).
●
Determine the attack point of origin.
●
Determine the intent of the attack. Was the attack specifically directed at your
organization to acquire specific information, or was it a random attack?
●
Identify the systems that have been compromised.
●
Identify the files that have been accessed and determine the sensitivity of those
files.
By performing these actions, you will be able to determine the appropriate responses for
your environment. A good incident response plan will outline specific procedures to follow
as you learn more about the attack. Generally, the nature of the attack symptoms will
determine the order in which you follow the procedures defined in your plan. As time is
crucial, less time consuming procedures should generally be followed before more
lengthy ones. To help determine the severity of the compromise, you should:
344
●
Contact other members of the response team to inform them of your findings, have
them verify your results, determine whether they are aware of related or other
potential attack activity, and help identify whether the incident is a false positive. In
some cases, what appeared to be a genuine incident on initial assessment will
prove to be a false positive.
●
Determine whether unauthorized hardware has been attached to the network or
whether there are any signs of unauthorized access through the compromise of
physical security controls.
●
Examine key groups (Domain Administrators, Administrators, and so on) for
unauthorized entries.
●
Search for security assessment or exploitation software. Cracking utilities are often
found on compromised systems during evidence gathering.
●
Look for unauthorized processes or applications currently running or set to run
using the startup folders or registry entries.
●
Search for gaps in, or absence of, system logs.
●
Review intrusion detection system logs for signs of intrusion, which systems may
have been affected, methods of attack, time and length of attack, and the overall
extent of potential damage.
●
Examine other log files for the following: unusual connections; security audit
failures; unusual security audit successes; failed logon attempts; attempts to log on
to default accounts; activity during nonworking hours; file, directory, and share
permission changes; and elevated or changed user permissions.
●
Compare systems to previously conducted file/system integrity checks. This allows
you to identify additions, deletions, modifications, and permission and control
modifications to the file system and registry. A great deal of time can be saved
when responding to incidents if you identify exactly what has been compromised
and what areas need to be recovered.
●
Search for sensitive data such as credit card numbers and employee or customer
data that may have been moved or hidden for future retrieval or modifications.
Systems may also need to be checked for nonbusiness data, illegal copies of
software, and e-mail or other records that may assist in an investigation. If there is
a possibility of violating privacy or other laws by searching on a system for
investigative purposes, you should contact your legal department before you
proceed.
●
Match the performance of suspected systems against their baseline performance
levels. This of course presupposes that baselines have been created and properly
updated. For more information about creating a performance baseline, see
Chapter 27 of the Windows 2000 Professional Resource Kit, "Overview of
Performance Monitoring" (Microsoft® Press®, ISBN: 1-57231-808-2).
When determining which systems have been compromised and how, you will generally
be comparing your systems against a previously recorded baseline of the same system
before it was compromised. Assuming that a recent system snapshot is sufficient for
comparison may put you in a difficult situation if the previous snapshot comes from a
system that has already been attacked.
Note: Tools such as EventCombMT, DumpEL, and Microsoft Operations Manager
(MOM) can help you determine how much a system has been attacked. Third-party
intrusion detection systems give advance warning of attacks, and other tools will show
file changes on your systems. For more information about these tools, see Chapter 9,
"Auditing and Intrusion Detection."
Protect Evidence
In many cases, if your environment has been deliberately attacked, you will want to take
legal action against the perpetrators. If you are going to do this, you will need to gather
evidence that can be used against them. It is extremely important to back up the
compromised systems as soon as possible, and prior to performing any actions that
could affect data integrity on the original media.
You should get someone skilled in computer forensics to make at least two complete bitfor-bit backups of the entire system using new, never-before-used media. At least one
backup should be on a write-once, read-many media such as a CD-R or DVD-R. This
backup should only be used for prosecution of the offender and should be physically
secured until needed.
The other backup may be used for data recovery. These backups should not be
accessed except for legal purposes, so you should physically secure them. You will also
need to document information about the backups, such as who backed up the systems,
at what time, how they were secured, and anyone who had access to them.
Once the backups are performed, you should remove the original hard disks and store
them in a physically secure location. These can be used as forensic evidence in the
event of a prosecution. New hard disks should be used to restore the system.
In some cases, the benefit of preserving data may not equal the cost of delaying the
response and recovery of the system. The costs and benefits of preserving data should
be compared to those of faster recovery for each event.
For extremely large systems, comprehensive backups of all compromised systems may
not be feasible. Instead you should back up all logs and selected, breached portions of
the system.
345
If possible, back up system state data, as well. It may be months or years until
prosecution takes place, so it is important to have as much detail of the incident archived
for future use.
Often the most difficult legal aspect of prosecuting a cyber crime is collecting evidence in
a manner acceptable to the particular jurisdiction’s laws of evidence submission. Hence,
the most critical component to the forensic process is detailed and complete
documentation of how systems were handled, by whom, and when, in order to
demonstrate reliable evidence. Sign and date every page of the documentation.
Once you have working, verified backups, you can wipe the infected systems and rebuild
them. This gets you back up and running quickly. It is the backups that provide the
critical, untainted evidence required for prosecution. A different backup than the forensic
backup should be used to restore data.
Notify External Agencies
After the incident has been contained and data preserved for potential prosecution, you
will need to start notifying appropriate external entities. Potential agencies include local
and national law enforcement, external security agencies, and virus experts. External
agencies can provide technical assistance, offering faster resolution and providing
information learned from similar incidents to help you fully recover from the incident and
prevent it from occurring in the future.
For particular industries and types of breaches, it may be necessary to specifically notify
customers and the general public, particularly if customers may be affected directly by
the incident.
If the event caused substantial financial impact, you may need to report the incident to
law enforcement agencies.
For higher profile companies and incidents, there may be media involvement. While
media attention to a security incident is never desirable, it is often unavoidable and allows
the organization to take a proactive stance in communicating the incident. At a minimum,
the incident response procedures should clearly define the individuals authorized to
speak to media representatives.
Normally these will be people in the public relations group within your organization. You
should not attempt to deny to the media that an incident has occurred, because doing so
is likely to damage your reputation more than proactive admission and visible responses
ever will. This does not mean that the media should be notified for each and every
incident regardless of its nature or severity. You should assess the appropriate media
response on a case-by-case basis.
Recover Systems
How you recover your system will generally depend on the extent of the security breach.
You will need to determine whether you can restore the existing system while leaving
intact as much as possible, or if it is necessary to completely rebuild the system.
Restoring data presumes, of course, that you have clean backups — backups made
before the incident occurred. File integrity software can help pinpoint the first occurrence
of damage. If the software alerts you to a changed file, then you know that the backup
you made just before the alert is a good one and should be preserved for use when
rebuilding the compromised system.
346
An incident could potentially corrupt data for many months prior to discovery. It is
therefore very important that as part of your incident response process, you determine
the duration of the incident. (File/system integrity software and intrusion detection
systems can assist you in this.) In some cases, the latest or even several prior backups
may not be long enough to get to a clean state, so you would be advised to regularly
archive data backups in a secure off-site location.
Compile and Organize Incident Evidence
The CSIRT should thoroughly document all processes when dealing with any incident.
This should include a description of the breach and details of each action taken (who took
the action, when they took it, and the reasoning behind it). All people involved with
access must be noted throughout the response process.
Afterwards, the documentation should be chronologically organized, checked for
completeness, and signed and reviewed with management and legal representatives.
You will also need to safeguard the evidence collected in the protect evidence phase.
You should consider having two people present during all phases who can sign off on
each step. This will help reduce the likelihood of evidence being inadmissible and the
possibility of evidence being modified after the fact.
Remember that the offender may be an employee, contractor, temporary employee, or
other insider within your organization. Without thorough, detailed documentation,
identifying an inside offender will be very difficult. Proper documentation also gives you
the best chance of prosecuting offenders.
Assess Incident Damage and Cost
When determining the damage to your organization, you should consider both direct and
indirect costs. These could include:
●
Costs due to the loss of competitive edge from the release of proprietary or
sensitive information.
●
Legal costs.
●
Labor costs to analyze the breaches, reinstall software, and recover data.
●
Costs relating to system downtime (for example, lost employee productivity, lost
sales, replacement of hardware, software, and other property).
●
Costs relating to repairing and possibly updating damaged or ineffective physical
security measures (locks, walls, cages, and so on).
●
Other consequential damages such as loss of reputation or customer trust.
Review Response and Update Policies
Once the documentation and recovery phases are complete, you should review the
process thoroughly. Determine with your team the steps that were executed successfully
and what mistakes were made. In almost all cases, you will find that your processes need
to be modified to allow you to handle incidents better in the future.
You will find weaknesses in your incident response plan, which is the point of this postmortem exercise — you are looking for opportunities for improvement, which should
initiate a whole new round of the incident response planning process.
347
Scenario — Contoso Incident Handling
To see how the different stages of incident response should work when dealing with an
attack, the following case study has been designed, showing the response of the
Contoso CSIRT team to an infection of the Code Red II virus. Although this case study is
fictional, the measures taken closely mirror those taken by real organizations in attacks.
Table 10.3: Contoso Case Study
Incident Response Step
Action Taken
Make initial assessment
Samantha Smith, an on-call CSIRT member, is paged with a
brief description of an event logged by the Contoso intrusion
detection system. The system indicates a possible Code Red
II incident on the Web server, WEB2. She examines the WEB2
server's Internet Information Services (IIS) log file for the
signature string and checks for the existence of root.exe on
c:\inetpub\scripts. The results of these investigations strongly
suggest that this is not a false positive.
Communicate the incident
Samantha notifies the rest of the CSIRT by telephone of the
initial findings and agrees to follow up with additional details as
soon as they are available.
Contain the damage and
minimize the risk
The incident response policy for Contoso states that
verification of the presence of a worm requires the system to
be removed from the network. Samantha removes the network
cable. Fortunately, WEB2 is part of a set of load-balanced
servers, so customers will not experience downtime due to the
disconnection.
Communicate the incident
Samantha communicates these findings to the rest of the
CSIRT by e-mail and directly contacts the CSIRT leader. The
CSIRT leader designates Taylor Maxwell, an Information
Security Manager, as Incident Lead. Taylor will coordinate all
activity and communication to and from the core CSIRT.
Taylor notifies the Director of Technology and the on-call
Information Technology team that the Web server has been
disconnected from the network and that, at minimum, it will be
cleaned of the worm before it is reconnected again.
Taylor also notifies the executive management, the
Communications Officer, and the Legal Representative. The
Legal Representative informs Taylor that although prosecution
may not be possible, she would still rather that he follow
procedures to collect evidence.
Identify the severity of the
compromise
348
Samantha scans the log files of other servers to determine
whether the worm has spread. She discovers that it has not
spread.
(continued)
Contain the damage and
minimize the risk
Another CSIRT member, Robert Brown, runs the Microsoft
Baseline Security Analyzer (MBSA), a Microsoft tool that
enables an administrator to check the patch status of all
computers running Microsoft® Windows NT® version 4.0,
Windows 2000, and Microsoft® Windows® XP on a network
from a central location, to make a real-time determination of
whether other servers have been patched for Code Red II. He
finds that two other servers are not up to date and immediately
applies the patch.
Identify the severity of the
compromise
Robert makes a further scan of log files of all other IIS servers
and determines no other instances of Code Red II exist at this
time.
Protect evidence
Every indication is that the damage has been contained to
WEB2. Since the damage has been reasonably contained and
the legal department has indicated that he should collect
evidence, Taylor decides to do this before performing a more
intrusive analysis of the system that could disturb or destroy
the evidence. Other team members continue to monitor the
other Web servers and log for suspicious activity.
A member of the CSIRT trained to collect forensic evidence
creates two snapshots (that is, full physical backups) of the
compromised system. One snapshot is carefully preserved for
later forensic examination. The other snapshot will potentially
be used in the recovery process in conjunction with clean,
secure backups prior to the event. The forensic backup is
stored on never-before-used, write-once media, carefully
documented, and sealed and secured along with the hard
disks from the server, in accordance with security policy.
Identify the type and severity
of the attack
The organization's security toolkit portable computer, which
contains a number of forensic tools, is used to review the
recovery backup for indications of additional compromise.
Registry entries and folders are reviewed for additions to areas
that run software upon startup, such as the profile/startup
directories and Run and RunOnce registry keys. User and
Group accounts are reviewed as well, along with User Rights
and Security Policies for any modifications. Security logs are
reviewed for any other suspicious activity.
349
(continued)
Notify external agencies
Taylor reports the incident to the Federal Bureau of
Investigation (FBI) National Infrastructure Protection Center,
since Contoso participates in many large U.S. government
projects.
Because it was judged that neither customer information nor
access to systems was compromised, customers are not
notified.
Recover systems
Although there are tools to clean Code Red II from WEB2, the
CSIRT and the WEB2 support team elect to reinstall the
operating system to new media. By reinstalling the operating
system from the original distribution media onto new disk
media, they are ensured of having a clean system with no
hacker back doors or corrupted files.
Once Windows 2000 has been reinstalled, security lockdown
is applied more rigorously on the system by following the
guidelines specified in chapters 5 through 7 of this guide.
An uninfected backup is located and then, according to
documented procedures, data is restored. If data is only
available from the compromised backup, it is restored to a
separate, offline system and then reincorporated onto WEB2
after it is clear that it does not pose a danger of reinfecting
other operational systems.
The CSIRT team performs a complete vulnerability
assessment of the system, documenting all information
discovered in the process.
WEB2 is reconnected to the network and closely monitored for
additional signs of new or existing compromise.
350
(continued)
Compile and organize
incident documentation
Taylor and the CSIRT research the root cause of the
vulnerability and determine that the system was recently
reinstalled and patches were not applied. This is against
clearly defined policy already in place.
The breakdown for this event occurred in three places: the
Support team members failed to reapply the patches, the
Information Security department failed to audit applied patches
in a timely manner, and the Configuration Management group
failed to identify the need to apply patches and to get
Information Security involved in reviewing the system before
returning to operational status. Had some subset of these
processes been followed, the incident could have been
averted.
The team decides to implement a new procedure to prevent
this incident from happening again. A checklist is created that
must be completed by Change Management, Web Server
Support, and Information Security prior to Information Security
approving the reinsertion of any system into the internal
network. The checklist procedure must be completed before
Information Security will reconfigure the firewall to allow
external access to and from this system. The Audit department
will also regularly review that the checklists are being
completed accurately and fully.
Taylor and the CSIRT compile all of the documentation to
determine what tasks were completed to respond to the
incident, the time each task took, and who performed them.
This information is sent to the Finance representative to
calculate the costs according the Generally Accepted Account
Principles for computer damage.
The CSIRT team leader ensures that management
understands the total cost of the event, why it occurred, and
how they plan to prevent it in the future. It is important for
management to see the implications of not having or following
procedures and not having resources, such as the CSIRT, in
place.
The applicable team members review overall incident
documentation, lessons learned, and which policies were
followed and which were not.
Documentation and procedures relevant to pursuing legal
action are reviewed by the Legal Representative, the CSIRT
team lead and Incident Lead, and executive management.
351
Summary
Much of this chapter has dealt with measures that you can take to minimize the risk of
being attacked. However, organizations have the most success at reaching their security
goals when they do everything that they can to minimize their chances of attack, and then
plan what they will do when they are attacked. Part of this process is to audit carefully for
attack, which is covered in Chapter 9, "Auditing and Intrusion Detection." Another equally
important part is to have a defined, well rehearsed set of responses that you can put into
place if a successful attack does occur.
Related Topics
Hacking Exposed Windows 2000 by Joel Scambray and Stuart McClure (McGraw-Hill
Professional Publishing, ISBN: 0072192623).
The Computer Security Institute releases an annual study called the Computer Crime and
Security Survey (http://www.gocsi.com).
More Information
For information about the Handbook for Computer Security Incident Response Teams,
see:
http://interactive.sei.cmu.edu/Recent_Publications/1999/March/98hb001.htm.
For information about Forum of Incident Response and Security Teams (FIRST), see:
http://www.first.org.
Incident Response: Investigating Computer Crime by Chris Prosise and Kevin Mandia
(McGraw-Hill Professional Publishing, ISBN: 0072131829).
The Internet Security Guidebook: From Planning to Deployment by Juanita Ellis, Tim
Speed, William P. Crowell (Academic Pr, ISBN: 0122374711).
For information about RFC 2196, see:
http://www.ietf.org/rfc/rfc2196.txt?number=2196.
For information about Chapter 27, "Overview of Performance Planning," in the
Windows 2000 Professional Resource Kit, see:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/
windows2000pro/reskit/part6/proch27.asp.
For Cert Coordination Center (CERT/CC) information, see:
http://www.cert.org/.
352
11
Conclusion
Congratulations. Now that you have finished this guide, you should have a much more
clear understanding of how to assess risks that may impact the security of the Microsoft®
Windows® 2000 servers in your organization. You have gained an understanding of how
to plan for and design security into your infrastructure where possible, and how to
maintain a secure environment going forward. This guide included prescriptive guidance
that may be applied to any organization. Examples were provided for a security project
undertaken for an enterprise by examining the security needs of Contoso, Ltd.
This guide includes material collected from consultants and systems engineers working in
the field who have implemented Windows 2000 Server solutions in a variety of corporate
settings to provide you with the current set of best practices to perform this complex task.
Chapters two and three in this guide introduced the concepts and terms relating to
security risk management such as assets, threats, vulnerability assessment, exploits, and
countermeasures. You also learned about a number of other key security terms, including
confidentiality, integrity, and authentication. Chapter four introduced you to Contoso and
explained what this organization determined what had to be done to improve the security
of the Windows 2000 servers in the company's environment. Contoso's Windows 2000
computers were then assessed and a detailed plan was developed to address identified
vulnerabilities.
Chapters five, six, and, seven then demonstrated how the concepts introduced in the
earlier chapters are applied. Contoso was used in a scenario that closely mirrors the
security tradeoffs that commonly exist in the real world among corporations today.
Organization units (OUs) that rely on Microsoft® Active Directory® directory service were
used to group servers by their primary functional roles, and then Group Policy objects
(GPOs) were created and linked to the OUs to simultaneously apply numerous settings to
hardened the servers against attacks and unauthorized access. A number of additional
tools also were used to accomplish this, such as the IIS Lockdown Tool and URLScan, to
further secure the systems at Contoso. In addition, some server hardening procedures
were performed manually.
Regardless of your organization's environment, security should be taken seriously.
However, many organizations still place little emphasis on security, mistakenly viewing it
as something that restricts the agility and flexibility of their enterprise. When well –
designed security becomes a core business requirement, and planning accounts for it at
the start of every information technology (IT) project, a properly implemented security
strategy can help to improve the availability and performance of your computer systems.
On the other hand, when security is added to a project as an afterthought, it can have a
negative effect on usability, stability, and management flexibility — all important reasons
why every organization should make security a top priority.
353
Vulnerabilities Identified in the Contoso Environment
Chapter four identified the most critical vulnerabilities present on Contoso's servers.
Contoso used a vulnerability scanning tool on its network to identify some of the major
issues with its configuration. The tool returned a large list of items, which were then
prioritized as High, Medium, or Low risk vulnerabilities. The following is a quick review of
the list and a brief explanation of how these issues were addressed.
Buffer Overflows
A number of Contoso's servers were identified as susceptible to buffer overflows related
to Microsoft® Internet Information Services (IIS). A buffer overflow is a type of exploit that
attackers employ to gain access to a system. Specifically, the tool identified the ida/idq
buffer overflow exploited by the Code Red worm, which had not been patched. A worm is
a stand-alone, self-replicating program that usually consumes memory to the point of
causing computers to crash.
Specific buffer overflow vulnerabilities were eliminated by installing service packs and
hotfixes from Microsoft that provide safeguards against these types of vulnerabilities in
such applications. Furthermore, the risks of a attacker exploiting buffer overflows as a
class were significantly lowered. This was accomplished through a number of
countermeasures, including installing and configuring URLScan; relocating data,
applications, and Web content to a storage volume separate from the location in which
the operating system is installed; and by disabling unnecessary services and
applications.
NetBIOS Enumeration
It was determined that all of Contoso's servers were vulnerable to network basic
input/output system (NetBIOS) enumeration. NetBIOS utilizes a default share for
interprocess communications (IPC). By default, anyone can connect to this share — no
user name or password is required. While creating a null connection, that is a connection
with no user name or password, to the IPC$ share on a computer will not give someone
rights to view files or control processes, it is possible to view a large amount of system
information. Malicious users can exploit this information disclosure vulnerability to gather
data for use in later attacks.
The risk of an attacker exploiting anonymous access via NetBIOS was reduced by
implementing a variety of countermeasures, including the Group Policy security option
called Additional restrictions for anonymous connections. Access to null session
pipes and null session shares, and IPSec filtering also was restricted.
SNMP Enumeration
Contoso uses Simple Network Management Protocol (SNMP) services on Windows 2000
servers for reporting events. The company had always used the default string "public,"
but their IT team was surprised to learn that in addition to generic hardware monitoring,
SNMP also may be used to return information on other aspects of the company's
computers. Attackers also can exploit this information disclosure vulnerability to collect
information for use in later assaults.
354
Although SNMP is an inherently insecure protocol due to the fact that SNMP network
data packets are contained in cleartext, it remains a very useful protocol for managing
enterprise networks. SNMP is an industry standard supported by most modern network
operating systems and enterprise management systems. The risk of sensitive information
being disclosed via SNMP was mitigated by changing the SNMP string on all of the
Contoso servers. A more effective way to protect SNMP network traffic is to implement
IPSec encryption between the servers; however, this encryption consumes a lot
processing power on busy servers. Contoso plans to eventually replace the network
interface cards (NIC) on their servers with NICs that can perform IPSec encryption
without placing any load on the CPUs of their machines. Once these are deployed
Contoso will implement IPSec encryption for most server – to – server communications.
DNS Enumeration
The Domain Name System (DNS) servers for Contoso did not restrict zone transfers.
Without securing this feature of DNS, an attacker can easily obtain data from an
organization’s DNS servers. Contoso uses Active Directory integrated with DNS in
Microsoft® Windows® 2000. DNS holds a large amount of information about a domain,
including server names and Internet Protocol (IP) addresses, services running on the
network, and servers hosting specific services, such as global catalogs and DCs.
DNS enumeration was made much more cumbersome for attackers by configuring the
DNS Servers to allow zone transfers only to a list of known computers. Any requests for a
zone transfer from a server not on the authorized list will now be ignored. The alternative
would be to not allow zone transfers. But this countermeasure was rejected because
Contoso's network is large and they have a DNS server hierarchy that includes
secondary DNS servers located in remote sites.
Weak Passwords
The assessment tool chosen by Contoso has additional functionality that allows it to
perform basic dictionary attacks against user accounts to identify weak passwords. In
addition, the tool examines the password hashes in the Security Accounts Manager
(SAM) database to determine whether there were any blank or duplicate passwords. If a
large number of duplicate passwords are identified, an attacker may determine that these
are default passwords to potentially exploit each time a new account is set up in the
organization.
The information in the SAM is encrypted, but even without trying to crack the passwords,
it is easy to identify blank or duplicate passwords based on the hash. Because Contoso
did not have an account lockout policy defined, an unlimited number of attempts could be
made to determine passwords. The scanning tool found a number of passwords
consisting purely of common words found in any dictionary that it could crack in a matter
of minutes.
The risk of passwords being cracked on the Contoso network was lowered by
implementing strict password and account lockout policies. It would be more effective to
implement smartcards for user authentication, but Contoso does not have either a Public
Key Infrastructure (PKI) deployed yet, or the resources to design and implement an
enterprise PKI. In the future Contoso plans to build a robust PKI that will be integrated
with Active Directory to deploy smartcards in a staged process.
355
Unencrypted Server Message Block Traffic
By default, the Micorosoft® Windows NT® local area network (LAN) Manager (NTLM)
challenge/response does not pass the LanManager (LM) authentication or NTLM hash
across the network. However, tools exist that can monitor this exchange traffic and use a
brute force method to derive the original LM hash value. After the hashes have been
obtained, several utilities can be used to crack the hashes into a cleartext password.
Unfortunately, all four of the following SMB encryption and signing countermeasures had
to be disabled: Digitally sign client communication (always); Digitally sign client
communication (when possible); Digitally sign server communication (always); and
Digitally sign server communication (when possible).
This was done to ensure compatibility with legacy SMB applications and operating
systems. Contoso plans to reduce the risk of this vulnerability by upgrading all of their
systems to Windows 2000, Microsoft® Windows® XP, and Microsoft® Windows® Server
2003 in the next 18 months. When the upgrades are complete, the security team at the
company can enable all four settings, however the team understands that there may still
be a significant performance impact on their busiest servers.
If the performance impact is too large, the team will disable the settings for Digitally sign
client communication (always) and Digitally sign server communication (always) on
all the company's systems, as well as disable all four settings on any servers showing
performance problems. An alternative solution would be to implement IPSec encryption
between all computers including the end-user systems.
Ineffective Auditing
Many of the servers scanned did not have audit settings enabled to a sufficient level to
identify potential attacks. For example, the Audit Account Logon setting was not
enabled, which could help to identify brute force attacks against passwords.
Appropriate auditing settings were chosen and implemented on Contoso's servers so that
significant security events are recorded in the Security Event Log while most unimportant
ones are omitted. The size of the event logs was dramatically increased so that even the
busiest servers would be able to hold several weeks' worth of entries in their logs.
Unchecked DoS Attacks
A denial of service (DoS) attack is any attack that prevents users from accessing
resources. There are many variations of DoS attacks, but some of the most common
affect either IIS or the Transmission Control Protocol/Internet Protocol (TCP/IP) stacks of
individual computers. Several changes were made on the computers at Contoso to lower
the risk of TCP/IP – based DoS attacks.
The TCP/IP network stack also was hardened by implementing a number of registry
value entries. Since these can not be configured directly through Group Policy, the
required entries were added into the security templates before importing the templates
into the appropriate GPOs.
356
IIS Directory Traversal
A review of the IIS servers revealed a common directory traversal issue. The exploit of
this vulnerability would allow an attacker not only to view information such as directory
layouts and the contents of files on the target computer, but in many cases, it would also
allow the attacker to write files and execute commands on the servers.
Specific directory traversal vulnerabilities were eradicated by installing recommended
service packs and hotfixes from Microsoft. The risk of an attacker exploiting any new
directory traversal vulnerabilities also was dramatically lowered by configuring URLScan
to block Hypertext Transfer Protocol (HTTP) requests that contain strings of characters
commonly used in this type of attack. Other countermeasures used to lower this risk
included relocating data, applications, and Web content to a storage volume separate
from the operating system; and disabling unnecessary services and applications.
357
Summary
This guide explained how to effectively assess, prioritize, and mitigate security risks in a
Windows 2000 Server environment. It documents methods for planning and designing
security into your organization's network infrastructure, and provides detailed guidance
on how to correct specific vulnerabilities that are commonly found on Windows 2000
servers.
The reasoning behind these choices was explained in terms of the tradeoffs that were
often involved in deciding whether to implement each of the countermeasures on the
Contoso servers. Details were provided on how specific countermeasures may impact
the functionality, manageability, performance, and reliability of the servers so that you
can make informed choices on which countermeasures to implement in your own
environment.
Finally, it is important to understand that the task of securing the servers on your network
is not a onetime project, but rather an ongoing process that organizations must include in
their budgets and schedules. Implementing every countermeasure discussed in this
guide will improve the security in the majority of organizations operating Windows 2000
servers. However, when the next serious vulnerability is discovered, these server
environments may again be quite susceptible to attack. For these reasons, it is critical to
monitor a variety of resources to stay current on security issues related to the operating
systems, applications, and devices present in your environment.
Every member of the team that produced this guide hopes that you found the material
covered in it useful, informative, and easy to understand.
358
Appendix A
Purpose of Windows 2000
Services
Alerter. Notifies selected users and computers of administrative alerts. If this service is
turned off, applications that use the NetAlertRaise or NetAlertRaiseEx application
programming interfaces (APIs) will be unable to notify a user or computer (by a message
box from the Messenger service) that the administrative alert took place.
Application Management. Provides software installation services for applications
deployed through Add/Remove Programs. This service (known as appmgmts) processes
requests to enumerate, install, and remove applications deployed via a corporate
network. When the Add button in Add/Remove Programs is pressed on a computer
joined to a domain, the applet calls in to the service to retrieve the list of deployed
applications.
Automatic Updates. Provides the download and installation of critical Windows updates,
such as security patches or hotfixes. This service can be disabled when automatic
updates are not performed on the server.
Background Intelligent Transfer Service. Provides a background file transfer
mechanism and queue management. This service is used by Automatic Update to
automatically download programs (such as security patches). Background Intelligent
Transfer Service can be disabled when automatic updates are not performed on the
server.
Boot Information Negotiation Layer (BINL). Provides the ability to install Microsoft®
Windows® 2000 Professional on Pre Execution Environment (PXE) remote boot-enabled
client computers. The BINL service, the primary component of Remote Installation
Services (RIS), answers PXE clients, checks Microsoft® Active Directory® for client
validation, and passes client information to and from the server. The BINL service is
installed when you either add the RIS component from Add/Remove Windows
Components, or select it when initially installing the operating system.
Certificate Services. Creates, manages, and removes X.509 certificates for applications
such as Secure/Multipurpose Internet Mail Extensions (S/MIME) and Secure Sockets
Layer (SSL). If this service is disabled, any services that explicitly depend on it will fail to
start.
359
ClipBook. Enables the Clipbook Viewer to create and share pages of data to be
reviewed by remote users. This service depends on the NetDDE/Network Dynamic Data
Exchange (DDE) service to create the actual file shares that can connect to other
computers. The Clipbook application and service allow users to create the pages of data
to share.
Cluster Service. Defines a cluster as a group of independent computer systems,
referred to as nodes, that work together to provide a unified computing resource. There
are two different types of cluster solutions in the Windows platform that support different
application styles: Server Clusters and Network Load Balancing (NLB) clusters. Server
clusters provide a highly available environment for long-running applications such as
database or file servers by providing failover support with tightly integrated cluster
management.
COM+ Event Services. Provides automatic distribution of events to Component Object
Model (COM) components. COM+ Events extend the COM+ programming model to
support late-bound events or method calls between the publisher or subscriber and the
event system. Instead of repeatedly polling the server, the event system notifies
interested parties as information becomes available.
Computer Browser. Maintains the list of computers on the network and supplies the list
to programs that request it. The Computer Browser service is used by Windows-based
computers that need to view network domains and resources.
Computers designated as browsers maintain browse lists, which contain all shared
resources used on the network. Earlier versions of Windows applications, such as My
Network Places, the NET VIEW command, and Microsoft® Windows NT® Explorer, all
require browsing capability.
For example, opening My Network Places on a computer running Windows 95 displays a
list of domains and computers, which is accomplished by the computer obtaining a copy
of the browse list from a computer designated as a browser. The Contoso servers in the
Contoso scenario use the Computer Browser service to enumerate services within the
domain.
DHCP Client. Manages network configuration by registering and updating Internet
Protocol (IP) addresses and Domain Name System (DNS) names. When this service is
running, it is not necessary to manually change the IP settings when a client, such as a
roaming user, travels throughout the network.
The client is automatically given a new IP address regardless of the subnet it reconnects
to — as long as a Dynamic Host Configuration Protocol (DHCP) server is accessible from
each of those subnets. Required to update records in Dynamic DNS. Dynamic DNS
enables DNS client computers to register and dynamically update their resource records
with a DNS server whenever changes occur.
DHCP Server. Allocates IP addresses and allows the advanced configuration of network
settings such as DNS servers, Windows Internet Naming Service (WINS) servers, and so
on to DHCP clients automatically. If the DHCP Server service is turned off, DHCP clients
will not receive IP addresses or network settings automatically.
Distributed file system. Manages logical volumes distributed across a local or wide area
network (WAN) and is required for the Active Directory SYSVOL share. Distributed file
system (Dfs) is a distributed service that integrates disparate file shares into a single
logical namespace.
360
This namespace is a logical representation of the network storage resources that are
available to users on the network. If the Dfs service is turned off, users will be unable to
access network data through the logical namespace. Users would need to know the
names of all the servers and shares in the namespace and access each of these targets
independently.
Distributed Link Tracking (DLT) Client. Maintains links between NTFS version 5
(NTFSv5) file system files within the domain controllers and other servers in the domain.
The DLT Client service ensures that shortcuts and Object Linking and Embedding (OLE)
links continue to work after the target file is renamed or moved.
When you create a shortcut to a file on an NTFSv5 volume, DLT stamps a unique object
identifier (ID) into the target file, known as the link source. Information about the object ID
is also stored within the referring file, known as the link client.
Distributed Link Tracking (DLT) Server. Tracks information so that files moved
between volumes can be tracked for each volume in the domain. The DLT Server service
runs on each domain controller in a domain.
This service enables the DLT Client service to track linked documents that have been
moved to a location in another NTFSv5 volume in the same domain. If the DLT Server
service is disabled, links maintained by the DLT Client service may become less reliable
over time. The NtfsDisableDomainLinkTracking policy setting should be enabled in the
File system policy group to prevent DLT clients from repeatedly trying to reach the
disabled service.
Distributed Transaction Coordinator (DTC). Coordinates transactions that are
distributed across multiple computer systems and resource managers, such as
databases, message queues, file systems, or other transaction-protected resource
managers.
DTC is necessary if transactional components are going to be configured through COM+.
COM+ is an extension to COM providing runtime and services that are readily used from
any programming language or tool. It enables extensive interoperability between
components regardless of how they were implemented.
It is also required for transactional queues in Message Queuing (MSMQ) and Microsoft®
SQL Server™ operations that span multiple systems. Disabling this service prevents
these transactions from occurring.
DNS Client. Resolves and caches DNS names. The DNS client service must be running
on every computer that will perform DNS name resolution. An ability to resolve DNS
names is crucial for locating domain controllers in Active Directory domains. Running the
DNS client service is also critical for enabling location of the devices identified using DNS
names.
If the DNS client service is disabled, the computers running Windows 2000 Server in your
organization may not be able to locate the domain controllers of the Active Directory
domains and Internet connections. The computers with disabled client service will not be
able to locate the devices identified using DNS names.
DNS Server. Enables DNS name resolution by answering queries and update requests
for DNS names. The presence of the DNS servers is crucial for locating devices identified
using DNS names and locating domain controllers in Active Directory.
361
If there is no DNS that is authoritative for a particular portion of the namespace, then
locating devices in that portion of the namespace will fail. Not having an authoritative
DNS server or the DNS namespace used to resolve Active Directory domains results in
an inability to locate the domain controllers in the domain. DNS Server is required for
Active Directory integrated DNS zones.
Event Log. Writes event log messages issued by Windows-based programs and
components to the log files. Event Log reports contain information that can be useful in
diagnosing problems. The reports are viewed in Event Viewer. The Event Log service
writes events sent by applications, services, and the operating system to log files.
The events contain diagnostic information in addition to errors specific to the source
application, service, or component. The logs can be viewed programmatically through the
Event Log APIs or through the Event Viewer in the Microsoft Management Console
(MMC) snap-in.
If the Event Log service is disabled, you will be unable to track events in your
environment, which reduces your ability to quickly diagnose problems with your system.
In addition, you will not be able to audit security events.
Fax Service. Provides the ability to send and receive faxes through fax resources
available on the domain controller and network.
File Replication. Maintains the file synchronization of file directory contents among
multiple servers. File Replication is the automatic file replication service in Windows
2000. It is used to copy and maintain files on multiple servers simultaneously and to
replicate the Windows 2000 system volume SYSVOL on all domain controllers.
In addition, the service can be configured to replicate files among alternate targets
associated with the fault-tolerant Dfs. If this service is disabled, file replication will not
occur, and server data will not be synchronized. In the case of a domain controller,
stopping the File Replication service may seriously impair its ability to function.
File Server for Macintosh. Enables Macintosh computer users to store and access files
on a computer running Windows 2000 Server. If this service is turned off, Macintosh
clients will not be able to view any NTFS file system (NTFS) shares.
FTP Publishing Service. Provides FTP connectivity and administration through the
Internet Information Service (IIS) snap-in. Features include bandwidth throttling, security
accounts, and extensible logging.
Gateway Service for Netware. Provides access to file and print resources on Netware
networks.
IIS Admin Service. Allows administration of IIS. If this service is not running, you will not
be able to run Web, File Transfer Protocol (FTP), Network News Transfer Protocol
(NNTP), or Simple Mail Transfer Protocol (SMTP) sites, or configure IIS in your
environment.
Indexing Service. Indexes content and file properties to provide rapid access to files
through a flexible querying language. This service also enables quick document
searching on local and remote computers and a search index for content shared on the
Web.
The Indexing Service builds indexes of all textual information in files and documents.
Once the initial index build is complete, the service maintains its indexes whenever a file
is created, modified, or deleted. On member servers it is disabled to prevent users from
searching files and file content if sensitive files and folders are inadvertently indexed.
362
Internet Authentication Service. Performs centralized authentication, authorization,
auditing, and accounting of users connecting to a network — either local area network
(LAN) or remote — using virtual private networking (VPN) equipment, Remote Access
Equipment (RAS), or 802.1x Wireless and Ethernet/Switch Access Points.
Internet Authentication Service (IAS) implements the Internet Engineering Task Force
(IETF) standard Remote Authentication Dial-In User Service (RADIUS) protocol, which
enables the use of heterogeneous network access equipment. If IAS is disabled or
stopped, authentication requests will failover to a backup IAS server, if it is available. If no
backup IAS servers are available, users will not be able to connect to the network.
Internet Connection Sharing. Provides network address translation (NAT), addressing,
and name resolution. When Internet Connection Sharing is enabled, your computer
becomes an "Internet gateway" on the network, enabling other client computers to share
one connection to the Internet, share files, and use the same printers.
This service is turned off by default. If Internet Connection Sharing is stopped or disabled,
services such as name resolution and addressing will be unavailable to clients on the
network. Therefore, clients on a home or small office network may not be able to get to
the Internet, and their IP addresses will expire, causing some clients to use Automatic
Private IP Addressing (APIPA) for peer-to-peer networking connectivity.
Internet Connection Sharing is disabled on all servers in the environment for the Contoso
scenario to prevent inadvertent enabling of NAT, which would prevent the server from
communicating with the remainder of the network.
Intersite Messaging (ISM). Allows sending and receiving messages between Windows
2000 Server sites. This service is used for mail-based replication between sites. Active
Directory includes support for replication between sites by using SMTP over IP transport.
SMTP support is provided by the SMTP service, which is a component of IIS. The set of
transports used for communication between sites must be extensible; therefore, each
transport is defined in a separate add-in dynamic-link library (DLL). These add-in DLLs
are loaded into the ISM service, which runs on all domain controllers that are candidates
for performing communication between sites.
The ISM service directs send and receive requests to the appropriate transport add-in
DLLs, which then route the messages to the ISM service on the destination computer.
This service is required only if SMTP replication is used in Active Directory.
IPSec Policy Agent (IPSec Service). Provides management and coordination of IPSec
policies with the IPSec driver.
Kerberos Key Distribution Center. Provides the ability for users to log on using the
Kerberos version 5 authentication protocol.
License Logging Service. Monitors and records client access licensing for portions of
the operating system, such as IIS, Terminal Services, file and print sharing, and products
that are not a part of the operating system, such as SQL Server or Microsoft® Exchange
server.
Logical Disk Manager. Watches Plug and Play events to detect new drives and passes
volume or disk information to the Logical Disk Manager Administrative Service to be
configured. If disabled, the Disk Management snap-in display will not change when disks
are added or removed.
363
The Logical Disk Manager uses an administrator service and a watchdog service. The
service should not be disabled if dynamic disks are in the system. This service is required
to ensure that dynamic disk information is up to date.
Logical Disk Manager Administrative Service. Performs an administrative service for
disk management requests. This service is started only when you configure a drive or
partition or when a new drive is detected. The service does not run by default, but it does
get activated by whenever dynamic disk configuration changes occur or when the Disk
Management MMC snap-in is open.
Such changes include converting a basic disk to dynamic, recovery of fault tolerant
volumes, volume formatting, or changing your page file. The service starts, completes the
configuration operation, and then exits. This service is required to perform disk
administration.
Messenger. Sends messages to and receives messages from users and computers or
messages transmitted by administrators or by the Alerter service. If disabled, Messenger
notifications cannot be sent to or received by the computer or by users currently logged
on. NET SEND and NET NAME also will no longer function.
Microsoft Message Queuing (MSMQ). A messaging infrastructure and development
tool for creating distributed messaging applications for Windows-based computers. Such
applications can communicate across heterogeneous networks and can send messages
between computers that may be temporarily unable to connect to each other.
MSMQ provides guaranteed message delivery, efficient routing, security, support for
sending messages within transactions, and priority-based messaging. MSMQ provides
both Microsoft® Win32® and COM APIs for all programmatic functionality including
administration and management.
Disabling MSMQ affects a number of other services including COM+ Queued Component
(QC) functionality, some parts of WMI, and the MSMQ Triggers service.
Net Logon Service. Supports pass-through authentication of account logon events for
computers in a domain. This service is started automatically when a computer is a
domain member. It is used to maintain a secure channel to a domain controller that the
computer can use to authenticate users and services running on it.
In the case of a domain controller, Net Logon handles the registration of the computer's
DNS names specific to domain controller locator discoveries and allows pass-through
authentication from other domain controllers running Net Logon that is forwarded to the
destination domain controller where the logon credentials are validated.
If this service is turned off, the computer will not operate properly in a domain.
Specifically, the computer may deny NTLM authentication requests and, in the case of
the domain controller, client computers will not be able to discover the domain controller.
NetMeeting Remote Desktop Sharing. Allows authorized users to remotely access your
Windows desktop from another personal computer over a corporate intranet by using
Microsoft® NetMeeting®. The service must be explicitly enabled by NetMeeting and can
be disabled in NetMeeting or shut down via a Windows tray icon.
Disabling the service unloads the NetMeeting display driver used for application sharing.
Remote desktop sharing is a potential security threat and is disabled on all servers.
364
Network Connections. Manages objects in the Network Connections folder, in which
you can view both network and remote connections. This is the service that takes care of
network configuration (client side) and displays status in the notification area on the
desktop (the area on the taskbar to the right of the taskbar buttons). You may also
access configuration parameters through this service.
Network DDE. Provides network transport and security dynamic data exchange (DDE)
for applications running on the same computer or computers. You can create Network
DDE "shares" programmatically or by using DDEshare.exe on your computer, and make
them visible to other applications and computers.
Traditionally, the user creating the share will create and run a server process to handle
incoming requests from client processes or applications (running on the same computer
or remotely). Once connected, these processes can exchange any kind of data over a
secure network transport. The service can be disabled when no DDE applications are
running locally on the system.
Network DDE DSDM. Manages shared DDE used by Network DDE. This service is used
only by Network DDE to manage shared DDE conversations. You can create and "trust"
DDE shares by using DDEshare.exe to allow remote computers and applications to
connect and share data.
This service maintains a database of these DDE shares, including information on which
ones are trusted. For each request for a connection from, or "conversation" with, an
application, this service queries the database and validates your security settings to
determine whether the request should be granted. Used by Network DDE. This service
can be disabled when Network DDE is disabled.
Network News Transport Protocol (NNTP). Allows computers running Windows 2000
Server to act as a news server. Clients can use a news client such as
Microsoft® Outlook® Express messaging client to retrieve newsgroups from the server
and read headers or bodies of the articles in each newsgroup.
The clients can then post back to the server. NNTP is an Internet standard. The version
included in Windows 2000 does not support feeds, in which two news servers replicate
their contents between each other. However, the version included in Exchange 2000
does include this functionality.
If the service is turned off, client computers will not be able to connect and read or
retrieve posts.
NTLM Security Support Provider. Provides security to remote procedure call (RPC)
programs that use transports other than named pipes and enables users to log on using
the NTLM authentication protocol. Contoso servers in the Contoso scenario run a
Microsoft Operations Manager (MOM) agent that is dependent on this service.
On-Line Presentation Broadcast. Links audio and video with Microsoft® PowerPoint®
presentation program slides as you deliver a presentation. This can occur either in real
time (people on the other end), or asynchronously while you are working on your
computer preparing a presentation to be stored on a server for later viewing. There are
no other dependencies on this service.
Performance Logs and Alerts. Collect performance data for the server, write the data to
a log, or generate alerts. These can be set to automatic when wanting to log performance
data or generate alerts without an administrator logged on.
365
Plug and Play. Enables a computer to recognize and adapt to hardware changes with
little or no user input. With Plug and Play, a user can add or remove devices, without any
intricate knowledge of computer hardware, and without being forced to manually
configure hardware or the operating system.
For example, a user can plug in a universal serial bus (USB) keyboard, and Plug and
Play will detect the new device, find a driver for it, and install it. Or, a user can dock a
portable computer and use the docking station's Ethernet card to connect to the network
without changing the configuration.
Later, the user can undock the same computer and use a modem to connect to the
network — again without making any manual configuration changes. Stopping or disabling
this service will result in system instability.
Print Server for Macintosh. Enables Macintosh clients to route printing to a print spooler
located on a computer running Windows 2000 Server. If this service is stopped, printing
will be unavailable to Macintosh clients.
Print Spooler. Manages all local and network print queues and controls all print jobs.
When this service is disabled on client computers, those systems will be unable to print
documents. The error messages that appear in Windows 2000 when a user attempts to
connect to a printer or print a document can be confusing.
Protected Storage. Protects storage of sensitive information, such as private keys, and
prevents access by unauthorized services, process, or users.
QoS Admission Control (RSVP). Provides network signaling and local, traffic-control,
setup functionality for Quality of Service (QoS)-aware programs and control applets.
QoS RSVP. Invoked when an application uses the Generic Quality of Service (GQoS)
API requesting a specific quality of service on the end-to-end connection that it uses. The
services signals its peer, and they agree (or not) on the parameters.
The RSVP messages can also be intercepted by routers that can veto the resource
request if they cannot guarantee that level of service. Once a successful negotiation
happens, the service then sets up appropriate flows with the Packet Scheduler, which
then ensures that a packet rate for that specific flow does not exceed the negotiated rate.
If disabled or removed, QoS is not guaranteed to the application, and it must then decide
whether to accept the best-effort (the default) or refuse to run. QoS RSVP can be
disabled when QoS is not used to allocate network bandwidth in network infrastructure.
Remote Access Auto Connection Manager. Creates a connection to a remote network
whenever a program references a remote DNS or network basic input/output system
(NetBIOS) name or address. This service (sometimes called the autodial service) detects
an attempt to resolve the name of a remote computer or share, or an unsuccessful
attempt to send packets to a remote computer or share.
The service is activated only when there is no network access. In that case, the service
brings up a dialog box that offers to make a dial-up or VPN connection to the remote
computer. It can be disabled on servers where no VPN or dial-up connections are
initiated.
Remote Access Connection Manager. Manages VPN and dial-up connections from the
server to the Internet or other remote networks. It can be disabled on servers where no
VPN or dial-up connections are initiated.
366
Remote Procedure Call (RPC). Serves as the RPC endpoint mapper for all applications
and services that use RPC communications. Required for internal processes in Windows
2000.
Remote Procedure Call (RPC) Locator. Enables RPC clients using the RpcNs family of
APIs to locate RPC servers and manage the RPC name service database. It can be
disabled if no applications use the RpcNs APIs.
Remote Registry Service. Enables remote users to modify registry settings on the
domain controller, provided the remote users have the required permissions. By default,
only Administrators and Backup Operators can access the registry remotely. This service
is required for the MBSA utility. Microsoft Baseline Security Analyzer is a tool that allows
you to verify which patches are installed on each of the servers in your organization. We
recommend the use of this tool in Chapter 8, "Patch Management."
Remote Storage Engine. Migrates infrequently used data to tape. It leaves a marker on
a disk allowing data to be recalled automatically from tape if you attempt to access a file.
Remote Storage File. Manages operations on remotely stored files.
Remote Storage Media. Controls the media used to store date remotely.
Remote Storage Notification. Allows Remote Storage to notify you when you have
accessed an offline file. Because it takes longer to access a file that has been moved to
tape, Remote Storage will notify you if you are attempting to read a file that has been
migrated and will allow you to cancel the request.
If the service is turned off, you will not receive additional notification when you try to open
offline files, nor will you be able to cancel an operation that involves an offline file.
Removable Storage. Manages and catalogs removable media and operates automated
removable media devices, such as tape auto loaders or CD jukeboxes. It can be disabled
when removable media devices are directly connected to the server.
Routing and Remote Access. Enables LAN-to-LAN, LAN-to-WAN, VPN, and network
address translation (NAT) routing services.
RunAs Service. Allows users to run specific tools and programs with different
permissions than their current logon provides.
SAP Agent. Advertises network services on an Inter Packet eXchange (IPX) network
using the IPX Service Advertising Protocol (SAP) protocol. It also forwards
advertisements on a multi-homed host. Some products such as the File and Print
Services from Microsoft for Netware rely on the SAP Agent. If this service is turned off,
these products may not function correctly.
Security Accounts Manager. The Security Accounts Manager (SAM) is a protected
subsystem that manages local user and group account information.
Server. Provides RPC support, file print, and named pipes sharing over the network.
Simple Mail Transport Protocol (SMTP). The SMTP service is an e-mail submission
and relay agent. It can accept and queue e-mail for remote destinations and retry at
specified intervals. Windows domain controllers use the SMTP service for intersite email-based replication. The Collaboration Data Objects (CDO) for the Windows 2000
COM component can use the SMTP Service to submit and queue outbound e-mail.
367
Simple TCP/IP Services. Implements support for the following protocols:
●
Echo (port 7, RFC 862)
●
Discard (port 9, RFC 863)
●
Character Generator (port 19, RFC 864)
●
Daytime (port 13, RFC 867)
●
Quote of the Day (port 17, RFC 865)
Single Instance Storage (SIS) Groveler. An integral component of Remote Installation
Services (RIS). In an effort to reduce the amount of disk space used by a RIS Server's
installation folders, SIS will grovel through the partition containing the RIS installation
directory, searching for redundant files, storing them centrally, and replacing them with
symbolic links. Although the SIS Groveler is installed by default in Windows 2000 Server,
it is set to Disabled unless the RIS component is installed.
Site Server ILS Service. As part of IIS, this service scans TCP/IP stacks and updates
directories with the most current user information. Windows 2000 is the last version of the
operating system to support the Site Server ILS service.
Smart Card. Manages and controls access to a smart card inserted into a smart card
reader attached to the server.
Smart Card Helper. Provides support for legacy, non-Plug and Play smart card readers.
SNMP Service. Allows incoming Simple Network Management Protocol (SNMP)
requests to be serviced by the local computer. SNMP includes agents that monitor
activity in network devices and report to the network console workstation.
If the service is turned off, the computer no longer responds to SNMP requests. If the
computer is being monitored by network management tools, the tools will not be able to
collect data from the computer or control its functionality via SNMP. The service is
required for Common Information Model (CIM) reporting to MOM. CIM is the data model
that describes the objects that exist in a management environment.
SNMP Trap Service. Receives trap messages generated by local or remote SNMP
agents and forwards the messages to SNMP management programs running on the
computer. If the service is turned off, SNMP applications will not receive SNMP traps that
they are registered to receive. If this computer is being used to monitor network devices
or server applications using SNMP traps, significant system occurrences could be
missed.
System Event Notification. Monitors system events and notifies subscribers to the
COM+ Event System of the events. Required to record entries in the event logs.
Task Scheduler. Provides the ability to schedule automated tasks on the server.
TCP/IP NetBIOS Helper Service. Provides support for the NetBIOS over TCP/IP
(NetBT) service and NetBIOS name resolution for clients. If this service is disabled,
NetBT clients, including Redirector (RDR), SRV, Net Logon, and Messenger, will stop
responding. As a result, users may not be able to share files, printers, or log on to the
system. This service is required for Group Policy (which may be used to distribute
patches).
TCP/IP Print Server. Enables TCP/IP-based printing using the Line Printer Daemon
protocol. If this service is stopped, TCP/IP-based printing will be unavailable. If this
service is disabled, any services that explicitly depend on it will fail to start.
368
Telephony. Provides Telephony API (TAPI) support for programs that control telephony
devices, as well as IP-based voice connections on the local computer and through the
LANs on servers also running the service. The telephony service enables applications to
act as clients to telephony equipment such as Private Branch Exchanges (PBXs),
telephones, and modems.
The service supports the TAPI under which different wire protocols that communicate
with telephony equipment can be supported. These protocols are implemented in
Telephony Service Providers (TSPs).
The telephony service cannot be stopped if there is another dependent service, such as
RAS, currently active. If no other dependent service is running and you stop the
telephony service, it will be restarted when any application makes an initialization call to
the TAPI interface. If the service is disabled, no program that depends upon it, including
modem support, will be able to run.
Telnet. Enables a remote user to log on and run applications from a command line on the
server. Because Telnet is inherently insecure, disable Telnet unless used for remote
administration for branch offices or headless systems.
Terminal Services. Allows multiple remote users to be connected interactively to the
domain controller and provides the display of desktops and runs applications. All Contoso
servers run Terminal Services for remote administration.
Terminal Services Licensing. Installs a license server and provides registered client
licenses when connecting to a Terminal Server. The Terminal Services License Service
is a low-impact service that stores the client licenses that have been issued for a
Terminal server, and then tracks the licenses that have been issued to client computers
or terminals.
If this service is turned off, the server will be unavailable to issue Terminal Server
licenses to clients when they are requested. If another License Server is discoverable on
a domain controller in the forest, the requesting Terminal Server will attempt to use it.
Trivial FTP Daemon. The Trivial File Transfer Protocol (TFTP) is an integral part of RIS
that implements support for the TFTP protocol defined in the following RFCs:
●
RFC 1350 — TFTP
●
RFC 2347 — Option extension
●
RFC 2348 — Blocksize option
●
RFC 2349 — Timeout interval, transfer size options
To disable this service, uninstall RIS. Disabling the service directly will cause it to
malfunction.
Uninterruptible Power Supply. Manages an uninterruptible power supply (UPS)
connected to the server by a serial port.
Utility Manager. Starts and configures accessibility tools from one window. Utility
Manager allows faster access to some accessibility tools and also displays the status of
the tools or devices that it controls.
This program saves users time because an administrator can designate that certain
features start when Windows 2000 starts. Utility Manager includes three built-in
accessibility tools: Magnifier, Narrator, and On-Screen Keyboard.
369
Volume Snapshot. Manages volume snapshots used by backup applications. When a
backup application attempts to start a backup utilizing the new snapshots infrastructure,
the backup application calls methods to determine the number of writers that are running
on the service, and then queries each writer to gather the required metadata.
Following this, the backup application can collect the volumes that need to get a
snapshot to ensure that a successful backup session occurs. The volumes are presented
to the snapshot coordinator, and a snapshot is created. The snapshot creates volumes
that match the original volumes at the time that the snapshot is taken. If turned off, no
snapshot backups can be done.
Windows Installer. Adds, modifies, and removes applications provided as a Windows
Installer (.msi file) package.
Windows Internet Name Service (WINS). Enables NetBIOS name resolution. The
presence of the WINS servers is crucial for locating the network resources identified
using NetBIOS names. WINS servers are required unless all domains have been
upgraded to Active Directory and all computers on the network are running Windows
2000.
Windows Management Instrumentation (WMI). Provides a common interface and
object model to access management information about the domain controller through the
WMI interface. It is required to implement performance alerts using performance logs and
alerts.
Windows Management Instrumentation Driver Extensions. Monitors all drivers and
event trace providers that are configured to publish WMI or event trace information.
Windows Media Monitor Service. Provides services to monitor client and server
connections to Microsoft® Windows Media® services.
Windows Media Program Service. Groups Windows Media streams into a sequential
program for the Windows Media Station Service.
Windows Media Station Service. Provides multicasting and distribution services for
streaming Windows Media content.
Windows Media Unicast Service. Provides Windows Media streaming content ondemand to networked clients.
Windows Time. Sets the computer clock W32Time to maintain date and time
synchronization on all computers running on a Windows network. Workstation uses the
Network Time Protocol (NTP) to synchronize computer clocks so that an accurate clock
value, or timestamp, can be assigned to network validation and resource access
requests.
NTP implementation and the integration of time providers makes W32Time a reliable and
scalable time service for enterprise administrators. For computers not joined to a domain,
W32Time can be configured to synchronize time with an external time source.
If this service is turned off, the time setting for local computers will not be synchronized
with any time service in the Windows domain, or an externally configured time service.
370
Workstation. Creates and maintains client network connections and communications.
The workstation service is a user-mode wrapper for the Microsoft Networks redirector. It
loads and performs configuration functions for the redirector, provides support for making
network connections to remote servers, provides support for the WNet APIs, and
furnishes redirector statistics. If this service is turned off, no network connections can be
made to remote computers using Microsoft Networks.
World Wide Web Publishing Service. Provides Hypertext Transfer Protocol (HTTP)
services for applications on the Windows platform. The service depends on the IIS
administration service and kernel TCP/IP support. If this service is turned off, the
operating system will no longer be able to function as a Web server.
371
Appendix B
Registry Access Control
Changes
The default permissions, also called access control lists (ACLs), applied to the registry in
Microsoft® Windows® 2000 Server are much more secure than those that appear in
Microsoft® Windows NT® version 4.0, but they can be further tightened without
significantly increasing the risk of application compatibility issues arising. The Member
Server Baseline Policy (MSBP) does not change the registry ACLs defined in hisecws.inf.
These ACLs reduce the level of access that unauthenticated users, Standard Users, and
Power Users have to the registry. These changes make it much more difficult for an
attacker who has anything less than administrative privileges to make any undesirable
changes to the registry.
Important: You should perform careful testing in your environment before you make
any changes to the existing ACLs.
The ACLs defined in hisecws.inf mainly change the Power Users group, which is created
by default for backward compatibility with Windows NT 4.0-based environments. The
template ensures that the Power Users group has the same permissions as the Users
group in Windows 2000.
Note: The Power Users group is not defined in the domain controllers.
373
374
Permissions Applied
HKLM\Software
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\Software\Classes
Everyone: Read
X
HKLM\SOFTWARE\Microsoft\
NetDDE
Administrators: Full control
Creator/Owner: Full control
System: Full control
X
HKLM\SOFTWARE\Microsoft\
Protected Storage System Provider
N/A
HKLM\SOFTWARE\Microsoft\
Secure
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
SystemCertificates
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion
Everyone: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
Accessibility
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
AEDebug
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
Inheritable/Can Propagate
Key Secured
Do Not Replace
Configure & Replace
Configure & Propagate
Table 1: Registry Access Control Changes
X
X
(continued)
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
AsrCommands
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
Backup Operators: Special
Permissions (Read & Write)
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
Classes
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
Drivers32
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\EFS
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
Font Drivers
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
FontMapper
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
Image File Execution Options
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
IniFileMapping
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\Perflib
Administrators: Full control
Creator/Owner: Full control
Interactive: Read
System: Full control
X
375
(continued)
376
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
Perflib\009
N/A
X
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
ProfileList
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
SecEdit
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
Setup\RecoveryConsole
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
Svchost
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
Time Zones
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
Windows
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows NT\CurrentVersion\
Winlogon
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SOFTWARE\Microsoft\
Windows\CurrentVersion\
Group Policy
N/A
X
X
HKLM\SOFTWARE\Microsoft\
Windows\CurrentVersion\Installer
N/A
X
X
HKLM\SOFTWARE\Microsoft\
Windows\CurrentVersion\Policies
N/A
X
X
(continued)
HKLM\System
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
HKLM\SYSTEM\Clone
N/A
X
X
HKLM\SYSTEM\ControlSet001
N/A
X
X
HKLM\SYSTEM\ControlSet002
N/A
X
X
HKLM\SYSTEM\ControlSet003
N/A
X
X
HKLM\SYSTEM\ControlSet004
N/A
X
X
HKLM\SYSTEM\ControlSet005
N/A
X
X
HKLM\SYSTEM\ControlSet006
N/A
X
X
HKLM\SYSTEM\ControlSet007
N/A
X
X
HKLM\SYSTEM\ControlSet008
N/A
X
X
HKLM\SYSTEM\ControlSet009
N/A
X
X
HKLM\SYSTEM\ControlSet010
N/A
X
X
HKLM\SYSTEM\CurrentControlSet\
Control\Computername
Everyone: Read
X
HKLM\SYSTEM\CurrentControlSet\
Control\ContentIndex
Everyone: Read
X
HKLM\SYSTEM\CurrentControlSet\
Control\Keyboard Layout
Everyone: Read
X
HKLM\SYSTEM\CurrentControlSet\
Control\Keyboard Layouts
Everyone: Read
X
HKLM\SYSTEM\CurrentControlSet\
Control\Print\Printers
Everyone: Read
X
HKLM\SYSTEM\CurrentControlSet\
Control\ProductOptions
Everyone: Read
X
HKLM\SYSTEM\CurrentControlSet\
Control\SecurePipeServers\winreg
Administrators: Full Control
Backup Operators: Read
X
HKLM\SYSTEM\CurrentControlSet\
Control\WMI\Security
Administrators: Read
Creator Owner: Full Control
System: Full Control
X
HKLM\SYSTEM\CurrentControlSet\
Enum
N/A
X
X
HKLM\SYSTEM\CurrentControlSet\
Hardware Profiles
N/A
X
X
HKLM\SYSTEM\CurrentControlSet\
Services\EventLog
Everyone: Read
X
X
HKLM\SYSTEM\CurrentControlSet\
Services\Tcpip
Everyone: Read
X
X
377
(continued)
USERS\. DEFAULT
Administrators: Full control
Creator/Owner: Full control
Power Users: Read
System: Full control
Users: Read
X
USERS\.
DEFAULT\Software\Microsoft\
NetDDE
Administrators: Full control
Creator/Owner: Full control
System: Full control
X
USERS\.
DEFAULT\SOFTWARE\Microsoft\
Protected Storage System
Provider
378
X
X
Appendix C
Disabling NetBIOS on Servers
in Untrusted Networks
This appendix discusses a recommendation specifically for servers located in untrusted
networks, for example, publicly accessible Web servers or corporate mail gateways.
None of the servers in the Contoso scenario were located in the perimeter network, so
the steps recommended within this appendix were not performed on any of them. If you
have servers located in an untrusted network, you should consider implementing the
changes that follow, but test them thoroughly and be certain that you understand the
challenges that disabling network basic input/output system (NetBIOS) will have on
managing the systems.
Vulnerability
Servers in the perimeter network should have all unnecessary protocols disabled
including NetBIOS and server message block (SMB). Web servers and Domain Name
System (DNS) servers do not require NetBIOS or SMB. These protocols should both be
disabled to counter the threat of user enumeration. User enumeration is a type of
information gathering exploit in which an attacker attempts to obtain system specific
information to plan further attacks.
The SMB protocol will return rich information about a computer even to unauthenticated
users using "null" sessions. The information that can be retrieved includes domain and
trust details, shares, user information (including groups and user rights), registry keys,
and more.
Note: Null sessions can be blocked by setting the RestrictAnonymous registry key as
described in the " MSBP Security Options" section in Chapter 6, "Hardening the Base
Windows 2000 Server."
Countermeasure
Disabling NetBIOS is not sufficient to prevent SMB communication. This is because in
the absence of standard NetBIOS ports, SMB will use Transmission Control Protocol
(TCP) port 445, which is referred to as SMB Direct Host. As a result, explicit steps must
be taken to separately disable both NetBIOS and SMB.
379
NetBIOS uses the following ports:
●
UDP/137 (NetBIOS name service)
●
UDP/138 (NetBIOS datagram service)
●
TCP/139 (NetBIOS session service)
SMB uses the following ports:
●
TCP/139
●
TCP/445
On servers accessible from the Internet, you should disable SMB by removing File and
Printer Sharing for Microsoft Networks and Client for Microsoft Networks using the
Transmission Control Protocol/Internet Protocol (TCP/IP) properties dialog box in your
Local Area Connection properties.
XTo disable SMB
1. On the Start menu, point to Settings, and then click Network and Dial-up
Connections.
2. Right-click Internet facing connection, and then click Properties.
3. Select Client for Microsoft Networks, and then click Uninstall.
4. Follow the uninstall steps.
5. Select File and Printer Sharing for Microsoft Networks, and then click
Uninstall.
6. Follow the uninstall steps.
XTo disable NetBIOS over TCP/IP
1. Right-click My Computer on the desktop, and then click Manage.
2. Expand System Tools, and then select Device Manager.
3. Right-click Device Manager, point to View, and then click Show hidden devices.
4. Expand Non-Plug and Play Drivers.
5. Right-click NetBios over Tcpip, and then click Disable.
This disables the SMB direct host listener on TCP/445 and UDP 445.
Note: This procedure disables the nbt.sys driver. The WINS tab of the Advanced
TCP/IP Settings dialog box contains a Disable NetBIOS over TCP/IP option.
Selecting this option only disables the NetBIOS Session Service (which listens on TCP
port 139). It does not disable SMB completely. To do so, follow the steps listed above.
Potential Impact
No systems will be able to connect to the server via SMB. The servers will be unable to
access folders shared on the network. Many management tools will be unable to connect
to the servers.
380
Appendix D
Configuring Digital Certificates
on Domain Controllers for
Secure LDAP and SMTP
Replication
381
Background
Digital certificates can be issued to your domain controllers (DCs) by any Certificate
Authority (CA) that can meet the formatting requirements for the certificates. One way to
easily issue digital certificates that are formatted properly is to first configure a Microsoft®
Windows® 2000 Enterprise CA (that is, a Microsoft® Active Directory® registered CA),
and then configure the DC certificates in Active Directory to automatically enroll the DCs.
There are at least two reasons for installing digital certificates on domain controllers
running Windows 2000 Server or later: to support Simple Mail Transfer Protocol (SMTP)
replication, and to support secure Lightweight Directory Access Protocol (LDAP)
transactions.
Digital Certificates for SMTP Replication
Active Directory replicates directory information between domain controllers via two
protocols: Remote Procedure Call (RPC), which is the default, and SMTP.
Replication via RPC is appropriate in most enterprise environments, but SMTP replication
is more appropriate between Active Directory sites separated by high latency or low
bandwidth network links.
Because SMTP is a cleartext protocol, and because directory replication information is
deemed sensitive material, by design SMTP replication can only be initiated if the DCs
have a way to encrypt the SMTP traffic over the network. The chosen method for
encryption is Secure/MIME, or S/MIME, a version of the Multipurpose Internet Mail
Extensions (MIME) protocol that supports encryption of messages. Windows 2000
requires digital certificates on each DC since replication can and does occur in either
direction across a replication link.
All DCs that may be enabled for SMTP replication should be enrolled for a DC certificate.
Each SMTP replication partner is individually configured in the Active Directory Sites and
Services Microsoft Management Console (MMC) snap-in, so it should be clear to you
which DCs require certificates. However, it is often most convenient to simply issue
certificates to all DCs, especially with Active Directory Group Policy using the
autoenrollment feature to enroll all members of the Domain Controllers organizational unit
(OU).
Once all the DCs are enrolled for digital certificates, any DCs that are configured to prefer
SMTP replication over Internet Protocol (IP) replication will automatically invoke SMTP
replication.
382
Digital Certificates for Secure LDAP
Windows 2000 domain controllers support LDAP over TCP port 389, which is sent over
the network in cleartext. The DCs can also support Secure Sockets Layer (SSL)
encryption of LDAP over TCP port 636 to encrypt LDAP authentication and to encrypt
LDAP data requests and responses. This is a very common requirement for enterprise
LDAP applications, as the information transmitted over the network by LDAP applications
can be very sensitive information — not just the LDAP request/response data, but also the
authentication IDs and passwords.
However, before SSL can be enabled for LDAP requests, the DC has to have a particular
type of digital certificate installed. The digital certificate has to be formatted properly to
ensure that LDAP applications operate correctly.
All DCs that might make SSL connections should enroll for a DC certificate. Some LDAP
applications are configured to make LDAP requests to a single LDAP server, so these
applications will make requests of the same DC each time. Other LDAP applications may
be aware of Active Directory. For this reason, any DC in a domain or in a forest may
receive SSL requests for LDAP. It is a best practice to enroll all DCs for DC certificates to
support the widest range of LDAP application scenarios.
Finally, once the DCs are prepared to accept SSL connections, the LDAP applications
have to be configured to request SSL connections. DCs cannot enforce SSL connections
for incoming LDAP requests — the DC can only be configured to support SSL for
applications that request it.
383
Installing and Configuring Infrastructure for Domain
Controller Certificates
Installing the Enterprise CA
The first phase in this process is to install an Enterprise CA and confirm that the
DomainController certificate template is enabled.
If you do not already have an Enterprise CA installed in your Active Directory forest,
install an Enterprise CA on a Windows 2000 server that is a member of one of the
domains in the Active Directory forest. For more information about installing an Enterprise
CA, see the "Step-by-Step Guide to Setting Up a Certification Authority," at:
http://www.microsoft.com/windows2000/techinfo/planning/security/casetupsteps.asp.
Confirming Domain Controller Certificate Template
Availability
Use the following steps to confirm whether the domain controller certificate template is
available.
XTo confirm that the domain controller certificate template is available
1. Open the Certification Authority MMC snap-in on the server.
2. Double-click the name of your CA (for example, Contoso Enterprise Root CA), then
click the Policy Settings folder.
3. Confirm that DomainController is listed in the right pane.
Configuring Automatic Enrollment
Next you need to configure automatic enrollment in Group Policy for each domain.
XTo configure automatic enrollment in Group Policy for each domain
1. In each domain for which you want to enable automatic enrollment for DC
certificates, open Default Domain Controller Policy using the Group Policy
Editor.
2. Under Computer Configuration, click Windows Settings.
3. Click Security Settings, and then click Public Key Policies.
4. Click Automatic Certificate Request Settings.
5. Right-click the Automatic Certificate Request Settings folder, select New on the
context menu, and then click Automatic Certificate Request.
6. The Automatic Certificate Request Setup Wizard launches. Click Next.
7. Select the certificate template to use in the request. In this example, you should
select Domain Controller, and then click Next.
384
8. Select the CA on the Windows 2000 domain to send the certificate request. (In this
example, choose the enterprise root CA. An enterprise may have more than one
CA.) Click Next.
Note: CAs not registered in Active Directory as enterprise CAs will not appear on
this list.
9. Click Finish to create the automatic certificate request. The request for the
certificate will take place when the Group Policy object (GPO) is refreshed on the
DCs.
Assigning Certificate Enrollment Permissions
Finally, you need to grant permission for each Domain Controllers security group of the
domain to enroll for the DC certificates.
XTo grant permission for DC groups to enroll for DC certificates
1. Start the Active Directory Sites and Services MMC snap-in.
2. Click the View menu, and then click Show Services Node.
3. Double-click the Services node and the Public Key Services node, and then
Certificate Templates.
4. Right-click DomainController , click Properties, and then select the Security tab.
Note: The Domain Controllers group in the CA's domain already has Enroll
permission to this template. You will need to grant the Enroll permission to all
other Domain Controllers groups from other domains in your forest. Otherwise,
those DCs will not have permission to successfully request the DomainController
certificates, and their attempts to automatically enroll for them will fail.
5. For each Domain Controllers group from each domain, click the Add button,
choose the domain in the Look in drop-down list box, select the Domain
Controllers group in that domain, click the Add button, and then click OK.
385
Testing Digital Certificates for LDAP or SMTP
Testing LDAP Applications That Connect via SSL
Once your domain controllers are capable of accepting SSL connections for LDAP
requests, each LDAP application will have to be reconfigured to default to SSL
communications (TCP port 636).
In this example, the LDAP application is the address book of Microsoft® Outlook®
Express. Outlook Express is installed on a Windows 2000 workstation that is not part of
the Active Directory forest. This example will help illustrate how the client can be
configured to trust the CA that issued the DC certificates.
Configuring the Address Book
This only works if a certificate has also been issued to the DC from a CA that is trusted
by your client. Use the following steps to verify that your DC certificate is working
properly.
XTo verify that the domain controller certificate is working properly
1. After you install the required certificates on the DCs, click Start, point to Search,
and then click For People.
2. In the Look in drop-down list box, click Active Directory.
3. Right-click Active Directory, and then click Properties.
4. In the Active Directory Properties dialog box, type in the Search Name box the
fully qualified domain name of the DC to which you want to connect. For example,
CDC-01.NORTHAMERICA.CONTOSO.COM.
If you are logged on with a domain account that has permissions to search the
Active Directory, you can skip this step. Otherwise, provide user credentials for this
domain controller in the Account and Password boxes. For example:
Account: domain name\user name
Password: password
Note: The domain name is the name of your domain where the account exists,
and the user name is the account that you are using to log on. The password must
be the password for the account that you are using.
5. After you have specified the DC and the appropriate credentials, click the
Advanced tab, and then specify SSL connectivity for LDAP (the port must be set
to 636).
6. Select a search base that is appropriate to your Active Directory structure, for
example CN=Users,DC=CDC01,DC=northamerica,DC=corp,DC=contoso,DC=com.
7. Click OK to close the Active Directory Properties dialog box.
386
Searching for People in Active Directory
Use the following steps to search for people in Active Directory.
XTo search for people in Active Directory
1. In the Find People dialog box, click Active Directory in the Look in drop-down list
box.
2. Click the Advanced tab.
3. In the define criteria section, select the following criteria for the search:
NAME Contains Administrator
4. Click Add, and then click Find Now.
Configuring SMTP Replication
If you have not already configured SMTP replication — because it required DC certificates
on the replicating DCs, for example — then you will have to set up the SMTP replication
site link between the DCs that require this replication.
For more information about configuring SMTP replication, see the "Step-by-Step Guide to
Setting up ISM-SMTP Replication," at:
http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/ismsmtp.asp
XTo configure SMTP replication
1. Start the Active Directory Sites and Services MMC snap-in as a user with
permissions to create site links (and, optionally, subnets) and to move DCs
between sites.
2. Create a new site — for example, in the Contoso scenario the Boston site was
created. Right-click the Sites folder, and then click New Site. Type a name for the
site in the Name box (for example, Boston), and then choose a site link object
from the list below (for example, the DEFAULTIPSITELINK link).
3. Click OK.
4. Double-click the Inter-Site Transports folder in the left pane, right-click the SMTP
object, and then click New Site Link.
5. In the Name box, type the name of this site link (for example, East Coast Site
Link).
6. Choose at least two sites to be replicated across this site link (for example, Boston
and Default-First-Site-Name), and then click OK.
387
Verifying Object Connections
Use the following steps to verify object connections.
XTo verify object connections
1. Double-click each server object to reveal an NTDS Settings object for each one.
2. Select each NTDS Settings object, and ensure that there is an NTDS
Connection object subordinate to each NTDS Settings object.
●
If you do not see Connection objects below each NTDS Settings object, rightclick each NTDS Settings object, select All Tasks, and then click Check
Replication Topology. This action forces the Knowledge Consistency
Checker (KCC) to check the replication topology, thereby creating a
Connection object between the two DCs.
3. Force replication between both DCs. Right-click the Connection object
subordinate to each NTDS Settings object, and then click Replicate Now.
4. Refresh the display by pressing F5 or by right-clicking the NTDS Settings object
and selecting Refresh. You should now see a Connection object.
Prioritizing SMTP Link Over IP link
Use the following steps to prioritize SMTP link over IP link.
XTo prioritize SMTP link over IP link
1. Select SMTP in the Inter-Site Transports container.
2. In the results pane, select the link object to be configured (that is, the East Coast
Site Link object). Right-click this object, and then click Properties.
Note: The cost of this site link is 100, which is also the default cost for each site
link. For the KCC to favor the SMTP site link over the IP site link, you need to
specify a lower cost for the site link called the Default-SMTP-Site-Link object.
3. Change the cost of the Default-SMTP-Site-Link object to 50 and then click OK.
(The cost of the DEFAULTIPSITELINK object can be changed if necessary so that
it is more than 50.)
4. To force replication between both DCs, right-click the Connection object
subordinate to each NTDS Settings object, and then click Replicate Now.
388
Requirements for a Domain Controller Certificate
To support secure LDAP or SMTP inter-site Active Directory replication, you must install
a certificate on the DCs that meets the following requirements:
●
The digital certificate is located in the Local Computer's Personal certificate store
(programmatically known as the computer's MY certificate store).
●
A private key matching the certificate is present in the Local Computer's store and
is correctly associated with the certificate. The private key must not have strong
private key protection enabled.
●
The Enhanced Key Usage extension in the digital certificate includes the Server
Authentication (1.3.6.1.5.5.7.3.1) object identifier (also known as the OID).
●
The Active Directory fully qualified domain name (for example,
C01.DOMAIN.COM) of the DC must appear in one of the following places:
●
●
The Common Name (CN) in the Subject field.
●
The Domain Name System (DNS) entry in the Subject Alternative Name
extension.
The certificate must be issued by a CA that the DCs and the Secure LDAP clients
trust. Trust is established by configuring the clients and the server to trust the root
CA that issues the signing certificate for the issuing CA.
389
More Information
See Microsoft Knowledge Base article 321051, "How to Enable LDAP over SSL with a
Third-Party Certification Authority."
See Knowledge Base article 247078, "HOW TO: Enable Secure Socket Layer (SSL)
Communication Over LDAP for Windows 2000 Domain Controllers."
See Knowledge Base article 296975, "Unable to Connect to a Domain Controller by
Using LDAP Connection over SSL."
See Knowledge Base article 319970, "How to Use the Address Book to Test SSL
Connectivity."
See Knowledge Base article 222962, "Microsoft Certificate Authority Is Required to
Perform Inter-Site SMTP."
390
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement