Az Policy Advertizer

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

1.18

CIS_Azure_2.0.0_1.18

CIS Microsoft Azure Foundations Benchmark recommendation 1.18

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.

1.19

CIS_Azure_2.0.0_1.19

CIS Microsoft Azure Foundations Benchmark recommendation 1.19

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.

1.20

CIS_Azure_2.0.0_1.20

CIS Microsoft Azure Foundations Benchmark recommendation 1.20

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.

1.21

CIS_Azure_2.0.0_1.21

CIS Microsoft Azure Foundations Benchmark recommendation 1.21

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.

1.23

CIS_Azure_2.0.0_1.23

CIS Microsoft Azure Foundations Benchmark recommendation 1.23

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.

1.24

CIS_Azure_2.0.0_1.24

CIS Microsoft Azure Foundations Benchmark recommendation 1.24

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.

10.1

CIS_Azure_2.0.0_10.1

CIS Microsoft Azure Foundations Benchmark recommendation 10.1

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.

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.

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

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.

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.

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.

FedRAMP_Moderate_R4

CM-3

FedRAMP_Moderate_R4_CM-3

FedRAMP Moderate CM-3

Configuration Management

Configuration Change Control

Shared

n/a

FedRAMP_Moderate_R4

CM-4

FedRAMP_Moderate_R4_CM-4

FedRAMP Moderate CM-4

Configuration Management

Security Impact Analysis

Shared

n/a

FedRAMP_Moderate_R4

CM-5

FedRAMP_Moderate_R4_CM-5

FedRAMP Moderate CM-5

Configuration Management

Access Restrictions For Change

Shared

n/a

hipaa-0228.09k2Organizational.3-09.k

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.

hipaa-0602.06g1Organizational.3-06.g

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.

hipaa-0605.10h1System.12-10.h

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.

hipaa-0618.09b1System.1-09.b

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.

hipaa-0638.10k2Organizational.34569-10.k

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.

hipaa-0640.10k2Organizational.1012-10.k

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.

hipaa-0641.10k2Organizational.11-10.k

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.

hipaa-0643.10k3Organizational.3-10.k

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.

hipaa-0669.10hCSPSystem.1-10.h

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.

hipaa-0671.10k1System.1-10.k

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.

hipaa-0672.10k3System.5-10.k

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.

hipaa-0821.09m2Organizational.2-09.m

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.

hipaa-0863.09m2Organizational.910-09.m

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.

hipaa-1208.09aa3System.1-09.aa

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.

hipaa-1211.09aa3System.4-09.aa

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.

hipaa-1734.03d2Organizational.1-03.d

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

NIST_SP_800-53_R4_CM-3(2)

CM-3(2)

NIST SP 800-53 Rev. 4 CM-3 (2)

Configuration Management

Test / Validate / Document Changes

Shared

n/a

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

NIST_SP_800-53_R4_CM-4(1)

CM-4(1)

NIST SP 800-53 Rev. 4 CM-4 (1)

Configuration Management

Separate Test Environments

Shared

n/a

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

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

NIST_SP_800-53_R5_CM-3(2)

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.

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.

NIST_SP_800-53_R5_CM-4(1)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.