last sync: 2024-Dec-06 18:53:17 UTC

Establish and document change control processes | Regulatory Compliance - Documentation

Azure BuiltIn Policy definition

Source Azure Portal
Display name Establish and document change control processes
Id bd4dc286-2f30-5b95-777c-681f3a7913d3
Version 1.1.0
Details on versioning
Versioning Versions supported for Versioning: 1
1.1.0
Built-in Versioning [Preview]
Category Regulatory Compliance
Microsoft Learn
Description CMA_0265 - Establish and document change control processes
Additional metadata Name/Id: CMA_0265 / CMA_0265
Category: Documentation
Title: Establish and document change control processes
Ownership: Customer
Description: Microsoft recommends that your organization create and distribute security policies and operational procedures for developing and maintaining secure systems and applications that include details on change control processes. It is recommended that your organization define, document, approve, and enforce physical and logical access restrictions associated with changes to the information systems. You organization is also encouraged to conduct periodic testing on change control processes. We recommend that your organization document the following for each change: - Original request for the proposed change - Impact - Change approval by authorized parties - Functionality testing to verify that the change does not adversely impact the security of the system - Classification of the change based on priority, nature, and complexity - Change implementation details - Back-out procedures - Change request closure. Microsoft recommends that your organization identify change risk categories and determine approval requirements in accordance with the change management process. It is recommended that your organization establish and document the change authority matrix to identify appropriate escalation levels and approvals for changes. Your organization may consider documenting change authorizations or change permits in a risk management file for traceability. It is recommended that your organization document pre-approved changes such as changes that do not require approval from senior management and update related documents periodically based on any changes. Revisions to the Principles for the Sound Management of Operational Risk requires banks to have policies and procedures defining the process for identifying, managing, challenging, approving and monitoring change on the basis of agreed objective criteria. Change management policies and procedures should be subject to independent and regular review and update, and clearly allocate roles and responsibilities in accordance with operational risk and control assessments of new products and initiatives, implementation of appropriate controls or remediation actions. The guidelines requires the change management to assess the evolution of associated risks over the product's lifecycle. Learn more: Microsoft recommends that your organization create and distribute security policies and operational procedures for developing and maintaining secure systems and applications that include details on change control processes. https://docs.microsoft.com/azure/azure-monitor/app/change-analysis
Requirements: The customer is responsible for implementing this recommendation.
Mode All
Type BuiltIn
Preview False
Deprecated False
Effect Default
Manual
Allowed
Manual, Disabled
RBAC role(s) none
Rule aliases none
Rule resource types IF (1)
Microsoft.Resources/subscriptions
Compliance
The following 104 compliance controls are associated with this Policy definition 'Establish and document change control processes' (bd4dc286-2f30-5b95-777c-681f3a7913d3)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
CIS_Azure_1.1.0 1.15 CIS_Azure_1.1.0_1.15 CIS Microsoft Azure Foundations Benchmark recommendation 1.15 1 Identity and Access Management Ensure that 'Restrict access to Azure AD administration portal' is set to 'Yes' Shared The customer is responsible for implementing this recommendation. Restrict access to the Azure AD administration portal to administrators only. link 7
CIS_Azure_1.1.0 1.16 CIS_Azure_1.1.0_1.16 CIS Microsoft Azure Foundations Benchmark recommendation 1.16 1 Identity and Access Management Ensure that 'Self-service group management enabled' is set to 'No' Shared The customer is responsible for implementing this recommendation. Restrict group creation to administrators only. link 4
CIS_Azure_1.1.0 1.17 CIS_Azure_1.1.0_1.17 CIS Microsoft Azure Foundations Benchmark recommendation 1.17 1 Identity and Access Management Ensure that 'Users can create security groups' is set to 'No' Shared The customer is responsible for implementing this recommendation. Restrict security group creation to administrators only. link 4
CIS_Azure_1.1.0 1.18 CIS_Azure_1.1.0_1.18 CIS Microsoft Azure Foundations Benchmark recommendation 1.18 1 Identity and Access Management Ensure that 'Users who can manage security groups' is set to 'None' Shared The customer is responsible for implementing this recommendation. Restrict security group management to administrators only. link 4
CIS_Azure_1.1.0 1.19 CIS_Azure_1.1.0_1.19 CIS Microsoft Azure Foundations Benchmark recommendation 1.19 1 Identity and Access Management Ensure that 'Users can create Office 365 groups' is set to 'No' Shared The customer is responsible for implementing this recommendation. Restrict Office 365 group creation to administrators only. link 4
CIS_Azure_1.1.0 1.20 CIS_Azure_1.1.0_1.20 CIS Microsoft Azure Foundations Benchmark recommendation 1.20 1 Identity and Access Management Ensure that 'Users who can manage Office 365 groups' is set to 'None' Shared The customer is responsible for implementing this recommendation. Restrict Office 365 group management to administrators only. link 4
CIS_Azure_1.1.0 1.23 CIS_Azure_1.1.0_1.23 CIS Microsoft Azure Foundations Benchmark recommendation 1.23 1 Identity and Access Management Ensure that no custom subscription owner roles are created Shared The customer is responsible for implementing this recommendation. Subscription ownership should not include permission to create custom owner roles. The principle of least privilege should be followed and only necessary privileges should be assigned instead of allowing full administrative access. link 6
CIS_Azure_1.1.0 8.3 CIS_Azure_1.1.0_8.3 CIS Microsoft Azure Foundations Benchmark recommendation 8.3 8 Other Security Considerations Ensure that Resource Locks are set for mission critical Azure resources Shared The customer is responsible for implementing this recommendation. Resource Manager Locks provide a way for administrators to lock down Azure resources to prevent deletion of, or modifications to, a resource. These locks sit outside of the Role Based Access Controls (RBAC) hierarchy and, when applied, will place restrictions on the resource for all users. These are very useful when there is have an important resource in a subscription that users should not be able to delete or change and can help prevent accidental and malicious changes or deletion. link 1
CIS_Azure_1.3.0 1.16 CIS_Azure_1.3.0_1.16 CIS Microsoft Azure Foundations Benchmark recommendation 1.16 1 Identity and Access Management Ensure that 'Restrict user ability to access groups features in the Access Pane' is set to 'No' Shared The customer is responsible for implementing this recommendation. Restrict group creation to administrators only. link 4
CIS_Azure_1.3.0 1.17 CIS_Azure_1.3.0_1.17 CIS Microsoft Azure Foundations Benchmark recommendation 1.17 1 Identity and Access Management Ensure that 'Users can create security groups in Azure Portals' is set to 'No' Shared The customer is responsible for implementing this recommendation. Restrict security group creation to administrators only. link 4
CIS_Azure_1.3.0 1.18 CIS_Azure_1.3.0_1.18 CIS Microsoft Azure Foundations Benchmark recommendation 1.18 1 Identity and Access Management Ensure that 'Owners can manage group membership requests in the Access Panel' is set to 'No' Shared The customer is responsible for implementing this recommendation. Restrict security group management to administrators only. link 4
CIS_Azure_1.3.0 1.19 CIS_Azure_1.3.0_1.19 CIS Microsoft Azure Foundations Benchmark recommendation 1.19 1 Identity and Access Management Ensure that 'Users can create Microsoft 365 groups in Azure Portals' is set to 'No' Shared The customer is responsible for implementing this recommendation. Restrict Microsoft 365 group creation to administrators only. link 4
CIS_Azure_1.3.0 1.21 CIS_Azure_1.3.0_1.21 CIS Microsoft Azure Foundations Benchmark recommendation 1.21 1 Identity and Access Management Ensure that no custom subscription owner roles are created Shared The customer is responsible for implementing this recommendation. Subscription ownership should not include permission to create custom owner roles. The principle of least privilege should be followed and only necessary privileges should be assigned instead of allowing full administrative access. link 6
CIS_Azure_1.3.0 1.23 CIS_Azure_1.3.0_1.23 CIS Microsoft Azure Foundations Benchmark recommendation 1.23 1 Identity and Access Management Ensure Custom Role is assigned for Administering Resource Locks Shared The customer is responsible for implementing this recommendation. Resource locking is a powerful protection mechanism that can prevent inadvertent modification/deletion of resources within Azure subscriptions/Resource Groups and is a recommended NIST configuration. link 4
CIS_Azure_1.3.0 8.3 CIS_Azure_1.3.0_8.3 CIS Microsoft Azure Foundations Benchmark recommendation 8.3 8 Other Security Considerations Ensure that Resource Locks are set for mission critical Azure resources Shared The customer is responsible for implementing this recommendation. Resource Manager Locks provide a way for administrators to lock down Azure resources to prevent deletion of, or modifications to, a resource. These locks sit outside of the Role Based Access Controls (RBAC) hierarchy and, when applied, will place restrictions on the resource for all users. These locks are very useful when there is an important resource in a subscription that users should not be able to delete or change. Locks can help prevent accidental and malicious changes or deletion. link 1
CIS_Azure_1.4.0 1.15 CIS_Azure_1.4.0_1.15 CIS Microsoft Azure Foundations Benchmark recommendation 1.15 1 Identity and Access Management Ensure that 'Restrict user ability to access groups features in the Access Pane' is Set to 'Yes' Shared The customer is responsible for implementing this recommendation. Restricts group creation to administrators with permissions only. link 4
CIS_Azure_1.4.0 1.16 CIS_Azure_1.4.0_1.16 CIS Microsoft Azure Foundations Benchmark recommendation 1.16 1 Identity and Access Management Ensure that 'Users can create security groups in Azure portals, API or PowerShell' is set to 'No' Shared The customer is responsible for implementing this recommendation. Restrict security group creation to administrators only. link 4
CIS_Azure_1.4.0 1.17 CIS_Azure_1.4.0_1.17 CIS Microsoft Azure Foundations Benchmark recommendation 1.17 1 Identity and Access Management Ensure that 'Owners can manage group membership requests in the Access Panel' is set to 'No' Shared The customer is responsible for implementing this recommendation. Restrict security group management to administrators only. link 4
CIS_Azure_1.4.0 1.18 CIS_Azure_1.4.0_1.18 CIS Microsoft Azure Foundations Benchmark recommendation 1.18 1 Identity and Access Management Ensure that 'Users can create Microsoft 365 groups in Azure portals, API or PowerShell' is set to 'No' Shared The customer is responsible for implementing this recommendation. Restrict Microsoft 365 group creation to administrators only. link 4
CIS_Azure_1.4.0 1.20 CIS_Azure_1.4.0_1.20 CIS Microsoft Azure Foundations Benchmark recommendation 1.20 1 Identity and Access Management Ensure That No Custom Subscription Owner Roles Are Created Shared The customer is responsible for implementing this recommendation. Subscription ownership should not include permission to create custom owner roles. The principle of least privilege should be followed and only necessary privileges should be assigned instead of allowing full administrative access. link 6
CIS_Azure_1.4.0 1.22 CIS_Azure_1.4.0_1.22 CIS Microsoft Azure Foundations Benchmark recommendation 1.22 1 Identity and Access Management Ensure a Custom Role is Assigned Permissions for Administering Resource Locks Shared The customer is responsible for implementing this recommendation. Resource locking is a powerful protection mechanism that can prevent inadvertent modification/deletion of resources within Azure subscriptions/Resource Groups and is a recommended NIST configuration. link 4
CIS_Azure_1.4.0 8.5 CIS_Azure_1.4.0_8.5 CIS Microsoft Azure Foundations Benchmark recommendation 8.5 8 Other Security Considerations Ensure that Resource Locks are set for Mission Critical Azure Resources Shared The customer is responsible for implementing this recommendation. Resource Manager Locks provide a way for administrators to lock down Azure resources to prevent deletion of, or modifications to, a resource. These locks sit outside of the Role Based Access Controls (RBAC) hierarchy and, when applied, will place restrictions on the resource for all users. These locks are very useful when there is an important resource in a subscription that users should not be able to delete or change. Locks can help prevent accidental and malicious changes or deletion. link 1
CIS_Azure_2.0.0 1.18 CIS_Azure_2.0.0_1.18 CIS Microsoft Azure Foundations Benchmark recommendation 1.18 1 Ensure that 'Restrict user ability to access groups features in the Access Pane' is Set to 'Yes' Shared Setting to `Yes` could create administrative overhead by customers seeking certain group memberships that will have to be manually managed by administrators with appropriate permissions. Restricts group creation to administrators with permissions only. Self-service group management enables users to create and manage security groups or Office 365 groups in Azure Active Directory (Azure AD). Unless a business requires this day-to-day delegation for some users, self-service group management should be disabled. link 4
CIS_Azure_2.0.0 1.19 CIS_Azure_2.0.0_1.19 CIS Microsoft Azure Foundations Benchmark recommendation 1.19 1 Ensure that 'Users can create security groups in Azure portals, API or PowerShell' is set to 'No' Shared Enabling this setting could create a number of requests that would need to be managed by an administrator. Restrict security group creation to administrators only. When creating security groups is enabled, all users in the directory are allowed to create new security groups and add members to those groups. Unless a business requires this day-to-day delegation, security group creation should be restricted to administrators only. link 4
CIS_Azure_2.0.0 1.20 CIS_Azure_2.0.0_1.20 CIS Microsoft Azure Foundations Benchmark recommendation 1.20 1 Ensure that 'Owners can manage group membership requests in the Access Panel' is set to 'No' Shared Group Membership for user accounts will need to be handled by Admins and cause administrative overhead. Restrict security group management to administrators only. Restricting security group management to administrators only prohibits users from making changes to security groups. This ensures that security groups are appropriately managed and their management is not delegated to non-administrators. link 4
CIS_Azure_2.0.0 1.21 CIS_Azure_2.0.0_1.21 CIS Microsoft Azure Foundations Benchmark recommendation 1.21 1 Ensure that 'Users can create Microsoft 365 groups in Azure portals, API or PowerShell' is set to 'No' Shared Enabling this setting could create a number of requests that would need to be managed by an administrator. Restrict Microsoft 365 group creation to administrators only. Restricting Microsoft 365 group creation to administrators only ensures that creation of Microsoft 365 groups is controlled by the administrator. Appropriate groups should be created and managed by the administrator and group creation rights should not be delegated to any other user. link 4
CIS_Azure_2.0.0 1.23 CIS_Azure_2.0.0_1.23 CIS Microsoft Azure Foundations Benchmark recommendation 1.23 1 Ensure That No Custom Subscription Administrator Roles Exist Shared Subscriptions will need to be handled by Administrators with permissions. The principle of least privilege should be followed and only necessary privileges should be assigned instead of allowing full administrative access. Classic subscription admin roles offer basic access management and include Account Administrator, Service Administrator, and Co-Administrators. It is recommended the least necessary permissions be given initially. Permissions can be added as needed by the account holder. This ensures the account holder cannot perform actions which were not intended. link 7
CIS_Azure_2.0.0 1.24 CIS_Azure_2.0.0_1.24 CIS Microsoft Azure Foundations Benchmark recommendation 1.24 1 Ensure a Custom Role is Assigned Permissions for Administering Resource Locks Shared By adding this role, specific permissions may be granted for managing just resource locks rather than needing to provide the wide Owner or User Access Administrator role, reducing the risk of the user being able to do unintentional damage. Resource locking is a powerful protection mechanism that can prevent inadvertent modification/deletion of resources within Azure subscriptions/Resource Groups and is a recommended NIST configuration. Given the resource lock functionality is outside of standard Role Based Access Control(RBAC), it would be prudent to create a resource lock administrator role to prevent inadvertent unlocking of resources. link 4
CIS_Azure_2.0.0 10.1 CIS_Azure_2.0.0_10.1 CIS Microsoft Azure Foundations Benchmark recommendation 10.1 10 Ensure that Resource Locks are set for Mission-Critical Azure Resources Shared There can be unintended outcomes of locking a resource. Applying a lock to a parent service will cause it to be inherited by all resources within. Conversely, applying a lock to a resource may not apply to connected storage, leaving it unlocked. Please see the documentation for further information. Resource Manager Locks provide a way for administrators to lock down Azure resources to prevent deletion of, or modifications to, a resource. These locks sit outside of the Role Based Access Controls (RBAC) hierarchy and, when applied, will place restrictions on the resource for all users. These locks are very useful when there is an important resource in a subscription that users should not be able to delete or change. Locks can help prevent accidental and malicious changes or deletion. As an administrator, it may be necessary to lock a subscription, resource group, or resource to prevent other users in the organization from accidentally deleting or modifying critical resources. The lock level can be set to to `CanNotDelete` or `ReadOnly` to achieve this purpose. - `CanNotDelete` means authorized users can still read and modify a resource, but they cannot delete the resource. - `ReadOnly` means authorized users can read a resource, but they cannot delete or update the resource. Applying this lock is similar to restricting all authorized users to the permissions granted by the Reader role. link 1
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_High_R4 CM-5 FedRAMP_High_R4_CM-5 FedRAMP High CM-5 Configuration Management Access Restrictions For Change Shared n/a The organization defines, documents, approves, and enforces physical and logical access restrictions associated with changes to the information system. Supplemental Guidance: Any changes to the hardware, software, and/or firmware components of information systems can potentially have significant effects on the overall security of the systems. Therefore, organizations permit only qualified and authorized individuals to access information systems for purposes of initiating changes, including upgrades and modifications. Organizations maintain records of access to ensure that configuration change control is implemented and to support after-the-fact actions should organizations discover any unauthorized changes. Access restrictions for change also include software libraries. Access restrictions include, for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover). Related controls: AC-3, AC-6, PE-3. References: None. link 1
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
FedRAMP_Moderate_R4 CM-5 FedRAMP_Moderate_R4_CM-5 FedRAMP Moderate CM-5 Configuration Management Access Restrictions For Change Shared n/a The organization defines, documents, approves, and enforces physical and logical access restrictions associated with changes to the information system. Supplemental Guidance: Any changes to the hardware, software, and/or firmware components of information systems can potentially have significant effects on the overall security of the systems. Therefore, organizations permit only qualified and authorized individuals to access information systems for purposes of initiating changes, including upgrades and modifications. Organizations maintain records of access to ensure that configuration change control is implemented and to support after-the-fact actions should organizations discover any unauthorized changes. Access restrictions for change also include software libraries. Access restrictions include, for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover). Related controls: AC-3, AC-6, PE-3. References: None. link 1
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 0605.10h1System.12-10.h hipaa-0605.10h1System.12-10.h 0605.10h1System.12-10.h 06 Configuration Management 0605.10h1System.12-10.h 10.04 Security of System Files Shared n/a Only authorized administrators are allowed to implement approved upgrades to software, applications, and program libraries, based on business requirements and the security implications of the release. 6
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
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 18
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 18
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 A.9.2.3 ISO27001-2013_A.9.2.3 ISO 27001:2013 A.9.2.3 Access Control Management of privileged access rights Shared n/a The allocation and use of privileged access rights shall be restricted and controlled. link 33
ISO27001-2013 A.9.4.5 ISO27001-2013_A.9.4.5 ISO 27001:2013 A.9.4.5 Access Control Access control to program source code Shared n/a Access to program source code shall be restricted. link 10
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.s.2 Protection of web services and applications mp.s.2 Protection of web services and applications 404 not found n/a n/a 102
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 59
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-171_R2_3 .4.5 NIST_SP_800-171_R2_3.4.5 NIST SP 800-171 R2 3.4.5 Configuration Management Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems. Shared Microsoft and the customer share responsibilities for implementing this requirement. Any changes to the hardware, software, or firmware components of systems can potentially have significant effects on the overall security of the systems. Therefore, organizations permit only qualified and authorized individuals to access systems for purposes of initiating changes, including upgrades and modifications. Access restrictions for change also include software libraries. Access restrictions include physical and logical access control requirements, workflow automation, media libraries, abstract layers (e.g., changes implemented into external interfaces rather than directly into systems), and change windows (e.g., changes occur only during certain specified times). In addition to security concerns, commonly-accepted due diligence for configuration management includes access restrictions as an essential part in ensuring the ability to effectively manage the configuration. [SP 800-128] provides guidance on configuration change control. link 6
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_R4 CM-5 NIST_SP_800-53_R4_CM-5 NIST SP 800-53 Rev. 4 CM-5 Configuration Management Access Restrictions For Change Shared n/a The organization defines, documents, approves, and enforces physical and logical access restrictions associated with changes to the information system. Supplemental Guidance: Any changes to the hardware, software, and/or firmware components of information systems can potentially have significant effects on the overall security of the systems. Therefore, organizations permit only qualified and authorized individuals to access information systems for purposes of initiating changes, including upgrades and modifications. Organizations maintain records of access to ensure that configuration change control is implemented and to support after-the-fact actions should organizations discover any unauthorized changes. Access restrictions for change also include software libraries. Access restrictions include, for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover). Related controls: AC-3, AC-6, PE-3. References: None. link 1
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
NIST_SP_800-53_R5 CM-5 NIST_SP_800-53_R5_CM-5 NIST SP 800-53 Rev. 5 CM-5 Configuration Management Access Restrictions for Change Shared n/a Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system. link 1
op.acc.1 Identification op.acc.1 Identification 404 not found n/a n/a 66
op.acc.2 Access requirements op.acc.2 Access requirements 404 not found n/a n/a 64
op.acc.3 Segregation of functions and tasks op.acc.3 Segregation of functions and tasks 404 not found n/a n/a 43
op.acc.4 Access rights management process op.acc.4 Access rights management process 404 not found n/a n/a 40
op.acc.5 Authentication mechanism (external users) op.acc.5 Authentication mechanism (external users) 404 not found n/a n/a 72
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
org.4 Authorization process org.4 Authorization process 404 not found n/a n/a 126
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 1.2.8 PCI_DSS_v4.0_1.2.8 PCI DSS v4.0 1.2.8 Requirement 01: Install and Maintain Network Security Controls Network security controls (NSCs) are configured and maintained Shared n/a Configuration files for NSCs are: • Secured from unauthorized access. • Kept consistent with active network configurations. link 3
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
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type
CIS Microsoft Azure Foundations Benchmark v1.1.0 1a5bb27d-173f-493e-9568-eb56638dde4d Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.3.0 612b5213-9160-4969-8578-1518bd2a000c Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.4.0 c3f5c4d9-9a1d-4a99-85c0-7f93e384d5c5 Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v2.0.0 06f19060-9e68-4070-92ca-f15cc126059e Regulatory Compliance GA BuiltIn
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn
HITRUST/HIPAA a169a624-5599-4385-a696-c8d643089fab Regulatory Compliance GA BuiltIn
ISO 27001:2013 89c6cddc-1c73-4ac1-b19c-54d1a15a42f2 Regulatory Compliance GA BuiltIn
NIST SP 800-171 Rev. 2 03055927-78bd-4236-86c0-f36125a10dc9 Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn
PCI DSS v4 c676748e-3af9-4e22-bc28-50feed564afb Regulatory Compliance GA BuiltIn
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn
Spain ENS 175daf90-21e1-4fec-b745-7b4c909aa94c Regulatory Compliance GA BuiltIn
SWIFT CSP-CSCF v2022 7bc7cd6c-4114-ff31-3cac-59be3157596d Regulatory Compliance GA BuiltIn
History
Date/Time (UTC ymd) (i) Change type Change detail
2022-09-27 16:35:32 change Minor (1.0.0 > 1.1.0)
2022-09-02 16:33:37 add bd4dc286-2f30-5b95-777c-681f3a7913d3
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC