Baseline Compliance Management Overview

Baseline Compliance Management
Overview
Security Compliance Management Toolkit
Version 2.0
Published: June 2008 | Updated: February 2009

For the latest information, please see
microsoft.com/securitycompliance
Copyright © 2009 Microsoft Corporation. All rights reserved. Complying with the applicable
copyright laws is your responsibility. By using or providing feedback on this documentation, you
agree to the license agreement below.
If you are using this documentation solely for non-commercial purposes internally within YOUR
company or organization, then this documentation is licensed to you under the Creative Commons
Attribution-NonCommercial License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-nc/2.5/ or send a letter to Creative Commons, 543
Howard Street, 5th Floor, San Francisco, California, 94105, USA.
This documentation is provided to you for informational purposes only, and is provided to you
entirely "AS IS". Your use of the documentation cannot be understood as substituting for
customized service and information that might be developed by Microsoft Corporation for a
particular user based upon that user’s particular environment. To the extent permitted by law,
MICROSOFT MAKES NO WARRANTY OF ANY KIND, DISCLAIMS ALL EXPRESS, IMPLIED AND
STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO YOU FOR ANY DAMAGES OF ANY TYPE
IN CONNECTION WITH THESE MATERIALS OR ANY INTELLECTUAL PROPERTY IN THEM.
Microsoft may have patents, patent applications, trademarks, or other intellectual property rights
covering subject matter within this documentation. Except as provided in a separate agreement
from Microsoft, your use of this document does not give you any license to these patents,
trademarks or other intellectual property.
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.
Microsoft, Access, Active Directory, ActiveX, Excel, InfoPath, Internet Explorer, Outlook,
PowerPoint, Visual Basic, Windows, Windows Server, Windows Vista, and Windows XP 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.
You have no obligation to give Microsoft any suggestions, comments or other feedback
("Feedback") relating to the documentation. However, if you do provide any Feedback to Microsoft
then you provide to Microsoft, without charge, the right to use, share and commercialize your
Feedback in any way and for any purpose. You also give to third parties, without charge, any
patent rights needed for their products, technologies and services to use or interface with any
specific parts of a Microsoft software or service that includes the Feedback. You will not give
Feedback that is subject to a license that requires Microsoft to license its software or
documentation to third parties because we include your Feedback in them.
Solution Accelerators microsoft.com/technet/SolutionAccelerators

Contents
Introduction.......................................................................................1
Who Should Read This Guidance.........................................................3
Skills and Readiness 3
Purpose 3
Scope 4
Requirements 4
Components....................................................................................4
Style Conventions 5
Support and Feedback 5
Acknowledgments.............................................................................6
Development Team 6
Contributors and Reviewers 7
Chapter 1: Plan...................................................................................9
Compliance Background....................................................................9
Regulatory Compliance Requirements..................................................9
SOX and COBIT10
FISMA, HIPAA, GLBA, and ISO 27002 11
EUDPD/COBIT and the AICPA/CICA Privacy and Trust Services
Framework 12
PCI DSS and the Payment Card Industry 13
Internal Compliance Requirements....................................................14
Security Requirements 14
Policy Requirements 14
Establish a Plan..............................................................................15
Pick a Framework 15
COBIT 16
ISO 27002 16
AICPA/CICA Privacy and Trust Services Framework 17
PCI DSS 19
Know the Environment 20
Determine a Security Baseline 20
Document the Plan 21
Customize Configuration Packs 21
Related Resources...........................................................................22
Chapter 2: Deploy.............................................................................23
Windows and Office Security Guides..................................................24
SOLUTIONACCELERATORS microsoft.com/technet/SolutionAccelerators
4 Baseline Compliance Management Overview
The GPOAccelerator Tool..................................................................24

Customization................................................................................24
Chapter 3: Monitor............................................................................25
Configuration Packs.........................................................................26
DCM Configuration Pack User Guide...................................................26
Configuration Pack Customization......................................................26
Chapter 4: Remediate.......................................................................27
Related Resources

Introduction
Baseline compliance management for the Security Compliance Management Toolkit is designed to help
your organization meet its security and compliance needs. This toolkit provides you with information to
help you establish security baselines and use compliance industry best practices from Microsoft. This
guidance then demonstrates how your organization can efficiently monitor the implementation of
security baselines for the most widely used Microsoft operating systems and applications.
The Security Compliance Management Toolkit helps automate this process to ensure that your security
baselines do not change or drift from their prescribed values. You can accomplish this by using the
desired configuration management (DCM) feature of Microsoft® System Center Configuration Manager
2007 Service Pack 1 (SP1). The toolkit includes Configuration Packs for you to use with the DCM feature
to monitor the computers in your environment.
At a high level, achieving security compliance consists of the following four-step process:
1. Plan how to meet security baseline requirements.
2. Deploy security baseline configurations.
3. Monitor security baseline configurations.
4. Remediate security baseline configurations.

The steps in the following figure reinforce this process to illustrate how each portion of the Security
Compliance Management Toolkit fits into the overall process flow. The bulleted list of items next to
each process step includes additional guidance from Microsoft that applies to each step. Best practice
information for each step of the overall process is included in each chapter.
Introduction 3
Baseline compliance management primarily addresses the Plan, Deploy, and Monitor steps of the
overall process. In addition, the guidance provides some information about how to remediate security
baseline issues.
The toolkit contains background information about compliance, and planning advice about how to
automate security compliance. In addition, the toolkit refers to other tools and guidance from Microsoft
that you can use to establish and deploy a security baseline, and then monitor and maintain compliance
with your established configuration. The toolkit also includes guidance on how to customize security
baselines according to the specific risk posture of your environment.
The chapters in this guide emphasize understanding why security compliance is important, and the
planning process required to support it. The guide also includes chapters that address the deployment
and monitoring steps of the security compliance management process. Completing these steps of the
process enables your organization to establish operating system security baselines on the computers
in your environment, and then monitor them to ensure they are in compliance with the security
requirements of your organization.

Introduction 1
Who Should Read This Guidance

The Security Compliance Management Toolkit is intended primarily for IT specialists, security
specialists, network architects, and other IT professionals and consultants who plan and design
deployments of Windows Vista® Service Pack 1 (SP1), Windows® XP Professional SP3, and Windows
Server® 2008, Windows Server® 2003 SP2, and 2007 Microsoft® Office SP1 on desktop, laptop, and
server computers in midsize to large organizations. This guidance is not intended for home users.
Skills and Readiness

