last sync: 2025-Feb-05 19:33:00 UTC

Linux machines should meet requirements for the Azure compute security baseline

Azure BuiltIn Policy definition

Source Azure Portal
Display name Linux machines should meet requirements for the Azure compute security baseline
Id fc9b3da7-8347-4380-8e70-0a0361d8dedd
Version 2.2.0
Details on versioning
Versioning Versions supported for Versioning: 2
2.1.0
2.2.0
Built-in Versioning [Preview]
Category Guest Configuration
Microsoft Learn
Description Requires that prerequisites are deployed to the policy assignment scope. For details, visit https://aka.ms/gcpol. Machines are non-compliant if the machine is not configured correctly for one of the recommendations in the Azure compute security baseline.
Mode Indexed
Type BuiltIn
Preview False
Deprecated False
Effect Default
AuditIfNotExists
Allowed
AuditIfNotExists, Disabled
RBAC role(s) none
Rule aliases IF (7)
Alias Namespace ResourceType Path PathIsDefault DefaultPath Modifiable
Microsoft.Compute/imageOffer Microsoft.Compute
Microsoft.Compute
Microsoft.Compute
virtualMachines
virtualMachineScaleSets
disks
properties.storageProfile.imageReference.offer
properties.virtualMachineProfile.storageProfile.imageReference.offer
properties.creationData.imageReference.id
True
True
True


False
False
False
Microsoft.Compute/imagePublisher Microsoft.Compute
Microsoft.Compute
Microsoft.Compute
virtualMachines
virtualMachineScaleSets
disks
properties.storageProfile.imageReference.publisher
properties.virtualMachineProfile.storageProfile.imageReference.publisher
properties.creationData.imageReference.id
True
True
True


False
False
False
Microsoft.Compute/imageSKU Microsoft.Compute
Microsoft.Compute
Microsoft.Compute
virtualMachines
virtualMachineScaleSets
disks
properties.storageProfile.imageReference.sku
properties.virtualMachineProfile.storageProfile.imageReference.sku
properties.creationData.imageReference.id
True
True
True


