last sync: 2023-Feb-06 18:40:05 UTC

Azure Policy definition

Authentication to Linux machines should require SSH keys

Name Authentication to Linux machines should require SSH keys
Azure Portal
Id 630c64f9-8b6b-4c64-b511-6544ceff6fd6
Version 3.0.0
details on versioning
Category Guest Configuration
Microsoft docs
Description Although SSH itself provides an encrypted connection, using passwords with SSH still leaves the VM vulnerable to brute-force attacks. The most secure option for authenticating to an Azure Linux virtual machine over SSH is with a public-private key pair, also known as SSH keys. Learn more: https://docs.microsoft.com/azure/virtual-machines/linux/create-ssh-keys-detailed.
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 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
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
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
false
false
false
Microsoft.Compute/virtualMachines/osProfile.linuxConfiguration Microsoft.Compute virtualMachines properties.osProfile.linuxConfiguration true
Microsoft.Compute/virtualMachines/storageProfile.osDisk.osType Microsoft.Compute virtualMachines properties.storageProfile.osDisk.osType true
Microsoft.ConnectedVMwarevSphere/virtualMachines/osProfile.osType Microsoft.ConnectedVMwarevSphere virtualmachines properties.osProfile.osType false
Microsoft.HybridCompute/imageOffer Microsoft.HybridCompute machines properties.osName false
THEN-ExistenceCondition (1)
Alias Namespace ResourceType DefaultPath Modifiable
Microsoft.GuestConfiguration/guestConfigurationAssignments/complianceStatus Microsoft.GuestConfiguration guestConfigurationAssignments properties.complianceStatus false
Rule
ResourceTypes
IF (3)
Microsoft.Compute/virtualMachines
Microsoft.ConnectedVMwarevSphere/virtualMachines
Microsoft.HybridCompute/machines
Compliance The following 25 compliance controls are associated with this Policy definition 'Authentication to Linux machines should require SSH keys' (630c64f9-8b6b-4c64-b511-6544ceff6fd6)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
Azure_Security_Benchmark_v3.0 IM-6 Azure_Security_Benchmark_v3.0_IM-6 Azure Security Benchmark IM-6 Identity Management Use strong authentication controls Shared **Security Principle:** Enforce strong authentication controls (strong passwordless authentication or multi-factor authentication) with your centralized identity and authentication management system for all access to resources. Authentication based on password credentials alone is considered legacy, as it is insecure and does not stand up to popular attack methods. When deploying strong authentication, configure administrators and privileged users first, to ensure the highest level of the strong authentication method, quickly followed by rolling out the appropriate strong authentication policy to all users. Note: If legacy password-based authentication is required for legacy applications and scenarios, ensure password security best practices such as complexity requirements, are followed. **Azure Guidance:** Azure AD supports strong authentication controls through passwordless methods and multi-factor authentication (MFA). - Passwordless authentication: Use passwordless authentication as your default authentication method. There are three options available in passwordless authentication: Windows Hello for Business, Microsoft Authenticator app phone sign-in, and FIDO 2Keys. In addition, customers can use on-premises authentication methods such as smart cards. - Multi-factor authentication: Azure MFA can be enforced on all users, select users, or at the per-user level based on sign-in conditions and risk factors. Enable Azure MFA and follow Microsoft Defender for Cloud identity and access management recommendations for your MFA setup. If legacy password-based authentication is still used for Azure AD authentication, be aware that cloud-only accounts (user accounts created directly in Azure) have a default baseline password policy. And hybrid accounts (user accounts that come from on-premises Active Directory) follow the on-premises password policies. For third-party applications and services that may have default IDs and passwords, you should disable or change them during initial service setup. **Implementation and additional context:** How to enable MFA in Azure: https://docs.microsoft.com/azure/active-directory/authentication/howto-mfa-getstarted Introduction to passwordless authentication options for Azure Active Directory: https://docs.microsoft.com/azure/active-directory/authentication/concept-authentication-passwordless Azure AD default password policy: https://docs.microsoft.com/azure/active-directory/authentication/concept-sspr-policy#password-policies-that-only-apply-to-cloud-user-accounts Eliminate bad passwords using Azure AD Password Protection: https://docs.microsoft.com/azure/active-directory/authentication/concept-password-ban-bad Block legacy authentication: https://docs.microsoft.com/azure/active-directory/conditional-access/block-legacy-authentication n/a link 7
CMMC_2.0_L2 AC.L1-3.1.1 CMMC_2.0_L2_AC.L1-3.1.1 404 not found n/a n/a 57
CMMC_2.0_L2 IA.L1-3.5.2 CMMC_2.0_L2_IA.L1-3.5.2 404 not found n/a n/a 18
FedRAMP_High_R4 AC-3 FedRAMP_High_R4_AC-3 FedRAMP High AC-3 Access Control Access Enforcement Shared n/a The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3. References: None. link 21
FedRAMP_High_R4 IA-5 FedRAMP_High_R4_IA-5 FedRAMP High IA-5 Identification And Authentication Authenticator Management Shared n/a The organization manages information system authenticators by: a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator; b. Establishing initial authenticator content for authenticators defined by the organization; c. Ensuring that authenticators have sufficient strength of mechanism for their intended use; d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost/compromised or damaged authenticators, and for revoking authenticators; e. Changing default content of authenticators prior to information system installation; f. Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators; g. Changing/refreshing authenticators [Assignment: organization-defined time period by authenticator type]; h. Protecting authenticator content from unauthorized disclosure and modification; i. Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators; and j. Changing authenticators for group/role accounts when membership to those accounts changes. Supplemental Guidance: Individual authenticators include, for example, passwords, tokens, biometrics, PKI certificates, and key cards. Initial authenticator content is the actual content (e.g., the initial password) as opposed to requirements about authenticator content (e.g., minimum password length). In many cases, developers ship information system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk. The requirement to protect individual authenticators may be implemented via control PL-4 or PS-6 for authenticators in the possession of individuals and by controls AC-3, AC-6, and SC-28 for authenticators stored within organizational information systems (e.g., passwords stored in hashed or encrypted formats, files containing encrypted or hashed passwords accessible with administrator privileges). Information systems support individual authenticator management by organization-defined settings and restrictions for various authenticator characteristics including, for example, minimum password length, password composition, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Specific actions that can be taken to safeguard authenticators include, for example, maintaining possession of individual authenticators, not loaning or sharing individual authenticators with others, and reporting lost, stolen, or compromised authenticators immediately. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include, for example, certificates and passwords. Related controls: AC-2, AC-3, AC-6, CM-6, IA-2, IA-4, IA-8, PL-4, PS-5, PS-6, SC-12, SC-13, SC-17, SC-28. References: OMB Memoranda 04-04, 11-11; FIPS Publication 201; NIST Special Publications 800-73, 800-63, 800-76, 800-78; FICAM Roadmap and Implementation Guidance link 18
FedRAMP_Moderate_R4 AC-3 FedRAMP_Moderate_R4_AC-3 FedRAMP Moderate AC-3 Access Control Access Enforcement Shared n/a The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3. References: None. link 21
FedRAMP_Moderate_R4 IA-5 FedRAMP_Moderate_R4_IA-5 FedRAMP Moderate IA-5 Identification And Authentication Authenticator Management Shared n/a The organization manages information system authenticators by: a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator; b. Establishing initial authenticator content for authenticators defined by the organization; c. Ensuring that authenticators have sufficient strength of mechanism for their intended use; d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost/compromised or damaged authenticators, and for revoking authenticators; e. Changing default content of authenticators prior to information system installation; f. Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators; g. Changing/refreshing authenticators [Assignment: organization-defined time period by authenticator type]; h. Protecting authenticator content from unauthorized disclosure and modification; i. Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators; and j. Changing authenticators for group/role accounts when membership to those accounts changes. Supplemental Guidance: Individual authenticators include, for example, passwords, tokens, biometrics, PKI certificates, and key cards. Initial authenticator content is the actual content (e.g., the initial password) as opposed to requirements about authenticator content (e.g., minimum password length). In many cases, developers ship information system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk. The requirement to protect individual authenticators may be implemented via control PL-4 or PS-6 for authenticators in the possession of individuals and by controls AC-3, AC-6, and SC-28 for authenticators stored within organizational information systems (e.g., passwords stored in hashed or encrypted formats, files containing encrypted or hashed passwords accessible with administrator privileges). Information systems support individual authenticator management by organization-defined settings and restrictions for various authenticator characteristics including, for example, minimum password length, password composition, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Specific actions that can be taken to safeguard authenticators include, for example, maintaining possession of individual authenticators, not loaning or sharing individual authenticators with others, and reporting lost, stolen, or compromised authenticators immediately. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include, for example, certificates and passwords. Related controls: AC-2, AC-3, AC-6, CM-6, IA-2, IA-4, IA-8, PL-4, PS-5, PS-6, SC-12, SC-13, SC-17, SC-28. References: OMB Memoranda 04-04, 11-11; FIPS Publication 201; NIST Special Publications 800-73, 800-63, 800-76, 800-78; FICAM Roadmap and Implementation Guidance link 18
NIST_SP_800-171_R2_3 .1.1 NIST_SP_800-171_R2_3.1.1 NIST SP 800-171 R2 3.1.1 Access Control Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). Shared Microsoft and the customer share responsibilities for implementing this requirement. Access control policies (e.g., identity- or role-based policies, control matrices, and cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, and domains) in systems. Access enforcement mechanisms can be employed at the application and service level to provide increased information security. Other systems include systems internal and external to the organization. This requirement focuses on account management for systems and applications. The definition of and enforcement of access authorizations, other than those determined by account type (e.g., privileged verses non-privileged) are addressed in requirement 3.1.2. link 55
NIST_SP_800-171_R2_3 .5.2 NIST_SP_800-171_R2_3.5.2 NIST SP 800-171 R2 3.5.2 Identification and Authentication Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. Shared Microsoft and the customer share responsibilities for implementing this requirement. Individual authenticators include the following: passwords, key cards, cryptographic devices, and one-time password devices. Initial authenticator content is the actual content of the authenticator, for example, the initial password. In contrast, the requirements about authenticator content include the minimum password length. Developers ship system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk. Systems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics including minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include certificates and passwords. [SP 800-63-3] provides guidance on digital identities. link 24
NIST_SP_800-53_R4 AC-3 NIST_SP_800-53_R4_AC-3 NIST SP 800-53 Rev. 4 AC-3 Access Control Access Enforcement Shared n/a The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3. References: None. link 21
NIST_SP_800-53_R4 IA-5 NIST_SP_800-53_R4_IA-5 NIST SP 800-53 Rev. 4 IA-5 Identification And Authentication Authenticator Management Shared n/a The organization manages information system authenticators by: a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator; b. Establishing initial authenticator content for authenticators defined by the organization; c. Ensuring that authenticators have sufficient strength of mechanism for their intended use; d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost/compromised or damaged authenticators, and for revoking authenticators; e. Changing default content of authenticators prior to information system installation; f. Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators; g. Changing/refreshing authenticators [Assignment: organization-defined time period by authenticator type]; h. Protecting authenticator content from unauthorized disclosure and modification; i. Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators; and j. Changing authenticators for group/role accounts when membership to those accounts changes. Supplemental Guidance: Individual authenticators include, for example, passwords, tokens, biometrics, PKI certificates, and key cards. Initial authenticator content is the actual content (e.g., the initial password) as opposed to requirements about authenticator content (e.g., minimum password length). In many cases, developers ship information system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk. The requirement to protect individual authenticators may be implemented via control PL-4 or PS-6 for authenticators in the possession of individuals and by controls AC-3, AC-6, and SC-28 for authenticators stored within organizational information systems (e.g., passwords stored in hashed or encrypted formats, files containing encrypted or hashed passwords accessible with administrator privileges). Information systems support individual authenticator management by organization-defined settings and restrictions for various authenticator characteristics including, for example, minimum password length, password composition, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Specific actions that can be taken to safeguard authenticators include, for example, maintaining possession of individual authenticators, not loaning or sharing individual authenticators with others, and reporting lost, stolen, or compromised authenticators immediately. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include, for example, certificates and passwords. Related controls: AC-2, AC-3, AC-6, CM-6, IA-2, IA-4, IA-8, PL-4, PS-5, PS-6, SC-12, SC-13, SC-17, SC-28. References: OMB Memoranda 04-04, 11-11; FIPS Publication 201; NIST Special Publications 800-73, 800-63, 800-76, 800-78; FICAM Roadmap and Implementation Guidance link 18
NIST_SP_800-53_R5 AC-3 NIST_SP_800-53_R5_AC-3 NIST SP 800-53 Rev. 5 AC-3 Access Control Access Enforcement Shared n/a Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. link 21
NIST_SP_800-53_R5 IA-5 NIST_SP_800-53_R5_IA-5 NIST SP 800-53 Rev. 5 IA-5 Identification and Authentication Authenticator Management Shared n/a Manage system authenticators by: a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, service, or device receiving the authenticator; b. Establishing initial authenticator content for any authenticators issued by the organization; c. Ensuring that authenticators have sufficient strength of mechanism for their intended use; d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost or compromised or damaged authenticators, and for revoking authenticators; e. Changing default authenticators prior to first use; f. Changing or refreshing authenticators [Assignment: organization-defined time period by authenticator type] or when [Assignment: organization-defined events] occur; g. Protecting authenticator content from unauthorized disclosure and modification; h. Requiring individuals to take, and having devices implement, specific controls to protect authenticators; and i. Changing authenticators for group or role accounts when membership to those accounts changes. link 18
NZ_ISM_v3.5 CR-10 NZ_ISM_v3.5_CR-10 NZISM Security Benchmark CR-10 Cryptography 17.5.7 Authentication mechanisms Customer n/a Public key-based systems have greater potential for strong authentication, put simply, people are not able to remember particularly strong passwords. Password-based authentication schemes are also more susceptible to interception than public key-based authentication schemes. link 1
NZISM_Security_Benchmark_v1.1 CR-9 NZISM_Security_Benchmark_v1.1_CR-9 NZISM Security Benchmark CR-9 Cryptography 17.5.7 Authentication mechanisms Customer Agencies SHOULD use public key-based authentication before using password-based authentication. Public key-based systems have greater potential for strong authentication, put simply, people are not able to remember particularly strong passwords. Password-based authentication schemes are also more susceptible to interception than public key-based authentication schemes. link 1
RBI_CSF_Banks_v2016 13.4 RBI_CSF_Banks_v2016_13.4 Advanced Real-Timethreat Defenceand Management Advanced Real-Timethreat Defenceand Management-13.4 n/a Consider implementingsecure web gateways with capability to deep scan network packets including secure (HTTPS, etc.) traffic passing through the web/internet gateway 44
RBI_CSF_Banks_v2016 7.7 RBI_CSF_Banks_v2016_7.7 Patch/Vulnerability & Change Management Patch/Vulnerability & Change Management-7.7 n/a Periodically evaluate the access device configurations and patch levels to ensure that all access points, nodes between (i) different VLANs in the Data Centre (ii) LAN/WAN interfaces (iii) bank???s network to external network and interconnections with partner, vendor and service provider networks are to be securely configured. 25
RBI_CSF_Banks_v2016 9.1 RBI_CSF_Banks_v2016_9.1 Authentication Framework For Customers Authentication Framework For Customers-9.1 n/a Implement authentication framework/mechanism to provide positive identify verification of bank to customers. 4
RBI_CSF_Banks_v2016 9.3 RBI_CSF_Banks_v2016_9.3 Authentication Framework For Customers Authentication Framework For Customers-9.3 n/a Banks should act as the identity provider for identification and authentication of customers for access to partner systems using secure authentication technologies 7
SOC_2 CC6.1 SOC_2_CC6.1 SOC 2 Type 2 CC6.1 Logical and Physical Access Controls Logical access security software, infrastructure, and architectures Shared The customer is responsible for implementing this recommendation. The following points of focus, specifically related to all engagements using the trust services criteria, highlight important characteristics relating to this criterion: • Identifies and Manages the Inventory of Information Assets — The entity identifies, Page 29 TSP Ref. # TRUST SERVICES CRITERIA AND POINTS OF FOCUS inventories, classifies, and manages information assets. • Restricts Logical Access — Logical access to information assets, including hardware, data (at-rest, during processing, or in transmission), software, administrative authorities, mobile devices, output, and offline system components is restricted through the use of access control software and rule sets. • Identifies and Authenticates Users — Persons, infrastructure, and software are identified and authenticated prior to accessing information assets, whether locally or remotely. • Considers Network Segmentation — Network segmentation permits unrelated portions of the entity's information system to be isolated from each other. • Manages Points of Access — Points of access by outside entities and the types of data that flow through the points of access are identified, inventoried, and managed. The types of individuals and systems using each point of access are identified, documented, and managed. • Restricts Access to Information Assets — Combinations of data classification, separate data structures, port restrictions, access protocol restrictions, user identification, and digital certificates are used to establish access-control rules for information assets. • Manages Identification and Authentication — Identification and authentication requirements are established, documented, and managed for individuals and systems accessing entity information, infrastructure, and software. • Manages Credentials for Infrastructure and Software — New internal and external infrastructure and software are registered, authorized, and documented prior to being granted access credentials and implemented on the network or access point. Credentials are removed and access is disabled when access is no longer required or the infrastructure and software are no longer in use. • Uses Encryption to Protect Data — The entity uses encryption to supplement other measures used to protect data at rest, when such protections are deemed appropriate based on assessed risk. • Protects Encryption Keys — Processes are in place to protect encryption keys during generation, storage, use, and destruction 80
SOC_2 CC6.6 SOC_2_CC6.6 SOC 2 Type 2 CC6.6 Logical and Physical Access Controls Security measures against threats outside system boundaries Shared The customer is responsible for implementing this recommendation. • Restricts Access — The types of activities that can occur through a communication channel (for example, FTP site, router port) are restricted. • Protects Identification and Authentication Credentials — Identification and authentication credentials are protected during transmission outside its system boundaries. • Requires Additional Authentication or Credentials — Additional authentication information or credentials are required when accessing the system from outside its boundaries. • Implements Boundary Protection Systems — Boundary protection systems (for example, firewalls, demilitarized zones, and intrusion detection systems) are implemented to protect external access points from attempts and unauthorized access and are monitored to detect such attempts 41
SWIFT_CSCF_v2021 2.1 SWIFT_CSCF_v2021_2.1 SWIFT CSCF v2021 2.1 Reduce Attack Surface and Vulnerabilities Internal Data Flow Security n/a Ensure the confidentiality, integrity, and authenticity of application data flows between local SWIFT-related applications. link 14
SWIFT_CSCF_v2021 2.4A SWIFT_CSCF_v2021_2.4A SWIFT CSCF v2021 2.4A Reduce Attack Surface and Vulnerabilities Back-office Data Flow Security n/a Ensure the confidentiality, integrity, and mutual authenticity of data flows between local or remote SWIFT infrastructure components and the back office first hops they connect to. link 7
SWIFT_CSCF_v2022 2.1 SWIFT_CSCF_v2022_2.1 SWIFT CSCF v2022 2.1 2. Reduce Attack Surface and Vulnerabilities Ensure the confidentiality, integrity, and authenticity of application data flows between local SWIFT-related components. Shared n/a Confidentiality, integrity, and authentication mechanisms are implemented to protect SWIFT-related component-to-component or system-to-system data flows. link 36
SWIFT_CSCF_v2022 2.4A SWIFT_CSCF_v2022_2.4A SWIFT CSCF v2022 2.4A 2. Reduce Attack Surface and Vulnerabilities Back-office Data Flow Security Customer n/a Ensure the confidentiality, integrity, and mutual authenticity of data flows between local or remote SWIFT infrastructure components and the back office first hops they connect to. link 3
History
Date/Time (UTC ymd) (i) Change type Change detail
2022-01-28 17:51:01 change Major (2.2.0 > 3.0.0)
2021-12-06 22:17:57 change Minor (2.1.0 > 2.2.0)
2021-10-04 15:27:15 change Minor (2.0.1 > 2.1.0)
2021-01-22 09:14:53 change Patch (2.0.0 > 2.0.1) *changes on text case sensitivity are not tracked
2020-09-16 13:09:49 change Previous DisplayName: Audit Linux virtual machines on which the use of passwords for SSH is allowed
2020-09-15 14:06:41 change Previous DisplayName: [Preview]: Audit Linux virtual machines on which the use of passwords for SSH is allowed
2020-06-09 16:25:53 add 630c64f9-8b6b-4c64-b511-6544ceff6fd6
Initiatives
usage
Initiative DisplayName Initiative Id Initiative Category State Type
[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
[Preview]: SWIFT CSP-CSCF v2021 abf84fac-f817-a70c-14b5-47eec767458a Regulatory Compliance Preview BuiltIn
Azure Security Benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn
New Zealand ISM Restricted d1a462af-7e6d-4901-98ac-61570b4ed22a Regulatory Compliance GA BuiltIn
New Zealand ISM Restricted v3.5 93d2179e-3068-c82f-2428-d614ae836a04 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
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn
SWIFT CSP-CSCF v2022 7bc7cd6c-4114-ff31-3cac-59be3157596d Regulatory Compliance GA BuiltIn
JSON
changes

JSON