The effectiveness of security compliance management relies on individuals who share team
responsibilities and who have strong skill sets and experience. Ideally, such a team includes members
with security expertise (network, host, and application), strong technical (infrastructure, databases) and
communication skills, and technical documentation and training expertise. This guidance is intended
for IT professionals with experience and training to perform the following roles:
• IT Managers:
• Experience deploying applications and client computers in enterprise environments.
• Experience working with Microsoft System Center Configuration Manager 2007 or its
predecessor Systems Management Server 2003.
• Understand IT security principles and practices.
• IT Specialists:
• MCSE on Windows Server 2003 or a later certification, and two or more years of security-
related experience, or equivalent knowledge.
• In-depth knowledge of the organization’s domain and Active Directory® environments.
• Experience with the Group Policy Management Console (GPMC).
• Experience in the administration of Group Policy using the Group Policy Management
Console (GPMC), which provides a single solution for managing all Group Policy–related
tasks.
• Experience deploying applications and client computers in enterprise environments.
• Experience working with Microsoft System Center Configuration Manager 2007 or its
predecessor Systems Management Server 2003.
Purpose
The purpose of this toolkit is to help IT professionals:
• Understand the concepts and practicalities of security baselines, and how they apply to specific
compliance framework requirements.
• Relate operating system security baselines to compliance requirements by providing security

baselines that you can customize for specific compliance needs.
• Demonstrate how to customize security baselines to meet specific compliance needs.
• Use Configuration Manager 2007 SP1 and the DCM feature to check and verify settings on
specified operating systems.
Scope
The information in this toolkit applies only to the following applications and tools:
• System Center Configuration Manager 2007 SP1 and the DCM feature.
• GPOAccelerator tool.
Introduction 3
The guidance for this toolkit does not apply to the earlier version of Configuration Manager called
Systems Management Server (SMS) 2003 because the DCM feature was not available in that release.
However, experience with SMS can help users to understand the underlying technology and principles
that this toolkit uses. This guidance was tested on computers running Windows Vista SP1, Windows XP
Professional SP3, Windows Server 2008, Windows Server 2003 SP2, and 2007 Microsoft Office SP1.
Requirements
You must use Configuration Manager with the DCM feature to use this toolkit, which is designed to help
you manage the security compliance of the following operating systems and applications:
• Windows Vista SP1
• Windows XP Professional SP3
• Windows Server 2008
• Windows Server 2003 SP2
• 2007 Microsoft Office SP1

The toolkit guidance is designed to help you monitor the compliance state of security baseline settings
that are prescribed in the following guides:
• Windows Vista Security Guide.
• Windows XP Security Guide.
• Windows Server 2008 Security Guide.
• 2007 Microsoft Office Security Guide.
Components
Use this overview with the following components:
• DCM Configuration Packs that provide security baseline configuration checks for each of the
following operating systems and applications: Windows Vista SP1, Windows XP Professional SP3,
Windows Server 2008, Windows Server 2003 SP2, and 2007 Microsoft Office SP1.
• The Security Compliance Management: DCM Configuration Pack User Guide, which describes how
to load and use the Configuration Packs.
You can download these components from the Security Compliance Management Toolkit page
on the Microsoft Download Center.
Style Conventions
This guide uses the following style conventions.
Style Conventions
Element Meaning
Bold font Signifies characters typed exactly as shown, including commands, switches
and file names. User interface elements also appear in bold.
Italic font Titles of books and other substantial publications appear in italic.
<Italic> Placeholders set in italic and angle brackets <filename> represent

variables.
Monospace font Defines code and script samples.
Note Alerts the reader to supplementary information.
Important An important note provides information that is essential to the completion of

a task.
Warning Alerts the reader to essential supplementary information that should not be
ignored.
Support and Feedback

The Solution Accelerators – Security and Compliance (SA–SC) team would appreciate your thoughts
about this solution accelerator.
Please use the following resources for questions about support and feedback:
• Direct questions and comments related to the DCM feature and Configuration Packs to the
Configuration Manager – Desired Configuration Management community forum on
Microsoft TechNet.
• Direct questions and comments about the Security Compliance Management Toolkit to:
secwish@microsoft.com.
We look forward to hearing from you.

Introduction 1
Acknowledgments
The Solution Accelerators – Security and Compliance (SA–SC) team would like to acknowledge and
thank the team that produced the Security Compliance Management Toolkit. The following people were
either directly responsible or made a substantial contribution to the writing, development, and testing
of this toolkit.
Development Team
Development Lead
Michael Tan
Developers
Haikun Zhang – Minesage Co Ltd
Hui Zeng – Minesage Co Ltd
José Maldonado
Kurt Dillard – kurtdillard.com
Trevy Burgess – Excell Data Corporation
ZhiQiang Yuan – Minesage Co Ltd
Subject Matter Expert
Tony Noblett – Socair Solutions
Editors
Jennifer Kerns – Wadeware LLC
John Cobb – Wadeware LLC
Steve Wacker – Wadeware LLC
Product Managers
Alan Meeus
Frank Simorjay
Jim Stuart
Karla Korchinsky – Xtreme Consulting Group Inc
Shruti Kala
Program Managers
Gaurav Bora
Flicka Enloe
Kelly Hengesteg
Vlad Pigin
Release Manager
Karina Larson
Test Manager
Sumit Parikh
Testers
Ankit Agarwal – Infosys Technologies Ltd
Dhanashri Dorle – Infosys Technologies Ltd
Raxit Gajjar – Infosys Technologies Ltd
Bidhan Chandra Kundu – Infosys Technologies Ltd

Introduction 3
Manish Patel – Infosys Technologies Ltd
Contributors and Reviewers

Jeremiah Beckett – Secure Vantage, Derick Campbell, Chase Carpenter, Rick Carper, Adeep Cheema,
Chew Hung Pong, Tom Cloward, Karl Grunwald, David Hoelscher, Hui Zeng – Minesage Co Ltd., David
Kennedy, Onur Koc, Kathy Lambert, Jose Maldonado, Luis Martinez, Carmelo Milian, Kenneth Pan, Vlad
Pigin, Greg Shields – Realtime Windows Server Community, Mark Simos, Jeffrey Sutherland, Richard
Xia

