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 seemicrosoft.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

ContentsIntroduction................................................................................................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 COBIT..................................................................................................10

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

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

Customization..........................................................................................................24

SOLUTIONACCELERATORS microsoft.com/technet/SolutionAccelerators


Chapter 3: Monitor....................................................................................25

Configuration Packs.................................................................................................26

DCM Configuration Pack User Guide........................................................................26

Configuration Pack Customization...........................................................................26


Chapter 4: Remediate................................................................................27



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.


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 3

Who Should Read This GuidanceThe 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 ReadinessThe 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.

PurposeThe 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.


http://go.microsoft.com/fwlink/?LinkID=21158

http://go.microsoft.com/fwlink/?LinkID=21158

4 Baseline Compliance Management Overview

Use Configuration Manager 2007 SP1 and the DCM feature to check and verify settings on specified operating systems.

ScopeThe information in this toolkit applies only to the following applications and tools:

System Center Configuration Manager 2007 SP1 and the DCM feature.

GPOAccelerator tool.

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.

RequirementsYou 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 .

ComponentsUse 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.


http://go.microsoft.com/fwlink/?LinkId=113939






Introduction 5

Style ConventionsThis 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 FeedbackThe 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: [email protected].

We look forward to hearing from you.


mailto:[email protected]?subject=Security%20Compliance%20Management%20toolkit

http://forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=1817&SiteID=17


AcknowledgmentsThe 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 TeamDevelopment 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


Introduction 7

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

Manish Patel – Infosys Technologies Ltd

Contributors and ReviewersJeremiah 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 BackgroundCompliance 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 RequirementsCurrently, 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.


http://www.itcinstitute.com/cci/


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

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 COBITThe 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.


Chapter 1: Plan 11

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 27002The 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.

EUDPD/COBIT and the AICPA/CICA Privacy and Trust Services FrameworkThe 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


http://www.27000.org/

Chapter 1: Plan 13

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 IndustryThe 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.


https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf

http://infotech.aicpa.org/Resources/Privacy/Generally+Accepted+Privacy+Principles/Generally+Accepted+Privacy+Principles+Appendixes/Appendix+B+Comparison+of+International+Privacy+Concepts.htm


http://infotech.aicpa.org/Resources/Privacy/Generally+Accepted+Privacy+Principles/Generally+Accepted+Privacy+Principles/



Internal Compliance RequirementsEnterprises 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 RequirementsCompany 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 RequirementsAt 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 15

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 PlanAfter 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 FrameworkMaking 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 IT Compliance Management Guide is a good source on mapping frameworks to regulations.




COBITThe 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 Repository and Baseline

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 are made.

DS9.2 Identification and Maintenance of Configuration Items

Establish configuration procedures to support management and the logging of all changes to the configuration repository. Integrate these procedures with change management, incident management, and problem management procedures.

DS9.3 Configuration Integrity Review

Periodically review 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.

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 27002ISO 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


Chapter 1: Plan 17


effectiveness of controls adopted and to verify conformity to an access policy model.

11.5 Operating System Access Control

Objective: To prevent unauthorized access to operating systems.

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.

15.2.1 Technical Compliance Checking

Control:

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 FrameworkThe 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 19

PCI DSSThe 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 EnvironmentEnsure 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 BaselineMicrosoft 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









Chapter 1: Plan 21

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 PlanAt 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 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 PacksDuring 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.


http://go.microsoft.com/fwlink/?linkid=109148


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 ResourcesThe 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 .

IT Compliance Management Guide .

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 .













https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf





http://www.27000.org/


http://www.itcinstitute.com/cci/





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 GuidesDetailed 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 ToolThe 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.

CustomizationWhen 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 ResourcesThe 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 PacksThe 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 GuideThe 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 CustomizationIf 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.


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.


Windows Vista Security Guide

Windows XP Security Guide









2007 Microsoft Office Security Guide

Threats and Countermeasures Guide





Baseline Compliance Management Overview

Documents

Transcript of Baseline Compliance Management Overview