compliance controls are associated with this Policy definition 'Establish configuration management requirements for developers' (8747b573-8294-86a0-8914-49e9b06a5ace)
| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
| FedRAMP_High_R4 |
CM-3 |
FedRAMP_High_R4_CM-3 |
FedRAMP High CM-3 |
Configuration Management |
Configuration Change Control |
Shared |
n/a |
The organization:
a. Determines the types of changes to the information system that are configuration-controlled;
b. Reviews proposed configuration-controlled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses;
c. Documents configuration change decisions associated with the information system;
d. Implements approved configuration-controlled changes to the information system;
e. Retains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period];
f. Audits and reviews activities associated with configuration-controlled changes to the information system; and
g. Coordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]].
Supplemental Guidance: Configuration change controls for organizational information systems involve the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of information systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled/unauthorized changes, and changes to remediate vulnerabilities. Typical processes for managing configuration changes to information systems include, for example, Configuration Control Boards that approve proposed changes to systems. For new development information systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards. Auditing of changes includes activities before and after changes are made to organizational information systems and the auditing activities required to implement such changes. Related controls: CM-2, CM-4, CM-5, CM-6, CM-9, SA-10, SI-2, SI-12.
References: NIST Special Publication 800-128. |
link |
8 |
| FedRAMP_High_R4 |
CM-3(2) |
FedRAMP_High_R4_CM-3(2) |
FedRAMP High CM-3 (2) |
Configuration Management |
Test / Validate / Document Changes |
Shared |
n/a |
The organization tests, validates, and documents changes to the information system before implementing the changes on the operational system.
Supplemental Guidance: Changes to information systems include modifications to hardware, software, or firmware components and configuration settings defined in CM-6. Organizations ensure that testing does not interfere with information system operations. Individuals/groups conducting tests understand organizational security policies and procedures, information system security policies and procedures, and the specific health, safety, and environmental risks associated with particular facilities/processes. Operational systems may need to be taken off-line, or replicated to the extent feasible, before testing can be conducted. If information systems must be taken off-line for testing, the tests are scheduled to occur during planned system outages whenever possible. If testing cannot be conducted on operational systems, organizations employ compensating controls (e.g., testing on replicated systems). |
link |
3 |
| FedRAMP_High_R4 |
CM-4 |
FedRAMP_High_R4_CM-4 |
FedRAMP High CM-4 |
Configuration Management |
Security Impact Analysis |
Shared |
n/a |
The organization analyzes changes to the information system to determine potential security impacts prior to change implementation.
Supplemental Guidance: Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) conduct security impact analyses. Individuals conducting security impact analyses possess the necessary skills/technical expertise to analyze the changes to information systems and the associated security ramifications. Security impact analysis may include, for example, reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security impact analyses may also include assessments of risk to better understand the impact of the changes and to determine if additional security controls are required. Security impact analyses are scaled in accordance with the security categories of the information systems. Related controls: CA-2, CA-7, CM-3, CM-9, SA-4, SA-5, SA-10, SI-2.
References: NIST Special Publication 800-128. |
link |
8 |
| FedRAMP_High_R4 |
CM-4(1) |
FedRAMP_High_R4_CM-4(1) |
FedRAMP High CM-4 (1) |
Configuration Management |
Separate Test Environments |
Shared |
n/a |
The organization analyzes changes to the information system in a separate test environment before implementation in an operational environment, looking for security impacts due to flaws, weaknesses, incompatibility, or intentional malice.
Supplemental Guidance: Separate test environment in this context means an environment that is physically or logically isolated and distinct from the operational environment. The separation is sufficient to ensure that activities in the test environment do not impact activities in the operational environment, and information in the operational environment is not inadvertently transmitted to the test environment. Separate environments can be achieved by physical or logical means. If physically separate test environments are not used, organizations determine the strength of mechanism required when implementing logical separation (e.g., separation achieved through virtual machines). Related controls: SA-11, SC-3, SC-7. |
link |
5 |
| FedRAMP_Moderate_R4 |
CM-3 |
FedRAMP_Moderate_R4_CM-3 |
FedRAMP Moderate CM-3 |
Configuration Management |
Configuration Change Control |
Shared |
n/a |
The organization:
a. Determines the types of changes to the information system that are configuration-controlled;
b. Reviews proposed configuration-controlled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses;
c. Documents configuration change decisions associated with the information system;
d. Implements approved configuration-controlled changes to the information system;
e. Retains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period];
f. Audits and reviews activities associated with configuration-controlled changes to the information system; and
g. Coordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]].
Supplemental Guidance: Configuration change controls for organizational information systems involve the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of information systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled/unauthorized changes, and changes to remediate vulnerabilities. Typical processes for managing configuration changes to information systems include, for example, Configuration Control Boards that approve proposed changes to systems. For new development information systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards. Auditing of changes includes activities before and after changes are made to organizational information systems and the auditing activities required to implement such changes. Related controls: CM-2, CM-4, CM-5, CM-6, CM-9, SA-10, SI-2, SI-12.
References: NIST Special Publication 800-128. |
link |
8 |
| FedRAMP_Moderate_R4 |
CM-4 |
FedRAMP_Moderate_R4_CM-4 |
FedRAMP Moderate CM-4 |
Configuration Management |
Security Impact Analysis |
Shared |
n/a |
The organization analyzes changes to the information system to determine potential security impacts prior to change implementation.
Supplemental Guidance: Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) conduct security impact analyses. Individuals conducting security impact analyses possess the necessary skills/technical expertise to analyze the changes to information systems and the associated security ramifications. Security impact analysis may include, for example, reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security impact analyses may also include assessments of risk to better understand the impact of the changes and to determine if additional security controls are required. Security impact analyses are scaled in accordance with the security categories of the information systems. Related controls: CA-2, CA-7, CM-3, CM-9, SA-4, SA-5, SA-10, SI-2.
References: NIST Special Publication 800-128. |
link |
8 |
| hipaa |
0228.09k2Organizational.3-09.k |
hipaa-0228.09k2Organizational.3-09.k |
0228.09k2Organizational.3-09.k |
02 Endpoint Protection |
0228.09k2Organizational.3-09.k 09.04 Protection Against Malicious and Mobile Code |
Shared |
n/a |
Rules for the migration of software from development to operational status are defined and documented by the organization hosting the affected application(s), including that development, test, and operational systems are separated (physically or virtually) to reduce the risks of unauthorized access or changes to the operational system. |
|
11 |
| hipaa |
0602.06g1Organizational.3-06.g |
hipaa-0602.06g1Organizational.3-06.g |
0602.06g1Organizational.3-06.g |
06 Configuration Management |
0602.06g1Organizational.3-06.g 06.02 Compliance with Security Policies and Standards, and Technical Compliance |
Shared |
n/a |
The results and recommendations of the reviews are documented and approved by management. |
|
10 |
| hipaa |
0618.09b1System.1-09.b |
hipaa-0618.09b1System.1-09.b |
0618.09b1System.1-09.b |
06 Configuration Management |
0618.09b1System.1-09.b 09.01 Documented Operating Procedures |
Shared |
n/a |
Changes to information assets, including systems, networks, and network services, are controlled and archived. |
|
16 |
| hipaa |
0638.10k2Organizational.34569-10.k |
hipaa-0638.10k2Organizational.34569-10.k |
0638.10k2Organizational.34569-10.k |
06 Configuration Management |
0638.10k2Organizational.34569-10.k 10.05 Security In Development and Support Processes |
Shared |
n/a |
Changes are formally controlled, documented, and enforced in order to minimize the corruption of information systems. |
|
14 |
| hipaa |
0640.10k2Organizational.1012-10.k |
hipaa-0640.10k2Organizational.1012-10.k |
0640.10k2Organizational.1012-10.k |
06 Configuration Management |
0640.10k2Organizational.1012-10.k 10.05 Security In Development and Support Processes |
Shared |
n/a |
Where development is outsourced, change control procedures to address security are included in the contract(s) and specifically require the developer to track security flaws and flaw resolution within the system, component, or service and report findings to organization-defined personnel or roles. |
|
22 |
| hipaa |
0641.10k2Organizational.11-10.k |
hipaa-0641.10k2Organizational.11-10.k |
0641.10k2Organizational.11-10.k |
06 Configuration Management |
0641.10k2Organizational.11-10.k 10.05 Security In Development and Support Processes |
Shared |
n/a |
The organization does not use automated updates on critical systems. |
|
13 |
| hipaa |
0643.10k3Organizational.3-10.k |
hipaa-0643.10k3Organizational.3-10.k |
0643.10k3Organizational.3-10.k |
06 Configuration Management |
0643.10k3Organizational.3-10.k 10.05 Security In Development and Support Processes |
Shared |
n/a |
The organization (i) establishes and documents mandatory configuration settings for information technology products employed within the information system using the latest security configuration baselines; (ii) identifies, documents, and approves exceptions from the mandatory established configuration settings for individual components based on explicit operational requirements; and, (iii) monitors and controls changes to the configuration settings in accordance with organizational policies and procedures. |
|
17 |
| hipaa |
0669.10hCSPSystem.1-10.h |
hipaa-0669.10hCSPSystem.1-10.h |
0669.10hCSPSystem.1-10.h |
06 Configuration Management |
0669.10hCSPSystem.1-10.h 10.04 Security of System Files |
Shared |
n/a |
Open and published APIs are used by cloud service providers to ensure support for interoperability between components and to facilitate migrating applications. |
|
16 |
| hipaa |
0671.10k1System.1-10.k |
hipaa-0671.10k1System.1-10.k |
0671.10k1System.1-10.k |
06 Configuration Management |
0671.10k1System.1-10.k 10.05 Security In Development and Support Processes |
Shared |
n/a |
The organization manages changes to mobile device operating systems, patch levels, and/or applications through a formal change management process. |
|
16 |
| hipaa |
0672.10k3System.5-10.k |
hipaa-0672.10k3System.5-10.k |
0672.10k3System.5-10.k |
06 Configuration Management |
0672.10k3System.5-10.k 10.05 Security In Development and Support Processes |
Shared |
n/a |
The integrity of all virtual machine images is ensured at all times by (i) logging and raising an alert for any changes made to virtual machine images, and (ii) making available to the business owner(s) and/or customer(s) through electronic methods (e.g., portals or alerts) the results of a change or move and the subsequent validation of the image's integrity. |
|
12 |
| hipaa |
0821.09m2Organizational.2-09.m |
hipaa-0821.09m2Organizational.2-09.m |
0821.09m2Organizational.2-09.m |
08 Network Protection |
0821.09m2Organizational.2-09.m 09.06 Network Security Management |
Shared |
n/a |
The organization tests and approves all network connections and firewall, router, and switch configuration changes prior to implementation. Any deviations from the standard configuration or updates to the standard configuration are documented and approved in a change control system. All new configuration rules beyond a baseline-hardened configuration that allow traffic to flow through network security devices, such as firewalls and network-based IPS, are also documented and recorded, with a specific business reason for each change, a specific individual’s name responsible for that business need, and an expected duration of the need. |
|
18 |
| hipaa |
0863.09m2Organizational.910-09.m |
hipaa-0863.09m2Organizational.910-09.m |
0863.09m2Organizational.910-09.m |
08 Network Protection |
0863.09m2Organizational.910-09.m 09.06 Network Security Management |
Shared |
n/a |
The organization builds a firewall configuration that restricts connections between untrusted networks and any system components in the covered information environment; and any changes to the firewall configuration are updated in the network diagram. |
|
25 |
| hipaa |
1208.09aa3System.1-09.aa |
hipaa-1208.09aa3System.1-09.aa |
1208.09aa3System.1-09.aa |
12 Audit Logging & Monitoring |
1208.09aa3System.1-09.aa 09.10 Monitoring |
Shared |
n/a |
Audit logs are maintained for management activities, system and application startup/shutdown/errors, file changes, and security policy changes. |
|
18 |
| hipaa |
1211.09aa3System.4-09.aa |
hipaa-1211.09aa3System.4-09.aa |
1211.09aa3System.4-09.aa |
12 Audit Logging & Monitoring |
1211.09aa3System.4-09.aa 09.10 Monitoring |
Shared |
n/a |
The organization verifies every 90 days for each extract of covered information recorded that the data is erased or its use is still required. |
|
9 |
| hipaa |
1734.03d2Organizational.1-03.d |
hipaa-1734.03d2Organizational.1-03.d |
1734.03d2Organizational.1-03.d |
17 Risk Management |
1734.03d2Organizational.1-03.d 03.01 Risk Management Program |
Shared |
n/a |
The risk management process is integrated with the change management process within the organization. |
|
8 |
| hipaa |
1735.03d2Organizational.23-03.d |
hipaa-1735.03d2Organizational.23-03.d |
1735.03d2Organizational.23-03.d |
17 Risk Management |
1735.03d2Organizational.23-03.d 03.01 Risk Management Program |
Shared |
n/a |
Risk assessments are conducted whenever there is a significant change in the environment, or a change that could have a significant impact, and the results of the assessments are included in the change management process, so they may guide the decisions within the change management process (e.g., approvals for changes). |
|
8 |
| ISO27001-2013 |
A.12.1.2 |
ISO27001-2013_A.12.1.2 |
ISO 27001:2013 A.12.1.2 |
Operations Security |
Change management |
Shared |
n/a |
Changes to organization, business processes, information processing facilities and systems that affect information security shall be controlled. |
link |
27 |
| ISO27001-2013 |
A.12.1.4 |
ISO27001-2013_A.12.1.4 |
ISO 27001:2013 A.12.1.4 |
Operations Security |
Separation of development, testing and operational environments |
Shared |
n/a |
Development, testing, and operational environments shall be separated to reduce the risks of unauthorized access or changes to the operational environment. |
link |
10 |
| ISO27001-2013 |
A.12.5.1 |
ISO27001-2013_A.12.5.1 |
ISO 27001:2013 A.12.5.1 |
Operations Security |
Installation of software on operational systems |
Shared |
n/a |
Procedures shall be implemented to control the installation of software on operational systems. |
link |
19 |
| ISO27001-2013 |
A.12.6.2 |
ISO27001-2013_A.12.6.2 |
ISO 27001:2013 A.12.6.2 |
Operations Security |
Restrictions on software installation |
Shared |
n/a |
Rules governing the installation of software by users shall be established and implemented. |
link |
19 |
| ISO27001-2013 |
A.14.2.2 |
ISO27001-2013_A.14.2.2 |
ISO 27001:2013 A.14.2.2 |
System Acquisition, Development And Maintenance |
System change control procedures |
Shared |
n/a |
Changes to systems within the development lifecycle shall be controlled by the use of formal change control procedures. |
link |
25 |
| ISO27001-2013 |
A.14.2.3 |
ISO27001-2013_A.14.2.3 |
ISO 27001:2013 A.14.2.3 |
System Acquisition, Development And Maintenance |
Technical review of applications after operating platform changes |
Shared |
n/a |
When operating platforms are changed, business critical applications shall be reviewed and tested to ensure there is no adverse impact on organizational operations or security. |
link |
18 |
| ISO27001-2013 |
A.14.2.4 |
ISO27001-2013_A.14.2.4 |
ISO 27001:2013 A.14.2.4 |
System Acquisition, Development And Maintenance |
Restrictions on changes to software packages |
Shared |
n/a |
Modifications to software packages shall be discouraged, limited to necessary changes and all changes shall be strictly controlled. |
link |
24 |
| ISO27001-2013 |
A.14.2.6 |
ISO27001-2013_A.14.2.6 |
ISO 27001:2013 A.14.2.6 |
System Acquisition, Development And Maintenance |
Secure development environment |
Shared |
n/a |
Organizations shall establish and appropriately protect secure development environments for system development and integration efforts that cover the entire system development lifecycle. |
link |
10 |
| ISO27001-2013 |
A.14.2.7 |
ISO27001-2013_A.14.2.7 |
ISO 27001:2013 A.14.2.7 |
System Acquisition, Development And Maintenance |
Outsourced development |
Shared |
n/a |
The organization shall supervise and monitor the activity of outsourced system development. |
link |
28 |
| ISO27001-2013 |
A.14.3.1 |
ISO27001-2013_A.14.3.1 |
ISO 27001:2013 A.14.3.1 |
System Acquisition, Development And Maintenance |
Protection of test data |
Shared |
n/a |
Test data shall be selected carefully, protected and controlled. |
link |
11 |
| ISO27001-2013 |
A.8.2.3 |
ISO27001-2013_A.8.2.3 |
ISO 27001:2013 A.8.2.3 |
Asset Management |
Handling of assets |
Shared |
n/a |
Procedures for handling assets shall be developed and implemented in accordance with the information classification scheme adopted by the organization. |
link |
26 |
| ISO27001-2013 |
C.10.1.f |
ISO27001-2013_C.10.1.f |
ISO 27001:2013 C.10.1.f |
Improvement |
Nonconformity and corrective action |
Shared |
n/a |
Corrective actions shall be appropriate to the effects of the nonconformities encountered.
The organization shall retain documented information as evidence of:
f) the nature of the nonconformities and any subsequent actions taken. |
link |
3 |
| ISO27001-2013 |
C.10.1.g |
ISO27001-2013_C.10.1.g |
ISO 27001:2013 C.10.1.g |
Improvement |
Nonconformity and corrective action |
Shared |
n/a |
Corrective actions shall be appropriate to the effects of the nonconformities encountered.
The organization shall retain documented information as evidence of:
g) the results of any corrective action. |
link |
3 |
| ISO27001-2013 |
C.5.1.b |
ISO27001-2013_C.5.1.b |
ISO 27001:2013 C.5.1.b |
Leadership |
Leadership and commitment |
Shared |
n/a |
Top management shall demonstrate leadership and commitment with respect to the information
security management system by:
b) ensuring the integration of the information security management system requirements into the
organization’s processes. |
link |
28 |
| ISO27001-2013 |
C.7.5.3.f |
ISO27001-2013_C.7.5.3.f |
ISO 27001:2013 C.7.5.3.f |
Support |
Control of documented information |
Shared |
n/a |
For the control of documented information, the organization shall address the following activities,
as applicable:
f) retention and disposition.
Documented information of external origin, determined by the organization to be necessary for
the planning and operation of the information security management system, shall be identified as
appropriate, and controlled.
NOTE Access implies a decision regarding the permission to view the documented information only, or the
permission and authority to view and change the documented information, etc. |
link |
7 |
| ISO27001-2013 |
C.8.1 |
ISO27001-2013_C.8.1 |
ISO 27001:2013 C.8.1 |
Operation |
Operational planning and control |
Shared |
n/a |
The organization shall plan, implement and control the processes needed to meet information security
requirements, and to implement the actions determined in 6.1. The organization shall also implement
plans to achieve information security objectives determined in 6.2.
The organization shall keep documented information to the extent necessary to have confidence that
the processes have been carried out as planned.
The organization shall control planned changes and review the consequences of unintended changes,
taking action to mitigate any adverse effects, as necessary.
The organization shall ensure that outsourced processes are determined and controlled. |
link |
21 |
|
mp.eq.2 User session lockout |
mp.eq.2 User session lockout |
404 not found |
|
|
|
n/a |
n/a |
|
29 |
|
mp.sw.1 IT Aplications development |
mp.sw.1 IT Aplications development |
404 not found |
|
|
|
n/a |
n/a |
|
51 |
|
mp.sw.2 Acceptance and commissioning |
mp.sw.2 Acceptance and commissioning |
404 not found |
|
|
|
n/a |
n/a |
|
60 |
| NIST_SP_800-171_R2_3 |
.4.3 |
NIST_SP_800-171_R2_3.4.3 |
NIST SP 800-171 R2 3.4.3 |
Configuration Management |
Track, review, approve or disapprove, and log changes to organizational systems. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Tracking, reviewing, approving/disapproving, and logging changes is called configuration change control. Configuration change control for organizational systems involves the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled and unauthorized changes, and changes to remediate vulnerabilities. Processes for managing configuration changes to systems include Configuration Control Boards or Change Advisory Boards that review and approve proposed changes to systems. For new development systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards or Change Advisory Boards. Audit logs of changes include activities before and after changes are made to organizational systems and the activities required to implement such changes. [SP 800-128] provides guidance on configuration change control. |
link |
15 |
| NIST_SP_800-171_R2_3 |
.4.4 |
NIST_SP_800-171_R2_3.4.4 |
NIST SP 800-171 R2 3.4.4 |
Configuration Management |
Analyze the security impact of changes prior to implementation. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Organizational personnel with information security responsibilities (e.g., system administrators, system security officers, system security managers, and systems security engineers) conduct security impact analyses. Individuals conducting security impact analyses possess the necessary skills and technical expertise to analyze the changes to systems and the associated security ramifications. Security impact analysis may include reviewing security plans to understand security requirements and reviewing system design documentation to understand the implementation of controls and how specific changes might affect the controls. Security impact analyses may also include risk assessments to better understand the impact of the changes and to determine if additional controls are required. [SP 800-128] provides guidance on configuration change control and security impact analysis. |
link |
8 |
| NIST_SP_800-53_R4 |
CM-3 |
NIST_SP_800-53_R4_CM-3 |
NIST SP 800-53 Rev. 4 CM-3 |
Configuration Management |
Configuration Change Control |
Shared |
n/a |
The organization:
a. Determines the types of changes to the information system that are configuration-controlled;
b. Reviews proposed configuration-controlled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses;
c. Documents configuration change decisions associated with the information system;
d. Implements approved configuration-controlled changes to the information system;
e. Retains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period];
f. Audits and reviews activities associated with configuration-controlled changes to the information system; and
g. Coordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]].
Supplemental Guidance: Configuration change controls for organizational information systems involve the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of information systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled/unauthorized changes, and changes to remediate vulnerabilities. Typical processes for managing configuration changes to information systems include, for example, Configuration Control Boards that approve proposed changes to systems. For new development information systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards. Auditing of changes includes activities before and after changes are made to organizational information systems and the auditing activities required to implement such changes. Related controls: CM-2, CM-4, CM-5, CM-6, CM-9, SA-10, SI-2, SI-12.
References: NIST Special Publication 800-128. |
link |
8 |
| NIST_SP_800-53_R4 |
CM-3(2) |
NIST_SP_800-53_R4_CM-3(2) |
NIST SP 800-53 Rev. 4 CM-3 (2) |
Configuration Management |
Test / Validate / Document Changes |
Shared |
n/a |
The organization tests, validates, and documents changes to the information system before implementing the changes on the operational system.
Supplemental Guidance: Changes to information systems include modifications to hardware, software, or firmware components and configuration settings defined in CM-6. Organizations ensure that testing does not interfere with information system operations. Individuals/groups conducting tests understand organizational security policies and procedures, information system security policies and procedures, and the specific health, safety, and environmental risks associated with particular facilities/processes. Operational systems may need to be taken off-line, or replicated to the extent feasible, before testing can be conducted. If information systems must be taken off-line for testing, the tests are scheduled to occur during planned system outages whenever possible. If testing cannot be conducted on operational systems, organizations employ compensating controls (e.g., testing on replicated systems). |
link |
3 |
| NIST_SP_800-53_R4 |
CM-4 |
NIST_SP_800-53_R4_CM-4 |
NIST SP 800-53 Rev. 4 CM-4 |
Configuration Management |
Security Impact Analysis |
Shared |
n/a |
The organization analyzes changes to the information system to determine potential security impacts prior to change implementation.
Supplemental Guidance: Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) conduct security impact analyses. Individuals conducting security impact analyses possess the necessary skills/technical expertise to analyze the changes to information systems and the associated security ramifications. Security impact analysis may include, for example, reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security impact analyses may also include assessments of risk to better understand the impact of the changes and to determine if additional security controls are required. Security impact analyses are scaled in accordance with the security categories of the information systems. Related controls: CA-2, CA-7, CM-3, CM-9, SA-4, SA-5, SA-10, SI-2.
References: NIST Special Publication 800-128. |
link |
8 |
| NIST_SP_800-53_R4 |
CM-4(1) |
NIST_SP_800-53_R4_CM-4(1) |
NIST SP 800-53 Rev. 4 CM-4 (1) |
Configuration Management |
Separate Test Environments |
Shared |
n/a |
The organization analyzes changes to the information system in a separate test environment before implementation in an operational environment, looking for security impacts due to flaws, weaknesses, incompatibility, or intentional malice.
Supplemental Guidance: Separate test environment in this context means an environment that is physically or logically isolated and distinct from the operational environment. The separation is sufficient to ensure that activities in the test environment do not impact activities in the operational environment, and information in the operational environment is not inadvertently transmitted to the test environment. Separate environments can be achieved by physical or logical means. If physically separate test environments are not used, organizations determine the strength of mechanism required when implementing logical separation (e.g., separation achieved through virtual machines). Related controls: SA-11, SC-3, SC-7. |
link |
5 |
| NIST_SP_800-53_R5 |
CM-3 |
NIST_SP_800-53_R5_CM-3 |
NIST SP 800-53 Rev. 5 CM-3 |
Configuration Management |
Configuration Change Control |
Shared |
n/a |
a. Determine and document the types of changes to the system that are configuration-controlled;
b. Review proposed configuration-controlled changes to the system and approve or disapprove such changes with explicit consideration for security and privacy impact analyses;
c. Document configuration change decisions associated with the system;
d. Implement approved configuration-controlled changes to the system;
e. Retain records of configuration-controlled changes to the system for [Assignment: organization-defined time period];
f. Monitor and review activities associated with configuration-controlled changes to the system; and
g. Coordinate and provide oversight for configuration change control activities through [Assignment: organization-defined configuration change control element] that convenes [Selection (OneOrMore): [Assignment: organization-defined frequency] ;when [Assignment: organization-defined configuration change conditions] ] . |
link |
8 |
| NIST_SP_800-53_R5 |
CM-3(2) |
NIST_SP_800-53_R5_CM-3(2) |
NIST SP 800-53 Rev. 5 CM-3 (2) |
Configuration Management |
Testing, Validation, and Documentation of Changes |
Shared |
n/a |
Test, validate, and document changes to the system before finalizing the implementation of the changes. |
link |
3 |
| NIST_SP_800-53_R5 |
CM-4 |
NIST_SP_800-53_R5_CM-4 |
NIST SP 800-53 Rev. 5 CM-4 |
Configuration Management |
Impact Analyses |
Shared |
n/a |
Analyze changes to the system to determine potential security and privacy impacts prior to change implementation. |
link |
8 |
| NIST_SP_800-53_R5 |
CM-4(1) |
NIST_SP_800-53_R5_CM-4(1) |
NIST SP 800-53 Rev. 5 CM-4 (1) |
Configuration Management |
Separate Test Environments |
Shared |
n/a |
Analyze changes to the system in a separate test environment before implementation in an operational environment, looking for security and privacy impacts due to flaws, weaknesses, incompatibility, or intentional malice. |
link |
5 |
|
op.exp.2 Security configuration |
op.exp.2 Security configuration |
404 not found |
|
|
|
n/a |
n/a |
|
112 |
|
op.exp.3 Security configuration management |
op.exp.3 Security configuration management |
404 not found |
|
|
|
n/a |
n/a |
|
123 |
|
op.exp.4 Security maintenance and updates |
op.exp.4 Security maintenance and updates |
404 not found |
|
|
|
n/a |
n/a |
|
78 |
|
op.exp.5 Change management |
op.exp.5 Change management |
404 not found |
|
|
|
n/a |
n/a |
|
71 |
|
op.mon.3 Monitoring |
op.mon.3 Monitoring |
404 not found |
|
|
|
n/a |
n/a |
|
51 |
|
org.4 Authorization process |
org.4 Authorization process |
404 not found |
|
|
|
n/a |
n/a |
|
127 |
| PCI_DSS_v4.0 |
1.2.2 |
PCI_DSS_v4.0_1.2.2 |
PCI DSS v4.0 1.2.2 |
Requirement 01: Install and Maintain Network Security Controls |
Network security controls (NSCs) are configured and maintained |
Shared |
n/a |
All changes to network connections and to configurations of NSCs are approved and managed in accordance with the change control process defined at Requirement 6.5.1. |
link |
8 |
| PCI_DSS_v4.0 |
5.3.5 |
PCI_DSS_v4.0_5.3.5 |
PCI DSS v4.0 5.3.5 |
Requirement 05: Protect All Systems and Networks from Malicious Software |
Anti-malware mechanisms and processes are active, maintained, and monitored |
Shared |
n/a |
Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented, and authorized by management on a case-by-case basis for a limited time period. |
link |
8 |
| PCI_DSS_v4.0 |
6.5.1 |
PCI_DSS_v4.0_6.5.1 |
PCI DSS v4.0 6.5.1 |
Requirement 06: Develop and Maintain Secure Systems and Software |
Changes to all system components are managed securely |
Shared |
n/a |
Changes to all system components in the production environment are made according to established procedures that include:
• Reason for, and description of, the change.
• Documentation of security impact.
• Documented change approval by authorized parties.
• Testing to verify that the change does not adversely impact system security.
• For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production.
• Procedures to address failures and return to a secure state. |
link |
8 |
| PCI_DSS_v4.0 |
6.5.3 |
PCI_DSS_v4.0_6.5.3 |
PCI DSS v4.0 6.5.3 |
Requirement 06: Develop and Maintain Secure Systems and Software |
Changes to all system components are managed securely |
Shared |
n/a |
Pre-production environments are separated from production environments and the separation is enforced with access controls. |
link |
6 |
| PCI_DSS_v4.0 |
6.5.4 |
PCI_DSS_v4.0_6.5.4 |
PCI DSS v4.0 6.5.4 |
Requirement 06: Develop and Maintain Secure Systems and Software |
Changes to all system components are managed securely |
Shared |
n/a |
Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed. |
link |
6 |
| PCI_DSS_v4.0 |
6.5.6 |
PCI_DSS_v4.0_6.5.6 |
PCI DSS v4.0 6.5.6 |
Requirement 06: Develop and Maintain Secure Systems and Software |
Changes to all system components are managed securely |
Shared |
n/a |
Test data and test accounts are removed from system components before the system goes into production. |
link |
5 |
| SOC_2 |
CC8.1 |
SOC_2_CC8.1 |
SOC 2 Type 2 CC8.1 |
Change Management |
Changes to infrastructure, data, and software |
Shared |
The customer is responsible for implementing this recommendation. |
Manages Changes Throughout the System Life Cycle — A process for managing
system changes throughout the life cycle of the system and its components (infrastructure, data, software, and procedures) is used to support system availability and
processing integrity.
• Authorizes Changes — A process is in place to authorize system changes prior to
development.
• Designs and Develops Changes — A process is in place to design and develop system changes.
• Documents Changes — A process is in place to document system changes to support ongoing maintenance of the system and to support system users in performing
their responsibilities.
• Tracks System Changes — A process is in place to track system changes prior to
implementation.
• Configures Software — A process is in place to select and implement the configuration parameters used to control the functionality of software.
• Tests System Changes — A process is in place to test system changes prior to implementation.
• Approves System Changes — A process is in place to approve system changes prior
to implementation.
• Deploys System Changes — A process is in place to implement system changes.
• Identifies and Evaluates System Changes — Objectives affected by system changes
are identified and the ability of the modified system to meet the objectives is evaluated throughout the system development life cycle.
• Identifies Changes in Infrastructure, Data, Software, and Procedures Required to
Remediate Incidents — Changes in infrastructure, data, software, and procedures
required to remediate incidents to continue to meet objectives are identified and the
change process is initiated upon identification.
• Creates Baseline Configuration of IT Technology — A baseline configuration of IT
and control systems is created and maintained.
• Provides for Changes Necessary in Emergency Situations — A process is in place
for authorizing, designing, testing, approving, and implementing changes necessary
in emergency situations (that is, changes that need to be implemented in an urgent
time frame).
Additional points of focus that apply only in an engagement using the trust services criteria for
confidentiality:
• Protects Confidential Information — The entity protects confidential information
during system design, development, testing, implementation, and change processes
to meet the entity’s objectives related to confidentiality.
Additional points of focus that apply only in an engagement using the trust services criteria for
privacy:
• Protects Personal Information — The entity protects personal information during
system design, development, testing, implementation, and change processes to meet
the entity’s objectives related to privacy. |
|
52 |
| SWIFT_CSCF_v2022 |
11.4 |
SWIFT_CSCF_v2022_11.4 |
SWIFT CSCF v2022 11.4 |
11. Monitor in case of Major Disaster |
Ensure an adequate escalation of operational malfunctions in case of customer impact. |
Shared |
n/a |
Ensure an adequate escalation of operational malfunctions in case of customer impact. |
link |
14 |
| SWIFT_CSCF_v2022 |
2.3 |
SWIFT_CSCF_v2022_2.3 |
SWIFT CSCF v2022 2.3 |
2. Reduce Attack Surface and Vulnerabilities |
Reduce the cyber-attack surface of SWIFT-related components by performing system hardening. |
Shared |
n/a |
Security hardening is conducted and maintained on all in-scope components. |
link |
25 |