Chapter 1: Plan
Because enterprise IT environments are complex, implementing technical controls for security
compliance requires both sound planning and careful execution. Establishing and maintaining security
baseline compliance requires a thorough understanding of the external compliance requirements and
the internal compliance needs of your environment. This chapter addresses the planning portion of this
process, and includes brief discussions of some regulatory requirements that organizations can
address using the Security Compliance Management Toolkit, The following figure shows where the
planning step fits into the overall process structure.
Figure 1.1 Security compliance management – Planning step
Compliance Background
Compliance is complex, uncoordinated, and full of ambiguity. The purpose of this chapter is to provide
you with some background on compliance, which you can use to select and plan an approach to
compliance for your organization. You can then implement and customize your approach using the
Configuration Packs that this toolkit provides.
This chapter divides requirements related to this subject into two generally accepted groups: regulatory
compliance requirements and internal compliance requirements. This is far from the whole story on the
subject. The information and sources cited in the chapter are intended to help you better understand
the subject.
Regulatory Compliance Requirements

Currently, there are more than 30 regulations worldwide that require some form of IT organizational
response in order to achieve compliance with them. The diversity and large overlap among these
regulations initially cause confusion in many organizations. To reduce the confusion, in the last few
years compliance specialists have recommended using a framework-based approach to implementing
IT controls. Frameworks have demonstrated that they can reduce the cost of compliance, and improve
the overall control mechanisms that organizations use to implement compliance responses.
The following resources offer good references on how organizations use such frameworks to meet
regulations:
• IT Compliance Management Guide from Microsoft.
• Compliance Convergence Initiative (CCI) framework from the IT Compliance Institute.

These references blend industry best practices with frameworks to provide a wide standard that
organizations can use to meet regulations, as well as identify and group IT controls that IT
professionals can implement to achieve the compliance goals of their organizations.
Examples of IT control groups include:
• Configuration Management
• Change Management
Chapter 1: Plan 3
• Incident Management
• Policy
• Document Management
• IT Governance
• IT Strategic Planning
• Software Development Life Cycle

Some regulations more closely match specific frameworks. To illustrate how specific regulations match
configuration controls, the following sections discuss several common regulations that are external to
organizations and how the regulations align with certain frameworks. These brief discussions include
references to other resources for more information about them.
Note In the following discussion on regulations and frameworks, the term third party
is used in the regulation and framework language. The term's legal definition in this
context is: "Any individual who does not have a direct connection with a legal
transaction, but who might be affected by it." In the case of compliance, a third party
company or person also refers to a party that may not have a direct legal right to
access the data affected, but may have been passed the data by the first party.
SOX and COBIT

The Sarbanes Oxley Act of 2002 (SOX) is a multifaceted regulation that is designed to require financial
transparency in publicly traded companies. The IT Governance Institute (ITGI) Control Objectives for
Information and related Technology (COBIT) framework closely aligns with SOX requirements. The
COBIT framework supports and integrates the Committee of Sponsoring Organizations of the Treadway
Commission’s (COSO) Internal Control – Integrated Framework, which is the widely accepted control
framework for enterprise governance and risk management, and similar compliance frameworks.
COBIT has undergone several revisions since it was initially used in SOX audits. Each revision more
closely aligns it with IT governance and the notion of control objectives. Control objectives can be
thought of as checkpoints, which provide windows into the overall operation of the business. Some of
these control objectives can be automated and are often called technical controls. The control
objectives and technical controls become important means of managing an enterprise and are
frequently used by executives, operations managers, and auditors to measure the performance and
transparency of the enterprise.
Organizations use these frameworks to achieve the following goals:
• Create links to business requirements.
• Organize IT activities into a generally accepted process model.
• Identify major IT resources that organizations can use.
• Define control objectives for management to consider.

For the purposes of this toolkit, process models and control objectives are extremely important and are
directly linked to creating and using security baselines.
The COBIT framework calls out the "Manage the configuration" process as part of the Deliver and
Support IT focus area. This callout is commonly referred to as DS9, and organizations can use it as
both a control objective for setting controls and as an audit objective to help ensure that the controls
are in place and working correctly.
DS9 Manage the Configuration ensures the integrity of hardware and software configurations and
requires the establishment and maintenance of an accurate and complete configuration repository. This
process includes collecting initial configuration information, establishing baselines, verifying and
auditing configuration information, and updating the configuration repository as needed.
Specific control objectives that apply to the Manage the Configuration process include the ability to:
• Establish a supporting tool and a central repository to contain all relevant information about
configuration items. Monitor and record all assets and changes to assets. Maintain a baseline of
configuration items for every system and service as a checkpoint to return to after changes.
• Identify and maintain configuration items by establishing configuration procedures to support

management and log all changes to the configuration repository. Integrate these procedures with
change management, incident management, and problem management procedures.
• Establish configuration integrity review by periodically reviewing the configuration data to verify
and confirm the integrity of the current and historical configuration. Periodically review installed
software against the policy for software usage to identify personal or unlicensed software or any
software instances in excess of current license agreements. Report and correct errors and
deviations.
To measure the control objective performance, organizations can:
• Track the number of business compliance issues caused by improper asset configurations.
• Track the number of deviations identified between the configuration repository and the actual
asset configurations.
• Track the percent of licenses purchased but not accounted for in the repository.
Throughout this process, review the provisions and control objectives of COBIT with regard to
configuration control. A key concept in configuration control is the establishment of a baseline or a
point of reference, such as a configuration baseline from which organizations can measure any
configuration deviation.
FISMA, HIPAA, GLBA, and ISO 27002

The Federal Information Security Management Act (FISMA) of 2002 is a US federal law designed to
improve computer and network security within the Federal Government and affiliated parties.
The Health Insurance Portability and Accountability Act (HIPAA) was enacted in 1996 and consists of
two parts: Title I protects health insurance coverage for workers when they change or lose their jobs,
and Title II focuses on Administrative Simplification provisions and addresses the security and privacy
of health data.
The Gramm-Leach-Bliley Act (GLBA) of 1999 allows commercial and investment banks to consolidate
and is a mandatory law. As part of GLBA, the following three privacy-oriented rules are enforced:
• Financial Privacy Rule
• Safeguards Rule
• Pretexting Prevention
These three rules are directly applicable to security baseline configuration and require privacy notices,
risk management for financial information, and the prevention of pretexting (social engineering) to
access nonpublic financial information.
ISO 27002 (formerly ISO 17799), which is the Information Technology — Security Techniques — Code
of practice for information security management, is most closely aligned with these three regulations
because they directly address information security.
ISO 27002 provides practice standards and, more importantly, a well designed and manageable method
that organizations can use to ensure information system security. This document is lengthy, and
requires careful study to implement its provisions. The following provides a high-level summary of
sections in it that apply to security baseline compliance:
• Management of assets, including responsibility for assets, inventory of assets, ownership of