False
False
False
Microsoft.Compute/virtualMachines/osProfile.linuxConfiguration Microsoft.Compute virtualMachines properties.osProfile.linuxConfiguration True True
Microsoft.Compute/virtualMachines/storageProfile.osDisk.osType Microsoft.Compute virtualMachines properties.storageProfile.osDisk.osType True True
Microsoft.ConnectedVMwarevSphere/virtualMachines/osProfile.osType Microsoft.ConnectedVMwarevSphere virtualmachines properties.osProfile.osType True False
Microsoft.HybridCompute/imageOffer Microsoft.HybridCompute machines properties.osName True False
THEN-ExistenceCondition (1)
Alias Namespace ResourceType Path PathIsDefault DefaultPath Modifiable
Microsoft.GuestConfiguration/guestConfigurationAssignments/complianceStatus Microsoft.GuestConfiguration guestConfigurationAssignments properties.complianceStatus True False
Rule resource types IF (3)
Microsoft.Compute/virtualMachines
Microsoft.ConnectedVMwarevSphere/virtualMachines
Microsoft.HybridCompute/machines
Compliance
The following 32 compliance controls are associated with this Policy definition 'Linux machines should meet requirements for the Azure compute security baseline' (fc9b3da7-8347-4380-8e70-0a0361d8dedd)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
Azure Security Baseline Azure Security Baseline 404 not found n/a n/a 4
Azure_Security_Benchmark_v3.0 PV-4 Azure_Security_Benchmark_v3.0_PV-4 Microsoft cloud security benchmark PV-4 Posture and Vulnerability Management Audit and enforce secure configurations for compute resources Shared **Security Principle:** Continuously monitor and alert when there is a deviation from the defined configuration baseline in your compute resources. Enforce the desired configuration according to the baseline configuration by denying the non-compliant configuration or deploy a configuration in compute resources. **Azure Guidance:** Use Microsoft Defender for Cloud and Azure Policy guest configuration agent to regularly assess and remediate configuration deviations on your Azure compute resources, including VMs, containers, and others. In addition, you can use Azure Resource Manager templates, custom operating system images, or Azure Automation State Configuration to maintain the security configuration of the operating system. Microsoft VM templates in conjunction with Azure Automation State Configuration can assist in meeting and maintaining security requirements. Note: Azure Marketplace VM images published by Microsoft are managed and maintained by Microsoft. **Implementation and additional context:** How to implement Microsoft Defender for Cloud vulnerability assessment recommendations: https://docs.microsoft.com/azure/security-center/security-center-vulnerability-assessment-recommendations How to create an Azure virtual machine from an ARM template: https://docs.microsoft.com/azure/virtual-machines/windows/ps-template Azure Automation State Configuration overview: https://docs.microsoft.com/azure/automation/automation-dsc-overview Create a Windows virtual machine in the Azure portal: https://docs.microsoft.com/azure/virtual-machines/windows/quick-create-portal Container security in Microsoft Defender for Cloud: https://docs.microsoft.com/azure/security-center/container-security n/a link 13
CMMC_2.0_L2 CM.L2-3.4.1 CMMC_2.0_L2_CM.L2-3.4.1 404 not found n/a n/a 25
CMMC_2.0_L2 CM.L2-3.4.2 CMMC_2.0_L2_CM.L2-3.4.2 404 not found n/a n/a 27
CMMC_L3 CM.2.061 CMMC_L3_CM.2.061 CMMC L3 CM.2.061 Configuration Management Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. Shared Microsoft and the customer share responsibilities for implementing this requirement. Baseline configurations are documented, formally reviewed, and agreed-upon specifications for systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and changes to systems. Baseline configurations include information about system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and update and patch information on operating systems and applications; and configuration settings and parameters), network topology, and the logical placement of those components within the system architecture. Baseline configurations of systems also reflect the current enterprise architecture. Maintaining effective baseline configurations requires creating new baselines as organizational systems change over time. Baseline configuration maintenance includes reviewing and updating the baseline configuration when changes are made based on security risks and deviations from the established baseline configuration Organizations can implement centralized system component inventories that include components from multiple organizational systems. In such situations, organizations ensure that the resulting inventories include system-specific information required for proper component accountability (e.g., system association, system owner). Information deemed necessary for effective accountability of system components includes hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include manufacturer, device type, model, serial number, and physical location. link 2
CSA_v4.0.12 CCC_04 CSA_v4.0.12_CCC_04 CSA Cloud Controls Matrix v4.0.12 CCC 04 Change Control and Configuration Management Unauthorized Change Protection Shared n/a Restrict the unauthorized addition, removal, update, and management of organization assets. 25
CSA_v4.0.12 IVS_04 CSA_v4.0.12_IVS_04 CSA Cloud Controls Matrix v4.0.12 IVS 04 Infrastructure & Virtualization Security OS Hardening and Base Controls Shared n/a Harden host and guest OS, hypervisor or infrastructure control plane according to their respective best practices, and supported by technical controls, as part of a security baseline. 3
EU_2555_(NIS2)_2022 EU_2555_(NIS2)_2022_21 EU_2555_(NIS2)_2022_21 EU 2022/2555 (NIS2) 2022 21 Cybersecurity risk-management measures Shared n/a Requires essential and important entities to take appropriate measures to manage cybersecurity risks. 194
EU_GDPR_2016_679_Art. 24 EU_GDPR_2016_679_Art._24 EU General Data Protection Regulation (GDPR) 2016/679 Art. 24 Chapter 4 - Controller and processor Responsibility of the controller Shared n/a n/a 311
EU_GDPR_2016_679_Art. 25 EU_GDPR_2016_679_Art._25 EU General Data Protection Regulation (GDPR) 2016/679 Art. 25 Chapter 4 - Controller and processor Data protection by design and by default Shared n/a n/a 311
EU_GDPR_2016_679_Art. 28 EU_GDPR_2016_679_Art._28 EU General Data Protection Regulation (GDPR) 2016/679 Art. 28 Chapter 4 - Controller and processor Processor Shared n/a n/a 311
EU_GDPR_2016_679_Art. 32 EU_GDPR_2016_679_Art._32 EU General Data Protection Regulation (GDPR) 2016/679 Art. 32 Chapter 4 - Controller and processor Security of processing Shared n/a n/a 311
FedRAMP_High_R4 CM-6 FedRAMP_High_R4_CM-6 FedRAMP High CM-6 Configuration Management Configuration Settings Shared n/a The organization: a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements; b. Implements the configuration settings; c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures. Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4. References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. link 23
FedRAMP_Moderate_R4 CM-6 FedRAMP_Moderate_R4_CM-6 FedRAMP Moderate CM-6 Configuration Management Configuration Settings Shared n/a The organization: a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements; b. Implements the configuration settings; c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures. Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4. References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. link 23
HITRUST_CSF_v11.3 10.k HITRUST_CSF_v11.3_10.k HITRUST CSF v11.3 10.k Security In Development and Support Processes To ensure the security of application system software and information through the development process, project and support environments shall be strictly controlled. Shared 1. The purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance for configuration management is to be formally addressed. 2. Changes to mobile device operating systems, patch levels, and/or applications is to be managed through a formal change management process. 3. A baseline configuration of the information system is to be developed, documented, and maintained under configuration control. The implementation of changes, including patches, service packs, and other updates and modifications, shall be controlled by the use of formal change control procedures. 34
NIST_SP_800-171_R2_3 .4.1 NIST_SP_800-171_R2_3.4.1 NIST SP 800-171 R2 3.4.1 Configuration Management Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. Shared Microsoft and the customer share responsibilities for implementing this requirement. Baseline configurations are documented, formally reviewed, and agreed-upon specifications for systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and changes to systems. Baseline configurations include information about system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and update and patch information on operating systems and applications; and configuration settings and parameters), network topology, and the logical placement of those components within the system architecture. Baseline configurations of systems also reflect the current enterprise architecture. Maintaining effective baseline configurations requires creating new baselines as organizational systems change over time. Baseline configuration maintenance includes reviewing and updating the baseline configuration when changes are made based on security risks and deviations from the established baseline configuration. Organizations can implement centralized system component inventories that include components from multiple organizational systems. In such situations, organizations ensure that the resulting inventories include system-specific information required for proper component accountability (e.g., system association, system owner). Information deemed necessary for effective accountability of system components includes hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include manufacturer, device type, model, serial number, and physical location. [SP 800-128] provides guidance on security-focused configuration management. link 31
NIST_SP_800-171_R2_3 .4.2 NIST_SP_800-171_R2_3.4.2 NIST SP 800-171 R2 3.4.2 Configuration Management Establish and enforce security configuration settings for information technology products employed in organizational systems. Shared Microsoft and the customer share responsibilities for implementing this requirement. Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture or functionality of the system. Information technology products for which security-related configuration settings can be defined include mainframe computers, servers, workstations, input and output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security parameters are those parameters impacting the security state of systems including the parameters required to satisfy other security requirements. Security parameters include: registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. [SP 800-70] and [SP 800-128] provide guidance on security configuration settings. link 25
NIST_SP_800-171_R3_3 .1.16 NIST_SP_800-171_R3_3.1.16 NIST 800-171 R3 3.1.16 Access Control Wireless Access Shared Establishing usage restrictions, configuration requirements, and connection requirements for wireless access to the system provides criteria to support access authorization decisions. These restrictions and requirements reduce susceptibility to unauthorized system access through wireless technologies. Wireless networks use authentication protocols that provide credential protection and mutual authentication. Organizations authenticate individuals and devices to protect wireless access to the system. Special attention is given to the variety of devices with potential wireless access to the system, including small form factor mobile devices (e.g., smart phones, smart watches). Wireless networking capabilities that are embedded within system components represent a significant potential vulnerability that can be exploited by adversaries. Disabling wireless capabilities when not needed for essential missions or business functions can help reduce susceptibility to threats by adversaries involving wireless technologies. a. Establish usage restrictions, configuration requirements, and connection requirements for each type of wireless access to the system. b. Authorize each type of wireless access to the system prior to establishing such connections. c. Disable, when not intended for use, wireless networking capabilities prior to issuance and deployment. 8
NIST_SP_800-53_R4 CM-6 NIST_SP_800-53_R4_CM-6 NIST SP 800-53 Rev. 4 CM-6 Configuration Management Configuration Settings Shared n/a The organization: a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements; b. Implements the configuration settings; c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures. Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4. References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. link 23
NIST_SP_800-53_R5.1.1 CM.6.1 NIST_SP_800-53_R5.1.1_CM.6.1 NIST SP 800-53 R5.1.1 CM.6.1 Configuration Management Control Configuration Settings | Automated Management, Application, and Verification Shared Manage, apply, and verify configuration settings for [Assignment: organization-defined system components] using [Assignment: organization-defined automated mechanisms]. Automated tools (e.g., hardening tools, baseline configuration tools) can improve the accuracy, consistency, and availability of configuration settings information. Automation can also provide data aggregation and data correlation capabilities, alerting mechanisms, and dashboards to support risk-based decision-making within the organization. 3
NIST_SP_800-53_R5 CM-6 NIST_SP_800-53_R5_CM-6 NIST SP 800-53 Rev. 5 CM-6 Configuration Management Configuration Settings Shared n/a a. Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using [Assignment: organization-defined common secure configurations]; b. Implement the configuration settings; c. Identify, document, and approve any deviations from established configuration settings for [Assignment: organization-defined system components] based on [Assignment: organization-defined operational requirements]; and d. Monitor and control changes to the configuration settings in accordance with organizational policies and procedures. link 23
RBI_CSF_Banks_v2016 13.1 RBI_CSF_Banks_v2016_13.1 Advanced Real-Timethreat Defenceand Management Advanced Real-Timethreat Defenceand Management-13.1 n/a Build a robust defence against the installation, spread, and execution of malicious code at multiple points in the enterprise. 21
RBI_CSF_Banks_v2016 17.1 RBI_CSF_Banks_v2016_17.1 Audit Log Settings Audit Log Settings-17.1 n/a Implement and periodically validate settings for capturing of appropriate logs/audit trails of each device, system software and application software , ensuring that logs include minimum information to uniquely identify the log for example by including a date, timestamp, source addresses, destination addresses, and various other useful elements of each packet and/or event and/or transaction. 14
SOC_2 CC6.8 SOC_2_CC6.8 SOC 2 Type 2 CC6.8 Logical and Physical Access Controls Prevent or detect against unauthorized or malicious software Shared The customer is responsible for implementing this recommendation. Restricts Application and Software Installation — The ability to install applications and software is restricted to authorized individuals. • Detects Unauthorized Changes to Software and Configuration Parameters — Processes are in place to detect changes to software and configuration parameters that may be indicative of unauthorized or malicious software. • Uses a Defined Change Control Process — A management-defined change control process is used for the implementation of software. • Uses Antivirus and Anti-Malware Software — Antivirus and anti-malware software is implemented and maintained to provide for the interception or detection and remediation of malware. • Scans Information Assets from Outside the Entity for Malware and Other Unauthorized Software — Procedures are in place to scan information assets that have been transferred or returned to the entity’s custody for malware and other unauthorized software and to remove any items detected prior to its implementation on the network. 47
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
SOC_2023 CC2.3 SOC_2023_CC2.3 SOC 2023 CC2.3 Information and Communication To facilitate effective internal communication. Shared n/a Entity to communicate with external parties regarding matters affecting the functioning of internal control. 219
SOC_2023 CC5.3 SOC_2023_CC5.3 SOC 2023 CC5.3 Control Activities To maintain alignment with organizational objectives and regulatory requirements. Shared n/a Entity deploys control activities through policies that establish what is expected and in procedures that put policies into action by establishing Policies and Procedures to Support Deployment of Management’s Directives, Responsibility and Accountability for Executing Policies and Procedures, perform tasks in a timely manner, taking corrective actions, perform using competent personnel and reassess policies and procedures. 230
SOC_2023 CC7.4 SOC_2023_CC7.4 SOC 2023 CC7.4 Systems Operations To effectively manage security incidents, minimize their impact, and protect assets, operations, and reputation. Shared n/a The entity responds to identified security incidents by: a. Executing a defined incident-response program to understand, contain, remediate, and communicate security incidents by assigning roles and responsibilities; b. Establishing procedures to contain security incidents; c. Mitigating ongoing security incidents, End Threats Posed by Security Incidents; d. Restoring operations; e. Developing and Implementing Communication Protocols for Security Incidents; f. Obtains Understanding of Nature of Incident and Determines Containment Strategy; g. Remediation Identified Vulnerabilities; h. Communicating Remediation Activities; and, i. Evaluating the Effectiveness of Incident Response and periodic incident evaluations. 214
SOC_2023 CC8.1 SOC_2023_CC8.1 SOC 2023 CC8.1 Change Management To minimise risks, ensure quality, optimise efficiency, and enhance resilience in the face of change. Shared n/a The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives by Managing Changes Throughout the System Life Cycle, authorizing changes, designing and developing changes, documenting all changes, tracking system changes, configuring software's, testing system changes, approving system changes, deploying system changes, identifying and evaluating system changes, creating baseline configurations for IT technologies and providing necessary changes in emergency situations. 148
SWIFT_CSCF_2024 2.1 SWIFT_CSCF_2024_2.1 SWIFT Customer Security Controls Framework 2024 2.1 Risk Management Internal Data Flow Security Shared The protection of internal data flows safeguards against unintended disclosure, modification, and access of the data while in transit. To ensure the confidentiality, integrity, and authenticity of application data flows between ’user’s Swift-related components. 48
SWIFT_CSCF_2024 2.3 SWIFT_CSCF_2024_2.3 SWIFT Customer Security Controls Framework 2024 2.3 Risk Management System Hardening Shared 1. System hardening applies the security concept of “least privilege” to a system by disabling features and services that are not required for normal system operations. 2. This process reduces the system capabilities, features, and protocols that a malicious person may use during an attack. To reduce the cyber-attack surface of Swift-related components by performing system hardening. 3
SWIFT_CSCF_2024 9.2 SWIFT_CSCF_2024_9.2 404 not found n/a n/a 16
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type
[Preview]: Audit configuration against Automanage Best Practices c138fd1a-e08f-4318-9490-d11ef2c2f9c1 Automanage Preview BuiltIn
[Preview]: CMMC 2.0 Level 2 4e50fd13-098b-3206-61d6-d1d78205cb45 Regulatory Compliance Preview BuiltIn
[Preview]: Reserve Bank of India - IT Framework for Banks d0d5578d-cc08-2b22-31e3-f525374f235a Regulatory Compliance Preview BuiltIn
CMMC Level 3 b5629c75-5c77-4422-87b9-2509e680f8de Regulatory Compliance GA BuiltIn
CSA CSA Cloud Controls Matrix v4.0.12 8791506a-dec4-497a-a83f-3abfde37c400 Regulatory Compliance GA BuiltIn
Enforce Azure Compute Security Benchmark compliance auditing Enforce-ACSB Guest Configuration GA ALZ
EU 2022/2555 (NIS2) 2022 42346945-b531-41d8-9e46-f95057672e88 Regulatory Compliance GA BuiltIn
EU General Data Protection Regulation (GDPR) 2016/679 7326812a-86a4-40c8-af7c-8945de9c4913 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 CSF v11.3 e0d47b75-5d99-442a-9d60-07f2595ab095 Regulatory Compliance GA BuiltIn
Microsoft cloud security benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn
NIST 800-171 R3 38916c43-6876-4971-a4b1-806aa7e55ccc Regulatory Compliance GA BuiltIn
NIST SP 800-171 Rev. 2 03055927-78bd-4236-86c0-f36125a10dc9 Regulatory Compliance GA BuiltIn
NIST SP 800-53 R5.1.1 60205a79-6280-4e20-a147-e2011e09dc78 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
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn
SOC 2023 53ad89f5-8542-49e9-ba81-1cbd686e0d52 Regulatory Compliance GA BuiltIn
SWIFT Customer Security Controls Framework 2024 7499005e-df5a-45d9-810f-041cf346678c Regulatory Compliance GA BuiltIn
History
Date/Time (UTC ymd) (i) Change type Change detail
2024-01-22 17:47:54 change Minor (2.1.0 > 2.2.0)
2023-08-03 17:56:09 change Minor (2.0.0 > 2.1.0)
2022-01-28 17:51:01 change Major (1.3.0 > 2.0.0)
2021-12-06 22:17:57 change Minor (1.2.0 > 1.3.0)
2021-10-19 19:10:32 change Version remains equal, old suffix: preview (1.2.0-preview > 1.2.0)
2021-10-04 15:27:15 change Minor, suffix remains equal (1.1.1-preview > 1.2.0-preview)
2021-05-11 14:06:18 change Patch, suffix remains equal (1.1.0-preview > 1.1.1-preview)
2021-01-22 09:14:53 change Minor, suffix remains equal (1.0.0-preview > 1.1.0-preview)
2020-09-02 14:03:46 add fc9b3da7-8347-4380-8e70-0a0361d8dedd
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC