Task 2 RMF_Configuration Management Plan.docx

FOR OFFICIAL USE ONLY

{ACRONYM}

SECURITY-FOCUSED CONFIGURATION MANAGEMENT PLAN {DATE}

{COMMAND}

{SYSTEM NAME} {ACRONYM}

System Version: {VERSION} eMASS# {EMASS#}

Confidentiality: {CONFIDENTIALITY} Integrity: {INTEGRITY} Availability: {AVAILABILITY}

Department of the {SERVICE}

{LOGO}

Security-Focused Configuration Management Plan (Sec-CM) Document Version: 1.0.0

{DATE}

Prepared by: {ORGANIZATION}

DISTRIBUTION IS LIMITED TO U.S. GOVERNMENT AGENCIES AND THEIR CONTRACTORS.

OTHER REQUESTS FOR THIS DOCUMENT MUST BE REFERRED TO: {ORGANIZATION}

Change Record

Amplifying Guidance

i. NIST Special Publication 800-128, "Guide for Security-Focused Configuration Management of Information Systems"

Table of Contents

1.0 OVERVIEW

Security-Focused Configuration Management (SecCM) is the management and control of secure configurations for an information system to enable security and facilitates the management of risk. SecCM builds on the general concepts, processes, and activities of configuration management by putting attention on the implementation and maintenance of the established security requirements of the organization and information systems.

This document complies with the following requirements from NIST Special Publication 800-53 Revision 4, "Security and Privacy Controls for Federal Information Systems and Organizations". A detailed compliance matrix can be found in Appendix I, “Detailed Compliance Matrix”.

Table 1 - SP-800-53v4 Compliance Matrix

2.0 INTRODUCTION

{ACRONYM} applies security-focused configuration management (SecCM) for establishing baselines and for tracking, controlling, and managing many aspects of business development and operation (e.g., products, services, manufacturing, business processes, and information technology).

2.1 Background

An information system is typically in a constant state of change in response to new, enhanced, corrected, or updated hardware and software capabilities, patches for correcting software flaws and other errors to existing components, new security threats, changing business functions, etc. Implementing information system changes almost always results in some adjustment to the system configuration. To ensure that the required adjustments to the system configuration do not adversely affect the security of the information system or the organization from operation of the information system, a well-defined configuration management process that integrates information security is needed.

2.2 System Overview

{SYSTEM DESCRIPTION}

2.3 Document Purpose

The security-focused configuration management process is critical to maintaining a secure state under normal operations, contingency recovery operations, and reconstitution to normal operations. This SecCM Plan provides:

· identification and recording of configurations that impact the security posture of {ACRONYM};

· the consideration of security risks in approving the initial configuration;

· the analysis of security implications of changes to the {ACRONYM} configuration; and

· documentation of the approved/implemented changes.

2.4 Scope

This SecCM Plan applies to all hardware and software contained within the {ACRONYM} Accreditation Boundary.

2.5 Applicable Policies and Procedures

Federal agencies are responsible for “including policies and procedures that ensure compliance with minimally acceptable system configuration requirements, as determined by the agency” within their information security program.[footnoteRef:1] Managing system configurations is also a minimum security requirement identified in FIPS 200[footnoteRef:2], and NIST SP 800-53[footnoteRef:3] defines security controls that support this requirement. [1: Federal Information Security Management Act (P.L. 107-347, Title III), December 2002 ] [2: National Institute of Standards and Technology Federal Information Processing Standards Publication 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006] [3: National Institute of Standards and Technology Special Publication 800-53, Recommended Security Controls for Federal Information Systems and Organizations, as amended]

In addition to general guidelines for ensuring that security considerations are integrated into the CM process, this document provides guidelines for implementation of the Configuration Management family of security controls defined in NIST SP 800-53 (CM-1 through CM-9).

3.0 SecCM PROGRAM

SecCM of {ACRONYM} involves a set of activities that are organized into four major phases – Planning, Identifying and Implementing Configurations, Controlling Configuration Changes, and Monitoring. It is through these phases that SecCM not only supports security for {ACRONYM}, but also supports the management of organizational risk.

Figure 2 - SecCM Process Planning Planning includes developing policy and procedures to incorporate SecCM into {ACRONYM}, and then disseminating the policy throughout the organization. Policy addresses areas such as the implementation of CM plans, integration into existing security program plans, Configuration Control Boards (CCBs), configuration change. control processes, tools and technology, the use of common secure configurations and baseline configurations, monitoring, and metrics for compliance with established SecCM policy.

Identifying and Implementing Configurations After the planning and preparation activities are completed, a secure baseline configuration for {ACRONYM} is developed, reviewed, approved, and implemented. The approved baseline configuration for {ACRONYM} represents the most secure state consistent with operational requirements and constraints. For {ACRONYM}, the secure baseline addresses configuration settings, software loads, patch levels, how {ACRONYM} is physically or logically arranged, how various security controls are implemented, and documentation. Where possible, automation is used to enable interoperability of tools and uniformity of baseline configurations across {ACRONYM}.

{ACRONYM} will utilize the DISA STIGs and IAVM Program as the configuration requirements for a secure baseline.

Controlling Configuration Changes Given the continually evolving nature of {ACRONYM} and the mission it supports, the challenge is not only to establish an initial baseline configuration that represents a secure state (which is also cost-effective, functional, and supportive of mission and business processes), but also to maintain a secure configuration in the face of the significant waves of change that ripple through {ORGANIZATION}.

In this phase of SecCM, the emphasis is put on the management of change to maintain the secure, approved baseline of {ACRONYM}. Through the use of SecCM practices, {ACRONYM} ensures that changes are formally identified, proposed, reviewed, analyzed for security impact, tested, and approved prior to implementation. As part of the configuration change control effort, {ACRONYM} employs a variety of access restrictions for change including access controls, process automation, change windows, and verification and audit activities to limit unauthorized and/or undocumented changes to {ACRONYM}.

Access restrictions will be reviewed at least every 90 days and documented in Enclosure 4. The following access restrictions are in place for {ACRONYM}:

Table 2 – Access Restrictions

Monitoring Monitoring activities are used as the mechanism within SecCM to validate that {ACRONYM} is adhering to organizational policies, procedures, and the approved secure baseline configuration. Planning and implementing secure configurations and then controlling configuration change is usually not sufficient to ensure that {ACRONYM} which was once secure will remain secure. Monitoring identifies undiscovered/undocumented system components, misconfigurations, vulnerabilities, and unauthorized changes, all of which, if not addressed, can expose {ACRONYM} to increased risk.

{ACRONYM} utilizes ACAS, SCAP and Manual Reviews to monitor the baseline configuration.

3.1 Roles and Responsibilities

The set of roles (at the organizational as well as the information system level) that are relevant to the SecCM program are defined along with the responsibilities. The responsibilities are in the context of SecCM only and are not inclusive of other non-SecCM responsibilities the roles may also have.

Information System Owner (ISO) The ISO identifies, defines, and ensures implementation of the aspects of SecCM for {ACRONYM} that have not been defined by the organization of which the information system is a part. The ISO also ensures implementation of organizational-level SecCM requirements for {ACRONYM}.

The ISO for {ACRONYM} is:

Table 3 – ISO Designation Program Manager The {ACRONYM} Program Manager develops SecCM policies and procedures, provides direction, and oversees the implementation of the SecCM program for {ACRONYM}. The SecCM Program Manager may be the SISO (or someone designated by the SISO or the CIO) at the organizational level or the ISO (or someone designated by the ISO) at the system level.

The Program Manager for {ACRONYM} is:

Table 4 – PM Designation Information System Security Officer (ISSO) The ISSO assists the ISO with implementation of SecCM for the system, conducts configuration monitoring activities (reporting and analysis), and may serve on the CCB.

The ISSO for {ACRONYM} is:

Table 5 – ISSO Designation Information System Administrator (ISA) The ISA implements agreed-upon secure baseline configurations, incorporates secure configuration settings for {ACRONYM}, and assists with security impact analyses and configuration monitoring activities as needed. In addition, the ISA may be included in the process for determining the appropriate baseline configuration for each CI and may serve on the CCB. ISAs are also responsible for complying with SecCM policies and implementing/following SecCM procedures.

The ISA for {ACRONYM} is:

Table 6 – ISA Designation Information System User (ISU) The ISU initiates change requests, assists with functional testing, and complies with SecCM requirements.

3.2 SecCM Tools

{ACRONYM} utilizes the following tools to support change requests and overarching SecCM:

Table 7 – SecCM Tools

3.3 SecCM Retention, Archiving, Storage and Solutions

Once the change has been analyzed, approved, tested, implemented, and verified, {ACRONYM} ensures that updates have been made to supporting documents such as technical designs and baseline configurations, in addition to security-related documentation such as System Security Plans, Risk Assessments, Security Assessment Reports, and Plans of Action & Milestones. In cases where there is high risk or where significant changes have been made, a system reauthorization may be required.

As changes are made to {ACRONYM} baseline configurations, the new baseline becomes the current version, and the previous baseline is no longer valid but is retained for historical purposes. If there are issues with a production release, retention of previous versions allows for a rollback or restoration to a previous secure and functional version of the baseline configuration. Additionally, archiving previous baseline configurations is useful for incident response and traceability support during formal audits.

3.4 Cryptographic Mechanisms

{ACRONYM} utilizes FIPS140-2 approved encryption algorithms to provide all security safeguards. Cryptographic mechanisms are verified through automated scans and manual reviews.

In the context of SecCM of {ACRONYM}, a configuration item (CI) is an aggregation of information system components that is designated for configuration management and treated as a single entity throughout the SecCM process. This implies that the CI is identified, labeled, and tracked during its life cycle – the CI is the target of many of the activities within SecCM, such as configuration change control and monitoring activities. A CI may be a specific {ACRONYM} component (e.g., server, workstation, router, application), a group of information system components (e.g., group of servers with like operating systems, group of network components such as routers and switches, an application or suite of applications), a non-component object (e.g., firmware, documentation), or an information system as a whole. CIs give organizations a way to decompose the information system into manageable parts whose configurations can be actively managed.

4.1.2 Identification Criteria

All assets contained within the {ACRONYM} accreditation boundary will be identified.

4.1.3 Configuration Item Labeling

Assets contained within the {ACRONYM} accreditation boundary will be labeled as follows:

· Hardware Items – label by unique hostname

· Software Items – label by manufacturer and version

4.2 Configuration Baselining

A baseline configuration is a set of specifications for {ACRONYM}, or Configuration Item (CI) within {ACRONYM}, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. The baseline configuration is used as a basis for future builds, releases, and/or changes.

The baseline configuration of {ACRONYM} may evolve over time depending on the stage of the system development life cycle (SDLC). Early in the SDLC when {ACRONYM} is being initiated and acquired, the baseline may be a set of functional requirements. As {ACRONYM} is developed and implemented, the baseline may expand to include additional configuration items such as the technical design, the software load, the architecture, and configurations of {ACRONYM} and its individual components. A baseline configuration may also represent different information computing environments such as development, test, and production.

When a new baseline configuration for {ACRONYM} is established, the implication is that all of the changes from the last baseline have been approved. Older versions of approved baseline configurations are maintained for at least 3 months and made available for review or rollback as needed.

Figure 3 – Configuration Baselining

4.2.1 Identification of Applicable Common Secure Configurations Common secure configurations are created based on requirements contained within DISA STIGs. For all assets, a combination on scripts, batch files and manual configuration will be performed to implement the initial secure state. All technologies contained within {ACRONYM} will be configured in accordance with the appropriate STIG.

4.2.2 Information System Component CI Baselines

Configurations represent the possible states in which {ACRONYM} can be arranged. Secure configurations are designed to reduce the organizational security risk from operation of {ACRONYM}, and may involve using trusted or approved software loads, maintaining up-to-date patch levels, applying secure configuration settings of the IT products used, and implementation of endpoint protection platforms. Secure configurations for {ACRONYM} are most often achieved through the application of secure configuration settings to the IT products (e.g., operating systems, databases, etc.) used to build the information system. For example, a secure configuration for selected IT products used within {ACRONYM} could incorporate the principle of least functionality. Least functionality helps to minimize the potential for introduction of security vulnerabilities and includes, but is not limited to, disabling or uninstalling unused/unnecessary operating system (OS) functionality, protocols, ports, and services, and limiting the software that can be installed and the functionality of that software.

The secure baseline is represented in the System Security Plan Hardware/Software List and Architecture Diagram. During assessment, the documented baseline is compared against the assessed baseline. This process is performed at least annually.

The following {ACRONYM} components are authorized to deviate from the approved baseline:

Table 8 – Authorized Deviations

4.2.3 Non-Component Object CI Baselines

Currently, there are no non-component CI baselines associated with {ACRONYM}.

4.2.4 Significant Risk Locations

Areas of significant risk are those physical locations that {ACRONYM}, or its components, may travel to that represent a higher threat level.

Currently, {ACRONYM} is not located in a Significant Risk Location. In the event {ACRONYM}, or any of its components, travels to a Significant Risk Location the following process will be implemented when it returns to its normal operating environment:

1. Prior to connecting to an established network, {ACRONYM} will be thoroughly evaluated for security Risk.

2. Prior to processing to additional data, {ACRONYM} will be thoroughly evaluated for security Risk.

3. Any data removed from {ACRONYM} will undergo a Virus Scan on a separate disconnected system prior to the data being moved into another environment.

NOTE: It is preferable that the {ACRONYM} asset be “wiped” and cloned from a known secure image.

4.3 Configuration Change Control

A well-defined configuration change control process is fundamental to any SecCM program. Configuration change control is the process for ensuring that configuration changes to {ACRONYM} are formally requested, evaluated for their security impact, tested for effectiveness, and approved before they are implemented. The {ACRONYM} utilizes the below overarching process to control change.

Figure 4 – Configuration Change Control

The {ACRONYM} utilizes the following process steps as part of the overarching process:

1. Request the change. A request for change may originate from any number of sources including the end user of {ACRONYM}, a help desk, or from management. Proposed changes may also originate from vendor-supplied patches, application updates, security alerts, system scans, etc. See Enclosure 2 for a Sample Change Request Template.

2. Record the request for the proposed change. A change request is formally entered into the configuration change control process when it is recorded. Organizations may use paper-based requests, emails, a help desk, and/or automated tools to track change requests, route them based on workflow processes, and allow for electronic acknowledgements/approvals.

3. Determine if the proposed change requires configuration control. Some types of changes may be exempt from configuration change control or pre-approved as defined in this plan. If the change is exempt or pre-approved, note this on the change request and allow the change to be made without further analysis or approval; however, system documentation may still require updating (e.g., the System Security Plan, the baseline configuration, IS component inventory, etc.).

4. Analyze the proposed change for its security impact on {ACRONYM} (see Section 4.3.2).

5. Test the proposed change for security and functional impacts. Testing confirms the impacts identified during analysis and/or reveals additional impacts. The impacts of the change are presented to the CCB.

6. Approve the change. This step is usually performed by the CCB. The CCB may require the implementation of additional controls if the change is necessary for mission accomplishment but has a negative impact on the security of {ACRONYM}. Implementation of additional controls is coordinated with the ISO.

7. Implement the approved change. Once approved, authorized {ACRONYM} staff makes the change. Depending upon the scope of the change, it may be helpful to develop an implementation plan. Change implementation includes changes to applicable/related configuration parameters as well as updating system documentation to reflect the change(s). Stakeholders (e.g., users, management, help desk, etc.) are notified about the change, especially if the change implementation requires a service interruption or alters the functionality of {ACRONYM}. In the case of the latter situation, user and help desk training may be required.

8. Verify that the change was implemented correctly (e.g., vulnerability scans, post-implementation security and functionality analysis, reassessment of affected security controls, etc.). Configuration change control is not complete and a change request not closed until it has been confirmed that the change was deployed without issues. Although the initial security impact analysis and testing may have found no impact from the change, an improperly implemented change can cause its own security issues.

9. Close out the change request. With completion of the above steps, the change request is closed out.

4.3.1 Handling of Scheduled, Unscheduled, and Unauthorized Changes When unscheduled changes must be made and time does not allow for following the established configuration change control process, unscheduled changes are still managed and controlled. {ACRONYM} include instructions for handling unscheduled changes within the CCB Charter. Unscheduled changes are reviewed/resolved by the CCB as soon as is practical after unscheduled changes are made.

During assessment activities, any unauthorized changes found will be immediately reported to the CCB.

In the event of an Incident, assessment activities will begin immediately.

4.3.2 Security Impact Analysis

Security impact analysis is the analysis conducted by qualified {ACRONYM} staff to determine the extent to which changes to {ACRONYM} affect the security posture. Because {ACRONYM} is typically in a constant state of change, it is important to understand the impact of changes on the functionality of existing security controls and in the context of organizational risk tolerance. Security impact analysis is incorporated into the documented configuration change control process.

The analysis of the security impact of a change occurs when changes are analyzed and evaluated for adverse impact on security, preferably before they are approved and implemented, but also in the case of emergency/unscheduled changes. Once the changes are implemented and tested, a security impact analysis (and/or assessment) is performed to ensure that the changes have been implemented as approved, and to determine if there are any unanticipated effects of the change on existing security controls.

Security impact analysis supports the implementation of NIST SP 800-53 control CM-4 Security Impact Analysis.

Figure 5 – Security Impact Analysis

The process for a security impact analysis consists of the following steps:

1. Understand the Change - If the change is being proposed, develop a high-level architecture overview which shows how the change will be implemented. If the change has already occurred (unscheduled/unauthorized), request follow-up documentation/information and review it or use whatever information is available (e.g., audit records, interview staff who made the change, etc.) to gain insight into the change.

2. Identify Vulnerabilities - If the change involves a COTS hardware or software product, identifying vulnerabilities may include, for example, a search of the National Vulnerability Database (NVD) which enumerates vulnerabilities, user experience, etc. {ACRONYM} can leverage this information to address known issues and remove or mitigate them before they become a concern. Other public databases of vulnerabilities, weaknesses, and threats may also be searched (e.g., US-CERT). Some automated vulnerability scanning tools (SCAP-validated tools where possible) are able to search various public vulnerability databases that apply to IT products/CPE names of IT products. If the change involves custom development, a more in-depth analysis of the security impact is conducted. Although application security is beyond the scope of this Plan, there are many best practices and useful sources of information for how to ensure the security of software code.

3. Assess Risks - Once a vulnerability has been identified, a risk assessment is needed to identify the likelihood of a threat exercising the vulnerability and the impact of such an event. Although vulnerabilities may be identified in changes as they are proposed, built, and tested, the assessed risk may be low enough that the risk can be accepted without remediation (i.e., risk acceptance). In other cases, the risk may be high enough that the change is not approved (i.e., risk avoidance), or that safeguards and countermeasures are implemented to reduce the risk (i.e., risk mitigation).

4. Assess Impact on Existing Security Controls - In addition to assessing the risk from the change, {ACRONYM} will analyze whether and how a change will impact existing security controls. For example, the change may involve installation of software that alters the existing baseline configuration, or the change itself may cause or require changes to the existing baseline configuration. The change may also affect other systems or system components that depend on the function or component being changed, either temporarily or permanently. For example, if a database that is used to support auditing controls is being upgraded to the latest version, auditing functionality within the system may be halted while the upgrade is being implemented.

5. Plan Safeguards and Countermeasures - In cases where risks have been identified and are unacceptable, {ACRONYM} will use the security impact analysis to revise the change or to plan safeguards and countermeasures to reduce the risk. For instance, if the security impact analysis reveals that the proposed change causes a modification to a common secure configuration setting, plans to rework the change to function within the existing setting are initiated. If a change involves new elevated privileges for users, plans to mitigate the additional risk are made (e.g., submission of requests for higher clearance levels for those users or implementation of stronger access controls).

4.3.3 Testing

{ACRONYM} fully tests secure configurations prior to implementation in the production environment. There are a number of issues that may be encountered when implementing configurations including software compatibility and hardware device driver issues. For example, there may be legacy applications with special operating requirements that do not function correctly after a common secure configuration has been applied. Additionally, configuration errors could occur if OS and multiple application configurations are applied to the same component. For example, a setting for an application configuration parameter may conflict with a similar setting for an OS configuration parameter. A Change Request must be prepared to the audit trail of testing activity is maintained.

Table 9 – Testing Types

4.3.4 Submission of Findings to CCB

Submission of CCRs are contained in Appendix A, Section 4.

4.3.5 CCB Evaluation and Approval Process

Approval of CCRs are contained in Appendix A, Section 5.

4.3.6 Recording Requirements

Once the change has been analyzed, approved, tested, implemented, and verified, {ACRONYM} ensures that updates have been made to supporting documents such as technical designs and baseline configurations, in addition to security-related documentation such as System Security Plans, Risk Assessments, Security Assessment Reports, and Plans of Action & Milestones. In cases where there is high risk or where significant changes have been made, a system reauthorization may be required.

4.4 SecCM Monitoring

Configuration monitoring involves activities to determine whether {ACRONYM} is configured in accordance with the organization’s agreed-upon baseline configurations, and whether the IS components identified within {ACRONYM} are consistent with the IS component inventory being maintained by the organization.

Configuration monitoring helps to ensure that SecCM controls are operating as intended and are providing effective security while supporting adherence to SecCM policies and procedures. Configuration monitoring may also help to motivate staff members to perform SecCM activities in accordance with policies and procedures. Additionally, configuration monitoring supports organizations in their efforts to conform to the Risk Management Framework.

Information gathered during configuration monitoring can be used to support overall continuous monitoring activities including ongoing assessments of specific security controls and updates to security documentation such as System Security Plans, Security Assessment Reports, and Security Status Reports. Automation capabilities, such as those defined by SCAP, can be used to automate assessment activities.

Configuration monitoring is part of the Monitoring phase of SecCM and supports the implementation of all NIST SP 800-53 controls in the CM Family.

Changes detected as a result of monitoring activities are reconciled with approved changes. Specifically, reconciliation attempts to answer the following:

· Who made the change;

· Whether the change occurred in a scheduled maintenance window;

· Whether the change matches a previously detected and approved change; and

· Whether the change corresponds with an approved change request, help desk ticket, or product release.

4.4.1 Organization Level Tools

{COMMAND} utilizes the following tools to implement and verify system security configuration settings, and examining systems for signs of compromise:

Table 10 – Organizational Level Tools

4.4.2 System Level Tools

{ACRONYM} utilizes the following tools to implement and verify system security configuration settings, and examining systems for signs of compromise:

Table 11 – System Level Tools

4.4.3 Monitoring Requirements and Frequencies

The following types of monitoring activities are performed on a monthly basis:

1. Scanning to discover components not recorded in the inventory.

2. Scanning to identify disparities between the approved baseline configuration and the actual configuration for an information system.

4.5 SecCM Reporting

Reports address the secure state of {ACRONYM} configurations and are used as input to Risk Management Framework information security continuous monitoring requirements. SecCM Reports are the output product of the SecCM Monitoring activity. Reports consist of:

1. Scan results

2. HBSS Reports

3. Incident Reports

4. Any Tool Reports

4.5.1 Report Recipients

All Reports will be made available to the CCB and personnel associated with the administration of {ACRONYM}.

4.5.2 Reviewing Reports

Reports will be reviewed once received to ensure SecCM Monitoring is occurring and to determine if there are additional actions that must be taken from a management perspective.

All software contained within {ACRONYM} must be correctly licensed. {ACRONYM} takes advantage of enterprise licensing where available. Peer-to-Peer file sharing is not authorized, therefore software licenses cannot be violated by its use.

The following table lists the software that requires a license and the related information to its use within {ACRONYM}.

Table 12 – Software Licensing

5.2 Software Installation

The following user types are authorized to install software on {ACRONYM}

Table 13 – Software Installation General Users are not permitted to install software. This is enforced by the base Operating System (OS) STIG settings and user rights, which do not grant the appropriate rights to General Users to install software. Security event logs, which are monitored at least monthly, create and audit trail of monitoring activities to ensure the software installation policy is being enforced.

APPENDIX A – CHANGE CONTROL BOARD CHARTER

A.1 PURPOSE

The purpose of this Change Control Board (CCB) Charter is to establish a sound CCB approach that maintains the integrity of {ACRONYM} as changes are required. Every Information Technology (IT) system is developed and implemented in response to a business need or as a solution to an organizational problem. Applying SecCM and CCB to {ACRONYM} will enhance a system's cost effectiveness and security. Changes to {ACRONYM}, when controlled, are less error-prone and therefore less costly to complete. Early identification of the impact of a modification on other components will result in better-designed changes. The need for formal approval of change requests will lead to better-developed and properly justified changes. The application of rigorous CCB procedures also reduces the risk of malicious changes by making each change to {ACRONYM} visible and ensuring full accountability and audit.

A.2 SCOPE OF AUTHORITY

The CCB effort covers the {ACRONYM} assets, both software and hardware, that are contained within the accreditation boundary. The CCB Charter ensures that any changes are reviewed and approved by the proper management authority for {ACRONYM} in terms of data confidentiality, integrity, and availability, as well as other security implications. Data integrity requires that information and programs are changed only in a specified and authorized manner. System integrity requires that {ACRONYM} perform its intended function in an unimpaired manner, free from deliberate, inadvertent, or unauthorized manipulation. This plan supports configuration management of all security aspects. The scope includes:

· Physical asset products and versions

· Operating system software products and versions

· Application software products and versions

· Boundary configurations

A.3 MEMBERSHIP

Current membership categories are as follows:

· CCB Chairperson

· Cyber Security Representative

· System Owner

· Technical Representatives CCB meetings will be open, by prior arrangement, to additional personnel as appropriate to issues under discussion. Initially, each CCB meeting will be preceded by the submissions of all change control requests (CCRs).

CCB members have a basic responsibility to adequately prepare for, attend, and actively participate in all scheduled meetings. This requires a commitment to perform the assigned duties and functions of the CCB, including reasonable attendance at CCB meetings and emails. Alternates for members will not be permitted unless so designated by the CCB Chairperson. In addition, each member is responsible for:

1. Possessing a thorough understanding of the {ACRONYM}

2. Representing the interests of their membership category

3. Reviewing CCRs

4. Responding to actions

5. Executing assignments in a timely manner CCB Chairperson The CCB Chairperson, or Alternate, has the authority to approve, disapprove, and defer a change proposal. The Chairperson is generally at the level of program manager, deputy program manager, or higher level. The CCB Chairperson should appoint an alternate if he or she is unable to attend the CCB meetings. The alternate will still need to brief the CCB Chairperson. If the CCB Chairperson is unable to go to the ISSM, the alternate will go to the ISSM if the CCR requires ISSM approval.

Cyber Security Representative The Cyber Security Representative participates as a voting member of the Configuration Control Board (CCB) to ensure that configuration changes are properly controlled and documented for {ACRONYM} and that the changes do not harm system security properties. The Cyber Security Representative will ensure that proposed system changes are reviewed, and that changes, enhancements, or modifications implemented do not adversely impact system security features.

System Owner The System Owner has full responsibility of {ACRONYM} to the sponsor and is responsible for meeting all Cyber Security requirements to obtain an Authorization to Operate (ATO) for the System. The System Owner may also be known as the Program Manager or System Manager and may also be the CCB Chairperson.

Technical Representatives The Technical Representatives support the CCB by assessing the change request for cost, schedule, and technical performance, scientific objectives, and risk impact. This group is also responsible for the implementation of approved CCRs and are the only ones allowed to make changes on the system.

A.4 OPERATING PROCEDURES

Any member of the {ACRONYM} community, including users, developers, and staff can recommend changes or report defects. Change control is exercised after establishment of each baseline or version.

CCB Meetings for the {ACRONYM} will occur on an as needed basis, throughout the entire system lifecycle. {ACRONYM} holds quarterly CCB meetings and processes emergency CCRs in an ad-hoc fashion via email to quickly address needed changes. The scheduling of additional meetings will depend upon the frequency of CCRs received and the needs of the {ACRONYM} community.

Change control ensures that all modifications/enhancements follow an orderly process for evaluation and implementation so that traceability and accountability are supported. The CCB must approve any change before it is implemented.

The CCB will perform the following activities:

· Schedule and convene CCB meetings either in person or via email

· Establish meeting agenda items and set meeting priorities

· Ensure completed Change Request Form is present

· Review and consider proposed changes and recommendations of the CCR Submitter

· Review cost effectiveness and feasibility reviews from {ACRONYM} staff

· Approve, disapprove, or defer CCRs

· Prioritize CCRs

· Assign CCRs to a release

· Approve and distribute CCB minutes

A.5 DECISION MAKING PROCESS

Approval of CCRs will be determined based upon a consensus of the board. For any changes negatively impacting the Cyber Security posture of {ACRONYM} that were denied, the CCB Chair cannot overrule the decision unless the ISSM agrees.

CCRs will be classified into two categories:

1. Trivial or low-risk