assets, and the acceptable use of those assets.
• Monitoring and logging of information system use, log auditing, log information protection,
protection and management of administrator and operator logs, and fault logging.
• Configuration and maintenance of operating system access control provisions. These provisions
include secure logon, user identification and authentication, password management, the use of
system utilities, and session time-out.
• Compliance with legal requirements, security policies and standards, and technical compliance.
This section includes considerations for information systems audits.
This overview of the provisions of ISO 27002 does not include much more detailed information that is
available in the original document. What is important to note is that all of these standards in some way
relate to or use a configuration baseline to ensure control and identify configuration drift or deviation.

Chapter 1: Plan 5
EUDPD/COBIT and the AICPA/CICA Privacy

and Trust Services Framework
The European Union Data Privacy Directives (EUDPD) forms a shortened description of two EU privacy
directives. The first of these is Directive 95/46/EC on the protection of personal data, which was initially
adopted in 1981. The second is the Directive on Privacy and Electronic Communications adopted in
2002, which is also known as the E-Privacy Directive. These two directives address informed consent to
the persons whose data is stored and moved, and provide for security of services. It is the duty of the
service provider to inform the subscribers when there is a risk to their data, such as a data breach or a
malware attack. The second directive is also specific in the service provider’s obligation to protect the
confidentiality of the information being maintained. Provisions prohibit the listening, tapping, storage,
or interception of communication and related traffic unless the users have consented to those
activities.
Directive 2002/58 includes three main provisions to prohibit:
• Data retention and use. Service providers must erase or make anonymous data that is no longer
needed. This provision includes a statue of limitations on the use or reuse of data unless the data
subjects are notified about why and for how long the data may be processed.
• The use of e-mail addresses for marketing purposes, unless the data subjects opt in for the reuse
of their e-mail addresses. This provision excludes existing customer relationships and the
marketing of similar goods or services.
• The use of cookie information (or similar technology) for the storage of information about data
subjects.
Another framework that is closely aligned with privacy is the Generally Accepted Privacy
Principles from the American Institute of Certified Public Accountants (AICPA). In addition to that
document, the document Trust Services Principles, Criteria and Illustrations for Security, Availability,
Processing Integrity, Confidentiality, and Privacy (Including WebTrust and SysTrust) that is available
from AICPA provides a broad coverage of many IT governance principles. An excellent resource that
you can use to compare international privacy concepts is "Appendix B: Comparison of
International Privacy Concepts" on the AICPA Web site.
Of the 10 generally accepted privacy principles from the Generally Accepted Privacy Principles, the
following three are closely coupled with a security baseline:
• Disclosure to third parties.
• Security.
• Monitoring and enforcement.

All three of these privacy principles have some form of association with the operating system security
baselines that this toolkit prescribes.
PCI DSS and the Payment Card Industry

The PCI Data Security Standard (PCI DSS) was founded by American Express, Discover Financial
Services, JCB, MasterCard Worldwide, and Visa International. The PCI DSS has 12 broad requirements
grouped into six logically related groups that are similar to control objectives. For more information
about this data security standard set by the payment card industry, download the Payment Card
Industry (PCI) .pdf file.
Unlike the regulations and frameworks discussed up to this point in this guide, the PCI DSS is very
specific about practice standards or requirements that organizations must implement. It also includes a
program for Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs) to provide a
uniform, global approach to account data protection.
Substantial fines are levied on organizations that use Payment Card Industry services but do not meet
these industry-specified standards. Because both the number and value of transactions worldwide that
use Payment Card Industry services is quite large, this standard has everyone’s attention.
The current version (1.1) of the PCI DSS includes the six control objectives and 12 requirements. Many
of these controls and requirements cannot be automated at present, but two are directly applicable to a
security baseline and this toolkit meets these two requirements. They are discussed in greater detail
later in this guide.

Internal Compliance Requirements

Enterprises can address strong internal compliance requirements with baseline compliance. Industries
such as banking, financial services, healthcare, pharmaceuticals, and food processing are under close
supervision by regulatory agencies.
One of the most important compliance tests that auditors ask of organizations is to answer the
question: "Does actual operational performance match your stated policy and procedures?"
Organizations must meet internal compliance requirements to pass this test. To meet these internal
requirements, organizations often subdivide them into security requirements and policy requirements.
The following sections explore these two internal compliance requirement groupings. As organizations
have rushed to establish technical controls for compliance, management server products, such as
Microsoft System Center Configuration Manager 2007 SP1, have become recognized for their ability to
provide strong configuration management, which is a cornerstone of internal compliance.
Security Requirements
Company intellectual property and trade secrets provide clear examples of internal security
compliance. For example, in a software product company the compiled binary software is probably its
most sensitive intellectual property, so aligning the company's systems and infrastructure to protect it
is a very high priority. Similarly, among companies in manufacturing industries, such as those that
produce chemicals, metals, pharmaceuticals, and cosmetics, the process of manufacturing is the
critical intellectual property of these firms.
In both of these examples, the software and the manufacturing processes are likely stored on the IT
systems of these companies. For this reason, any deviation from the desired configuration baseline of
these IT systems places intellectual property at risk. In a sales-driven organization, customer lists and
sales information stored in sales systems is the heart of the organization. This information must be
protected because it includes customer names, specifies sales amounts, sales margins, and products
sold.
To better meet these security requirements, using a tool to automate the process to establish security
baselines, such as the GPOAccelerator, helps to shift the burden of security from people to technology.
This approach frees people in the organization to do more productive work, while helping to prevent or
identify mistakes in the system software that the organization uses.
Policy Requirements
At a high level, the purpose of policy in a business environment is to provide guidelines for desired
behavior. The guidelines can be for both humans and computers. However, often the organizations
involved enforce the desired behavior using computers. A baseline configuration can be a direct
example of such a policy.
For example, a company could decide to set up and maintain all client computers using a specific
configuration baseline for ease of maintenance. The ability to automate establishing the baseline
setting configuration, and then monitoring the baseline for adherence to the original settings reduces
overhead and improves the accuracy and reliability of the settings. Moreover, using automation to
configure and monitor the more than 300 security settings available in client and server operating
systems from Microsoft can save a significant amount of effort for organizations.

Chapter 1: Plan 7
Other compliance policy examples that organizations can implement when establishing an operating
system baseline could include the following security measures:
• Other organization and vendor security controls.
• Appropriate access.
• Separation of duties.
• System usage.
• Customer data privacy.

Other organizations and vendors can be required by company policy to comply with operating system
configuration security measures, and depending on access agreements and Service Level Agreements
(SLAs), companies also can test and verify that the settings that enforce these requirements are
maintained. Specialized security settings can also be levied on other organizations and vendors by
enterprises and government entities that require stronger security.
Organizations can limit access to information assets with permissions and limit specific actions on
data. Access control and verification is set and monitored by the system settings on operating systems
in the infrastructure. Some level of separation of duties can be maintained with user roles and access
rights defined according to those roles.
Appropriate use, and the actual time of use also can be controlled by system settings. Finally, access to
data that contains customer data in both processed and raw form can be controlled to eliminate privacy
infractions by configuring the operating systems in use.
Establish a Plan
After defining the compliance goals for your organization, the next task is to establish a security
compliance plan. The major components of this step are to pick a framework, know your environment,
determine your security baseline, document the plan, and then customize the Configuration Packs that
you use as needed. Due to the operational complexities of implementing security compliance, Microsoft
recommends to formally document the plan or create a road map that fully defines it.
Pick a Framework
Making the connection between control objectives and regulatory requirements is important and
sometimes difficult. For this reason, the following sections provide examples of how common
frameworks relate to the security compliance process. These examples relate closely to the compliance
monitoring capabilities this toolkit prescribes. As mentioned earlier, the is a good source on mapping
frameworks to regulations.

COBIT
The control objective category Deliver and Support DS9 "Manage the Configuration" has several control
objectives that directly apply to the monitoring process of a security baseline. The Security Compliance
Management Toolkit can meet this control objective. The following table describes the DS9 control
objectives.
Table 1.1 COBIT Framework Objectives
Objective Framework language

DS9.1 Configuration Establish a supporting tool and a central repository to contain all
Repository and Baseline relevant information about configuration items. Monitor and record all
assets and changes to assets. Maintain a baseline of configuration
items for every system and service as a checkpoint to return to after
changes are made.
DS9.2 Identification and Establish configuration procedures to support management and the
Maintenance of logging of all changes to the configuration repository. Integrate these
Configuration Items procedures with change management, incident management, and
problem management procedures.
DS9.3 Configuration Periodically review the configuration data to verify and confirm the
Integrity Review integrity of the current and historical configuration. Periodically
review installed software against the policy for software usage to
identify personal or unlicensed software or any software instances in
excess of current license agreements. Report and correct errors and
deviations.
The monitoring process of a security baseline directly applies to objective DS9.1 "Maintain a baseline of
configuration." It also applies to DS9.3 "Periodically review the configuration data to verify and confirm
the integrity of the current and historical configuration."
ISO 27002
ISO 27002, which is the renamed ISO17799:2005, has several direct links to the monitoring process of a
security baseline.
Table 1.2 ISO 27002 Framework Objectives

10.10 Monitoring Objective: To detect unauthorized information processing activities.
Systems should be monitored and information security events should
be recorded. Operator logs and fault logging should be used to ensure
information system problems are identified.
An organization should comply with all relevant legal requirements
applicable to its monitoring and logging activities.
System monitoring should be used to check the effectiveness of
controls adopted and to verify conformity to an access policy model.
11.5 Operating System Objective: To prevent unauthorized access to operating systems.
Access Control
Security facilities should be used to restrict access to operating
systems to authorized users. The facilities should be capable of the
following:
• Authenticating authorized users, in accordance with a defined

access control policy.
• Recording successful and failed system authentication attempts.
• Recording the use of special system privileges.
• Issuing alarms when system security policies are breached.
• Providing appropriate means for authentication.
• Where appropriate, restricting the connection time of users.

Chapter 1: Plan 9

15.2.1 Technical Control:
Compliance Checking
Information systems should be regularly checked for compliance with
security implementation standards.
Technical compliance checking involves the examination of
operational systems to ensure that hardware and software controls
have been correctly implemented. This type of compliance checking
requires special technical expertise.
The monitoring process of a security baseline meets the requirement of objective 10.10 Monitoring, and
security baseline settings almost entirely cover objective 11.5 Operating System Access Control. The
monitoring process also ensures that the security baselines are implemented and maintained correctly
as required in 15.2.1 Technical Compliance Checking.
AICPA/CICA Privacy and Trust Services Framework

The AICPA Generally Accepted Privacy Principles (GAPP) discussed earlier in this overview defines
three areas that directly apply to the Security Compliance Management Toolkit. The following sections
discuss related principles.
Disclosure to Third Parties

The seventh principle of GAPP, Disclosure to Third Parties, requires that the entity disclose personal
information to third parties only for the purposes identified in the notice, and only with the implicit or
explicit consent of the individual according to the following criteria:
• Design procedures and controls to ensure that personal information is disclosed only for the
purposes described in the notice, and only information for which the individual has provided
consent will be disclosed, unless a law or regulation specifically allows or requires otherwise (see
Criterion 7.2.1).
• Design procedures and controls to ensure that personal information is disclosed only to third
parties that have agreements with the entity to protect personal information from loss, misuse,
unauthorized access, disclosure, alteration, and destruction (see Criterion 7.2.2).
• Design procedures and controls to ensure that personal information is disclosed to third parties
for new purposes or uses only with the prior consent of the individual (see Criterion 7.2.3).
Security
The eighth principle of GAPP, Security for Privacy, requires that the entity protect personal information
against unauthorized access (both physical and logical) according to the following criteria:
• Design privacy policies that address the security of personal information (see Criterion 8.1.0).
• Communicate to individuals the precautions that are taken to protect personal information (see
Criterion 8.1.1).
• Design procedures and controls that ensure that a security program has been developed,
documented, approved, and implemented that includes administrative, technical, and physical
safeguards to protect personal information from loss, misuse, unauthorized access, disclosure,
alteration, and destruction (see Criterion 8.2.1).
• Design procedures and controls to ensure that logical access to personal information is
appropriately restricted (see Criterion 8.2.2).
• Design procedures and controls to ensure that physical access to personal information in any form
is appropriately restricted (see Criterion 8.2.3).
• Design procedures and controls to ensure that personal information, in all forms, is protected
against unlawful destruction, accidental loss, natural disasters, and environmental hazards (see
Criterion 8.2.4).

• Design procedures and controls to ensure that personal information is protected when transmitted
by e-mail over the Internet and through public networks by deploying industry-standard encryption
technology for transferring and receiving personal information (see Criterion 8.2.5).
• Design procedures and controls to ensure that tests of the effectiveness of the key administrative,
technical, and physical safeguards protecting personal information are conducted at least annually
(see Criterion 8.2.6).
Monitoring and Enforcement