2. Non-trivial or high-risk Any change to the {ACRONYM} has a risk associated with it due to the nature of modifying system processes. The CCB Chairperson will evaluate whether a request represents a low or high risk to the system. The {ACRONYM} Cyber Security Representative or ISSM will determine overall Security Risk. This risk will be presented to the CCB. Listed below are the guidelines for assessing risk.

A high risk request is one that:

· Changes the logical data flow of the system

· Requires modification of key shared modules

· Changes the security policy in any way

· A major operating system or major firmware release

· Adding or removing servers

A low risk request is one that:

· Application of patches

· Upgrading of an older operating system or firmware release that does not include a major version change

The CCB Chairperson will initially review each CCR for completeness and accuracy. If necessary, additional information about the request may be required. In the case of a necessary but trivial or low-risk change, the CCB Chairperson will approve the request and schedule its implementation, after discussion with the {ACRONYM}, but without review by the CCB. However, all members of the CCB will be notified of the modification.

In the case of a non-trivial or high-risk modification, the CCB will assess the impact of the change in terms of cost, level of effort, and schedule. These requests will be presented to the CCB for approval and prioritization.

The CCB will maintain a history of all change requests for at least one year.

A.6 COMMUNICATING STATUS

{ACRONYM} uses emails as their primary method of documenting meeting minutes. The email documents the CCRs status of either approved, processed as urgent, or deferred. The email also documents the CCRs that are approved but have not been completed.

APPENDIX C – DETAILED COMPLIANCE MATRIX

The following table provides traceability between this document and the Assessment Procedures contained within NIST Special Publication 800-53A Revision 4, "Assessing Security and Privacy Controls in Federal Information Systems and Organizations".

Moderate Low High Moderate Low

The organization being inspected/assessed is automatically compliant with this CCI because they are covered at the DoD level.

DoD has defined the organizational personnel or roles as all stakeholders in the configuration management process.

Automatically compliant with this CCI because they are covered at the DoD level

Moderate Low High Moderate Low

The organization being inspected/assessed is automatically compliant with this CCI because they are covered at the DoD level.

DoD has defined the organizational personnel or roles as all stakeholders in the configuration management process.

Automatically compliant with this CCI because they are covered at the DoD level

Moderate Low High Moderate Low

Section 2.4 Section 3.1 This Document

Moderate Low High Moderate Low

Moderate Low High Moderate Low

Moderate Low High Moderate Low

Moderate Low High Moderate Low

The organization conducting the inspection/assessment obtains and examines documentation of occurrence of reviews and update actions for the configuration management policy to ensure annual review and necessary updates are occurring.

DoD has defined the frequency as annually.

Change Record

Moderate Low High Moderate Low

The organization being inspected/assessed is automatically compliant with this CCI because they are covered at the DoD level.

DoD has defined the frequency as annually.

Automatically compliant with this CCI because they are covered at the DoD level

Moderate Low High Moderate Low

The organization conducting the inspection/assessment obtains and examines documentation of occurrence of reviews and update actions for the procedures to facilitate the implementation of the configuration management policy and associated configuration management controls to ensure annual review and necessary updates are occurring.

DoD has defined the frequency as annually.

Change Record

Moderate Low High Moderate Low

The organization being inspected/assessed is automatically compliant with this CCI because they are covered at the DoD level.

DoD has defined the frequency as annually.

Automatically compliant with this CCI because they are covered at the DoD level

High Moderate Low

The organization being inspected/assessed is automatically compliant with this CCI because they are covered at the DoD level.

DoD has defined the restrictions as IAW DoD Memorandum "Clarifying Guidance Regarding Open Source Software (OSS)" 16 Oct 2009 (http://dodcio.defense.gov/Home/Issuances/DoDCIOMemorandums.aspx).

Automatically compliant with this CCI because they are covered at the DoD level

High Moderate Low

DoD Memorandum "Clarifying Guidance Regarding Open Source Software (OSS)" 16 Oct 2009 (http://dodcio.defense.gov/Home/Issuances/DoDCIOMemorandums.aspx) meets the DoD requirement for establishing restrictions on the use of open source software.

DoD Components are automatically compliant with this control because they are covered by the DoD level policy, DoD Memorandum "Clarifying Guidance Regarding Open Source Software (OSS)."

Automatically compliant with this CCI because they are covered at the DoD level

High Moderate Low

High Moderate Low

High Moderate Low

High Moderate Low