The last principle of GAPP, Monitoring and Enforcement, requires that the entity monitor compliance
with its privacy policies and procedures and uses procedures to address privacy-related inquiries and
disputes according to the following criterion:
• Design procedures and controls to ensure that instances of noncompliance with privacy policies
and procedures are documented and reported and, if needed, corrective measures are taken on a
timely basis (see Criterion 10.2.4).
By ensuring that security baselines are implemented correctly, due care has been exercised to prevent
disclosure to other companies, security provisions are in place to prevent access by unauthorized
persons, and the technical underpinnings are in place to monitor and enforce security for the
environment. The process to establish a security baseline directly addresses these requirements.

Chapter 1: Plan 11
PCI DSS
The Payment Card Industry Digital Data Security (PCI DSS) has 12 broad requirements grouped into 6
logically related groups that are similar to control objectives. Of these control objectives and
requirements, the following requirement is directly applicable to the Security Compliance Management
Toolkit:
• Requirement 2: Do not use vendor-supplied defaults for system passwords and other security
parameters.
The following table includes provisions of PCI DSS that the security baselines address.
Table 1.3 PCI DSS Requirements
Requirement Framework language

2.1 Always change vendor-supplied defaults before installing a system on the
network. For example, include passwords, simple network management protocol
(SNMP) community strings, and elimination of unnecessary accounts.
2.1.1 For wireless environments, change wireless vendor defaults, including but not
limited to, wired equivalent privacy (WEP) keys, default service set identifier
(SSID), passwords, and SNMP community strings. Disable SSID broadcasts.
Enable WiFi protected access (WPA and WPA2) technology for encryption and
authentication when WPA–capable.
2.2 Develop configuration standards for all system components. Assure that these
standards address all known security vulnerabilities and are consistent with
industry-accepted system hardening standards. For example, those defined by the
SysAdmin Audit Network Security Network (SANS), the National Institute of
Standards Technology (NIST), and the Center for Internet Security (CIS).
2.2.1 Implement only one primary function per server. For example, Web servers,
database servers, and DNS should be implemented on separate servers.
2.2.2 Disable all unnecessary and unsecure services and protocols (services and
protocols not directly needed to perform the devices’ specified function).
2.2.3 Configure system security parameters to prevent misuse.
2.2.4 Remove all unnecessary functionality, such as scripts, drivers, features,
subsystems, file systems, and unnecessary Web servers.
2.3 Encrypt all nonconsole administrative access. Use technologies such as SSH,
VPN, or SSL/TLS (transport layer security) for Web-based management and other
nonconsole administrative access.
2.4 Require hosting providers to protect each entity’s hosted environment and data.
These providers must meet specific requirements as detailed in Appendix A, "PCI
DSS Applicability for Hosting."

Know the Environment

Ensure to gather key information about your IT environment. For example, if you are running Systems
Management Server (SMS) or Configuration Manager 2007 SP1, the computer management topology
must be available. Key mapping information for baseline compliance from an IT infrastructure
perspective includes the following information:
• Site collections.
• Computer names.
• Operating systems.
• Hardware profiles.
• Computer roles (member server, domain controller).
• Computer names for line-of-business software (ERP server, CRM server, and so on).
• Specific line-of-business software Group Policy requirements.
• Legacy application location by computer name.

From a compliance perspective, you also must be able to map both external regulatory requirements
and internal compliance requirements to key information such as:
• Control objectives.
• Technical controls.
• Test/audit frequency.
• Control objectives to computer names.
• Control objectives to site collections.
• Group control objectives by technology (configuration items).

Ensure to carefully identify your environment and the control objectives that apply to your enterprise.
Without a one-to-one mapping of the elements for the computers, site collections, hardware profiles,
and computer roles in your organization, the Configuration Packs in this toolkit cannot provide an
accurate validation of the settings applied to your computers.
Determine a Security Baseline

Microsoft recommends to use the Windows Vista Security Guide, the Windows XP Security
Guide, the Windows Server 2008 Security Guide, the Windows Server 2003 Security
Guide, and the 2007 Microsoft Office Security Guide as references to initially determine the risk
posture of your organization. You can use the GPOAccelerator tool to establish security baselines for
each of these operating systems.
If your organization's security posture sufficiently matches the prescribed settings in these guides for
either the Enterprise Client (EC) environment or the Specialized Security – Limited Functionality (SSLF)
environment, Microsoft recommends to use one or the other of these security baselines.
Important The security settings for the EC environment are recommended for the
majority of domain-joined enterprises. However, Microsoft only recommends the
security settings for the SSLF environment for organizations in which the need for
security outweighs functionality.
However, if your organization determines that its security needs require some adjustment from either
the EC or SSLF security baselines, develop a plan to implement modifications to meet these security
requirements. Most importantly, after determining the security baselines for your environment, declare
it to be your security baseline, and document a plan to implement and monitor it using the Security
Compliance Management Toolkit.
Document the Plan

At this stage in the security compliance management process, carefully document all aspects of your
plan. If you can divide the computers in your environment into multiple site collections with multiple

Chapter 1: Plan 13
roles, decide which of the 26 configuration baselines that this toolkit prescribes best match the
computer organization in your environment, and then stick with it.
While documenting the plan, also decide which of the Configuration Packs for this toolkit meet your
control objectives and document that information. If your organization has control objectives that the
Configuration Packs do not meet, decide how to customize the Configuration Packs to meet them and
document that information.
If you have line-of-business software or legacy applications that require control objectives and Group
Policy settings that conflict with the configuration baselines this toolkit prescribes, place them in a
separate site collection and do not apply the provided configuration baselines to it.
When documenting your security configuration plan, it is also important to create a change control
process to record authorized changes to satisfy future audits. It is a best practice to also document
backup plans in conflicts occur, and to create a formal risk control plan. The Microsoft Deployment
Toolkit Solution Accelerator provides a good source of information about these topics.
The configuration baselines provided with this toolkit require you to customize settings as needed to
meet the specific compliance requirements of your organization. The process and procedures to
customize settings in the Configuration Packs are included in the DCM Configuration Pack User Guide
for this toolkit.
Customize Configuration Packs

During the planning step, if you selected a security baseline that requires you to modify either the EC
security baseline or the SSLF security baseline, you must customize the Configuration Packs that the
Security Compliance Management Toolkit provides to match these settings.
When modifying the Configuration Packs with custom settings, administrators should carefully
document why the organization is customizing them. The ability to review changes and understand why
and how setting customization occurred might be critical for incident management in the future, or if
you need to roll back to previous settings for the computers in the environment. For more information
about customizing Configuration Packs to meet business requirements, see the companion document
DCM Configuration Pack User Guide.
Common reasons to consider customization are to comply with internal or external business mandates.
For example, the Defense Intelligence Agency (DIA) has published a series of setting recommendations
for the operating systems in scope for this toolkit that was mandated by the nature and scope of
organizations with which it conducts business. If your organization needs to deploy specific settings to
comply with this mandate, use those settings instead of the ones recommended in this security
guidance.
Similarly, if your organization does not provide an Internet connection that is always in use, you might
need to customize some of the security guide settings. The DCM feature in Configuration Manager 2007
SP1 requires a connection to the Internet that is always in use to provide continuous monitoring.
Specific line-of-business (LOB) applications, such as a CRM or an ERP system, also might require you
to customize the Configuration Packs. Specific reasons and situations for such customization vary by
application and how they are implemented in each environment.
Because the Configuration Packs for this toolkit are built to align with recommended security baselines
from Microsoft, any customization carries some level of risk. Microsoft recommends to perform a
customization risk assessment, and then proceed with the customization effort with full knowledge that
the organization must absorb some level of risk. A good source of risk management information is
contained in the Security Risk Management Guide.
Related Resources
The following resources provide additional information about security topics and in-depth discussion
of the concepts and security prescriptions in this toolkit:
• "Appendix B: Comparison of International Privacy Concepts" from the American Institute

of Certified Public Accountants (AICPA).
• Audit Collection with Microsoft System Center Operations Manager 2007 .pdf file.
• Compliance Convergence Initiative (CCI).
• Generally Accepted Privacy Principles from AICPA.

• ISO 27002 (formerly ISO 17799).
• 2007 Microsoft Office Security Guide.
• Microsoft Assessment and Planning.
• Microsoft Windows Security Resource Kit.
• Microsoft Windows Server 2003 Resource Kit.
• PCI Data Security Standard.
• .
• Security Guidance Web page on Microsoft TechNet.
• Security Risk Management Guide.
• Solution Accelerator for Microsoft Deployment Toolkit.
• System Center TechCenter.
• Threats and Countermeasures.
• Windows Server 2008 Security Guide
• Windows Vista Security Guide.
• Windows XP TechCenter.
• Windows XP Security Guide.

Chapter 2: Deploy
The Deploy step (establishing recommended operating system security baselines) is the first
prescriptive step in the overall security compliance management process for this toolkit. You can use
the recommended tools and resources to complete this step, which follows the Plan step and precedes
the Monitor step, in the following figure.
Figure 2.1 Security compliance management – Deploy step
In the Windows Vista Security Guide, Windows XP Security Guide, Windows Server 2008 Security
Guide, Windows Server 2003 Security Guide, and the 2007 Microsoft Office Security Guide, Microsoft
provides recommended security baselines for two operating system environments: the Enterprise
Client (EC) environment, and the Specialized Security Limited Functionality (SSLF) environment. The
security guides include detailed descriptions of the settings that support these environments. In short,
the baselines for the EC environment are recommended for most domain-joined enterprise
environments, whereas the baselines for the SSLF environment are designed for environments in which
the need for security outweighs functionality.
You can implement the required baselines either manually or automatically. However, Microsoft also
provides the GPOAccelerator tool that you can use to perform an automated installation. The
GPOAccelerator is designed for you to deploy the appropriate settings on computers running these
operating systems in a domain-joined enterprise.
It is important to note that the manual method is extremely time-consuming. It requires the user to
deploy the operating system settings using the Group Policy Management Console (GPMC), the
Registry Editor (Regedit.exe), traverse the Windows Management Instrumentation (WMI) interface using
the command prompt, write scripts, configure Windows Firewall settings, and use other interfaces for
these operating systems.
Note This is an error-prone process, which relies on the use of "approved" images
that are created based on operating system hardware configurations and user roles. As
the enterprise rolls out clean installations, the images require modifications to reflect
updates and changes in the environment.
Windows and Office Security Guides

Detailed discussions on recommended security baselines from Microsoft are contained in the guides
this toolkit prescribes. For more background, operational considerations, and details about the
baselines, see the following guides:
• Windows Vista Security Guide
• Windows XP Security Guide
• 2007 Microsoft Office Security Guide
The GPOAccelerator Tool

The GPOAccelerator tool automatically deploys the GPO–based security recommendations from the
Windows XP Security Guide and the Windows Vista Security Guide. For the purposes of this toolkit,
Microsoft recommends to run the GPOAccelerator as part of the deployment process to implement the
security baselines before you use the DCM feature in Configuration Manager 2007 SP1.
Customization
When customizing security settings, users that stay within the bounds of the prescribed EC or SSLF
security baseline settings can remain assured that the settings were tested and verified. Staying "within
the bounds" of the security baselines for these environments means that the security configuration you
use is not degraded from the EC security baseline and is not more secure than the SSLF security
baseline. If your organization is considering whether to use the SSLF security baseline, it is important
to understand that the settings for this security baseline limit the performance and functionality of the
computers in your environment.
Another approach to customization is to use iteration, which is much like mathematical iteration, in
which settings are modified in small increments and rigorously tested by users. Through this process,
users can develop set boundary conditions to provide security for specific user environments.
Warning The SSLF security baseline is not intended for most organizations. The
settings for this baseline were developed for organizations in which security is more
important than functionality.
Related Resources
The following resource provide additional information about security topics and in-depth discussion of
the concepts and security prescriptions in this toolkit:
• System Center Configuration Manager 2007

Chapter 3: Monitor
The Monitor step in the process checks for the existence of settings and validates that the existing
settings have the proper values. The Monitor step is the third step in the overall compliance
management process for this toolkit. You can use the recommended resources to complete this step in
the following figure.
Figure 3.1 Security compliance management – Monitor step
The Monitor step is what makes this toolkit unique. It uses the DCM feature of Configuration Manager
2007 SP1 to validate existential rules (settings that exist) and that the settings conform to the validation
rules for them. The DCM feature offers the first truly automated method to perform the monitoring
process from Microsoft.
Manual methods for baseline compliance and security configuration control rely heavily on "approved"
images that IT uses for all client and server computers. Typically, the server images have not been
optimized for specific server roles. Instead, the images are customized as each new software set is
added and deployed.
Image modification starts the cycle of configuration drift or deviation from the baseline configuration
for the operating system. Configuration drift occurs primarily during the process of daily business-
related activities. However, if a malicious act compromises the company's IT assets, it becomes difficult
to differentiate it from otherwise typical drift.
Each operating system and application security guide discusses approximately 300 settings that must
be checked and verified, which is a tedious job. Checking operating settings also has an operational
timing dependency. The timing dependency is most prevalent on the client side, and involves mobile
devices such as laptops that are not always connected to the network. To check operating settings on
these devices, setting scans must be performed several times a day and at peak operating hours for
mobile users.
The primary purpose of this toolkit is to provide you with an automated method to check and monitor
the state of operating system security baseline compliance on the computers in your environment. It
relies on the availability of the DCM feature in Configuration Manager 2007 SP1, and the connectivity of
the operating systems in your environment to access the DCM node of this software. You can control
DCM scans and reporting to specify the configuration items that you want to check, the frequency of
checks, and the reports that you want to generate. For more information about working with the DCM
feature, see the companion document DCM Configuration Pack User Guide.
Configuration Packs
The Security Compliance Management Toolkit Series provides 26 Configuration Packs that are prebuilt
for you to use with the DCM feature. The companion document, DCM Configuration Pack User Guide,
lists the 26 Configuration Packs. For a detailed discussion of operational issues related to running the
DCM feature in a production environment, see System Center Configuration Manager 2007.
DCM Configuration Pack User Guide

The DCM Configuration Pack User Guide contains step-by-step instructions about how to load the 26
Configuration Packs, apply them to site collections, and customize them as needed. It also contains a
more detailed discussion on how to select a Configuration Pack for a site collection, and how to deal
with exceptions. In addition, the guide discusses how to run reports. For more information about these
topics, see the DCM Configuration Pack User Guide, which is included in the Security Compliance
Management Toolkit .zip file archive.
Configuration Pack Customization

If the security baselines you select for your environment deviate from the security baselines that the
Security Compliance Management Toolkit provides, you need to customize the Configuration Packs for
this toolkit. The DCM configuration Pack User Guide contains step-by-step instructions on customizing
the Configuration Packs.
Related Resources
• System Center Configuration Manager 2007.

Chapter 4: Remediate
The final step in this process is to remediate or fix any problems found in the monitoring step. You can
use the recommended tools and resources in the following figure to help you complete this step.
Figure 4.1 Security compliance management – Remediate step

After finding a setting problem and reporting it to an IT professional, the setting must be reset or
remediated to correct it. This section discusses some methods you can use to remediate security
baselines for the operating systems in scope for this toolkit. Possible remediation methods include the
ability to do the following:
• Run the GPOAccelerator again. You can rerun the GPOAccelerator to remediate a specific
configuration error. However, it is important to note that you cannot target this tool at a single
computer. You must the run the tool on the entire domain. If you have configured customized
settings for specialized security on the computers in your environment, this is not a good option.
• Use reports to focus your efforts. You can apply a Configuration Pack and then rerun the DCM
feature in Configuration Manager to create reports on specific issues. Then you can use the
reports to modify settings manually to bring them back into compliance with the baseline for your
environment.
• Prioritize setting drift. You can perform manual remediation by prioritizing setting drift severity,
and then remediating settings according to the severity ratings. Manual remediation is discussed
in detail in the security guides and in the Threats and Countermeasures Guide.
More active automation for remediation is not available from Microsoft at this time. However, there are
plans to include it with the DCM feature in a future release. Microsoft intends to provide other toolkits to
fill this gap until the enhanced DCM feature is available.
Related Resources
• Windows Vista Security Guide
• Windows XP Security Guide
• 2007 Microsoft Office Security Guide
• Threats and Countermeasures Guide

Baseline Compliance Management Overview

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Baseline Compliance Management Overview

Hochgeladen von

Copyright:

Verfügbare Formate

Baseline Compliance Management

Published: June 2008 | Updated: February 2009

Solution Accelerators microsoft.com/technet/SolutionAccelerators

The GPOAccelerator Tool..................................................................24

Solution Accelerators microsoft.com/technet/SolutionAccelerators

1. Plan how to meet security baseline requirements.

2. Deploy security baseline configurations.

3. Monitor security baseline configurations.

4. Remediate security baseline configurations.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Who Should Read This Guidance

Skills and Readiness

• Experience deploying applications and client computers in enterprise environments.

• Understand IT security principles and practices.

• In-depth knowledge of the organization’s domain and Active Directory® environments.

• Experience with the Group Policy Management Console (GPMC).

• Experience deploying applications and client computers in enterprise environments.

• Relate operating system security baselines to compliance requirements by providing security

• Demonstrate how to customize security baselines to meet specific compliance needs.

• Windows Vista SP1

• Windows XP Professional SP3

• Windows Server 2008

• Windows Server 2003 SP2

• 2007 Microsoft Office SP1

• Windows Vista Security Guide.

• Windows XP Security Guide.

• Windows Server 2008 Security Guide.

• Windows Server 2003 Security Guide.

• 2007 Microsoft Office Security Guide.

<Italic> Placeholders set in italic and angle brackets <filename> represent

Monospace font Defines code and script samples.

Note Alerts the reader to supplementary information.

Important An important note provides information that is essential to the completion of

Support and Feedback

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Manish Patel – Infosys Technologies Ltd

Contributors and Reviewers

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Figure 1.1 Security compliance management – Planning step

Regulatory Compliance Requirements

• IT Compliance Management Guide from Microsoft.

• Compliance Convergence Initiative (CCI) framework from the IT Compliance Institute.

• Software Development Life Cycle

SOX and COBIT

• Create links to business requirements.

• Organize IT activities into a generally accepted process model.

• Identify major IT resources that organizations can use.

• Define control objectives for management to consider.

• Identify and maintain configuration items by establishing configuration procedures to support

FISMA, HIPAA, GLBA, and ISO 27002

• Financial Privacy Rule

• Management of assets, including responsibility for assets, inventory of assets, ownership of

Solution Accelerators microsoft.com/technet/SolutionAccelerators

EUDPD/COBIT and the AICPA/CICA Privacy

• Disclosure to third parties.

• Monitoring and enforcement.

PCI DSS and the Payment Card Industry

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Internal Compliance Requirements

Solution Accelerators microsoft.com/technet/SolutionAccelerators

• Other organization and vendor security controls.

• Customer data privacy.