compliance controls are associated with this Policy definition 'Define cryptographic use' (c4ccd607-702b-8ae6-8eeb-fc3339cd4b42)
| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
| CIS_Azure_1.1.0 |
3.2 |
CIS_Azure_1.1.0_3.2 |
CIS Microsoft Azure Foundations Benchmark recommendation 3.2 |
3 Storage Accounts |
Ensure that storage account access keys are periodically regenerated |
Shared |
The customer is responsible for implementing this recommendation. |
Regenerate storage account access keys periodically. |
link |
7 |
| CIS_Azure_1.1.0 |
8.1 |
CIS_Azure_1.1.0_8.1 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.1 |
8 Other Security Considerations |
Ensure that the expiration date is set on all keys |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that all keys in Azure Key Vault have an expiration time set. |
link |
8 |
| CIS_Azure_1.1.0 |
8.2 |
CIS_Azure_1.1.0_8.2 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.2 |
8 Other Security Considerations |
Ensure that the expiration date is set on all Secrets |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that all Secrets in the Azure Key Vault have an expiration time set. |
link |
8 |
| CIS_Azure_1.3.0 |
3.2 |
CIS_Azure_1.3.0_3.2 |
CIS Microsoft Azure Foundations Benchmark recommendation 3.2 |
3 Storage Accounts |
Ensure that storage account access keys are periodically regenerated |
Shared |
The customer is responsible for implementing this recommendation. |
Regenerate storage account access keys periodically. |
link |
7 |
| CIS_Azure_1.3.0 |
8.1 |
CIS_Azure_1.3.0_8.1 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.1 |
8 Other Security Considerations |
Ensure that the expiration date is set on all keys |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that all keys in Azure Key Vault have an expiration time set. |
link |
8 |
| CIS_Azure_1.3.0 |
8.2 |
CIS_Azure_1.3.0_8.2 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.2 |
8 Other Security Considerations |
Ensure that the expiration date is set on all Secrets |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that all Secrets in the Azure Key Vault have an expiration time set. |
link |
8 |
| CIS_Azure_1.3.0 |
9.11 |
CIS_Azure_1.3.0_9.11 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.11 |
9 AppService |
Ensure Azure Keyvaults are used to store secrets |
Shared |
The customer is responsible for implementing this recommendation. |
Encryption keys ,Certificate thumbprints and Managed Identity Credentials can be coded into the APP service, this renders them visible as part of the configuration, to maintain security of these keys it is better to store in an Azure Keyvault and reference them from the Keyvault. |
link |
9 |
| CIS_Azure_1.4.0 |
3.2 |
CIS_Azure_1.4.0_3.2 |
CIS Microsoft Azure Foundations Benchmark recommendation 3.2 |
3 Storage Accounts |
Ensure That Storage Account Access Keys are Periodically Regenerated |
Shared |
The customer is responsible for implementing this recommendation. |
Regenerate storage account access keys periodically. |
link |
7 |
| CIS_Azure_1.4.0 |
8.1 |
CIS_Azure_1.4.0_8.1 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.1 |
8 Other Security Considerations |
Ensure that the Expiration Date is set for all Keys in RBAC Key Vaults |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that all Keys in Role Based Access Control (RBAC) Azure Key Vaults have an expiration time set. |
link |
8 |
| CIS_Azure_1.4.0 |
8.2 |
CIS_Azure_1.4.0_8.2 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.2 |
8 Other Security Considerations |
Ensure that the Expiration Date is set for all Keys in Non-RBAC Key Vaults. |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that all Keys in Non Role Based Access Control (RBAC) Azure Key Vaults have an expiration time set. |
link |
8 |
| CIS_Azure_1.4.0 |
8.3 |
CIS_Azure_1.4.0_8.3 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.3 |
8 Other Security Considerations |
Ensure that the Expiration Date is set for all Secrets in RBAC Key Vaults |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that all Secrets in Role Based Access Control (RBAC) Azure Key Vaults have an expiration time set. |
link |
8 |
| CIS_Azure_1.4.0 |
8.4 |
CIS_Azure_1.4.0_8.4 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.4 |
8 Other Security Considerations |
Ensure that the Expiration Date is set for all Secrets in Non-RBAC Key Vaults |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that all Secrets in Non Role Based Access Control (RBAC) Azure Key Vaults have an expiration time set. |
link |
8 |
| CIS_Azure_1.4.0 |
9.11 |
CIS_Azure_1.4.0_9.11 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.11 |
9 AppService |
Ensure Azure Keyvaults are Used to Store Secrets |
Shared |
The customer is responsible for implementing this recommendation. |
Encryption keys ,Certificate thumbprints and Managed Identity Credentials can be coded into the APP service, this renders them visible as part of the configuration, to maintain security of these keys it is better to store in an Azure Keyvault and reference them from the Keyvault. |
link |
9 |
| CIS_Azure_2.0.0 |
3.4 |
CIS_Azure_2.0.0_3.4 |
CIS Microsoft Azure Foundations Benchmark recommendation 3.4 |
3 |
Ensure that Storage Account Access Keys are Periodically Regenerated |
Shared |
Regenerating access keys can affect services in Azure as well as the organization's applications that are dependent on the storage account. All clients who use the access key to access the storage account must be updated to use the new key. |
For increased security, regenerate storage account access keys periodically.
When a storage account is created, Azure generates two 512-bit storage access keys which are used for authentication when the storage account is accessed. Rotating these keys periodically ensures that any inadvertent access or exposure does not result from the compromise of these keys.
Cryptographic key rotation periods will vary depending on your organization's security requirements and the type of data which is being stored in the Storage Account. For example, PCI DSS mandates that cryptographic keys be replaced or rotated 'regularly,' and advises that keys for static data stores be rotated every 'few months.'
For the purposes of this recommendation, 90 days will prescribed for the reminder. Review and adjustment of the 90 day period is recommended, and may even be necessary. Your organization's security requirements should dictate the appropriate setting. |
link |
7 |
| CIS_Azure_2.0.0 |
8.1 |
CIS_Azure_2.0.0_8.1 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.1 |
8 |
Ensure that the Expiration Date is set for all Keys in RBAC Key Vaults |
Shared |
Keys cannot be used beyond their assigned expiration dates respectively. Keys need to be rotated periodically wherever they are used. |
Ensure that all Keys in Role Based Access Control (RBAC) Azure Key Vaults have an expiration date set.
Azure Key Vault enables users to store and use cryptographic keys within the Microsoft Azure environment. The `exp` (expiration date) attribute identifies the expiration date on or after which the key MUST NOT be used for encryption of new data, wrapping of new keys, and signing. By default, keys never expire. It is thus recommended that keys be rotated in the key vault and set an explicit expiration date for all keys to help enforce the key rotation. This ensures that the keys cannot be used beyond their assigned lifetimes. |
link |
8 |
| CIS_Azure_2.0.0 |
8.2 |
CIS_Azure_2.0.0_8.2 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.2 |
8 |
Ensure that the Expiration Date is set for all Keys in Non-RBAC Key Vaults. |
Shared |
Keys cannot be used beyond their assigned expiration dates respectively. Keys need to be rotated periodically wherever they are used. |
Ensure that all Keys in Non Role Based Access Control (RBAC) Azure Key Vaults have an expiration date set.
Azure Key Vault enables users to store and use cryptographic keys within the Microsoft Azure environment. The `exp` (expiration date) attribute identifies the expiration date on or after which the key MUST NOT be used for a cryptographic operation. By default, keys never expire. It is thus recommended that keys be rotated in the key vault and set an explicit expiration date for all keys. This ensures that the keys cannot be used beyond their assigned lifetimes. |
link |
8 |
| CIS_Azure_2.0.0 |
8.3 |
CIS_Azure_2.0.0_8.3 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.3 |
8 |
Ensure that the Expiration Date is set for all Secrets in RBAC Key Vaults |
Shared |
Secrets cannot be used beyond their assigned expiry date respectively. Secrets need to be rotated periodically wherever they are used. |
Ensure that all Secrets in Role Based Access Control (RBAC) Azure Key Vaults have an expiration date set.
The Azure Key Vault enables users to store and keep secrets within the Microsoft Azure environment. Secrets in the Azure Key Vault are octet sequences with a maximum size of 25k bytes each. The `exp` (expiration date) attribute identifies the expiration date on or after which the secret MUST NOT be used. By default, secrets never expire. It is thus recommended to rotate secrets in the key vault and set an explicit expiration date for all secrets. This ensures that the secrets cannot be used beyond their assigned lifetimes. |
link |
8 |
| CIS_Azure_2.0.0 |
8.4 |
CIS_Azure_2.0.0_8.4 |
CIS Microsoft Azure Foundations Benchmark recommendation 8.4 |
8 |
Ensure that the Expiration Date is set for all Secrets in Non-RBAC Key Vaults |
Shared |
Secrets cannot be used beyond their assigned expiry date respectively. Secrets need to be rotated periodically wherever they are used. |
Ensure that all Secrets in Non Role Based Access Control (RBAC) Azure Key Vaults have an expiration date set.
The Azure Key Vault enables users to store and keep secrets within the Microsoft Azure environment. Secrets in the Azure Key Vault are octet sequences with a maximum size of 25k bytes each. The `exp` (expiration date) attribute identifies the expiration date on or after which the secret MUST NOT be used. By default, secrets never expire. It is thus recommended to rotate secrets in the key vault and set an explicit expiration date for all secrets. This ensures that the secrets cannot be used beyond their assigned lifetimes. |
link |
8 |
| CIS_Azure_2.0.0 |
9.11 |
CIS_Azure_2.0.0_9.11 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.11 |
9 |
Ensure Azure Key Vaults are Used to Store Secrets |
Shared |
Integrating references to secrets within the key vault are required to be specifically integrated within the application code. This will require additional configuration to be made during the writing of an application, or refactoring of an already written one. There are also additional costs that are charged per 10000 requests to the Key Vault. |
Azure Key Vault will store multiple types of sensitive information such as encryption keys, certificate thumbprints, and Managed Identity Credentials. Access to these 'Secrets' can be controlled through granular permissions.
The credentials given to an application have permissions to create, delete, or modify data stored within the systems they access. If these credentials are stored within the application itself, anyone with access to the application or a copy of the code has access to them. Storing within Azure Key Vault as secrets increases security by controlling access. This also allows for updates of the credentials without redeploying the entire application. |
link |
9 |
| FedRAMP_High_R4 |
SC-12 |
FedRAMP_High_R4_SC-12 |
FedRAMP High SC-12 |
System And Communications Protection |
Cryptographic Key Establishment And Management |
Shared |
n/a |
The organization establishes and manages cryptographic keys for required cryptography employed within the information system in accordance with [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction].
Supplemental Guidance: Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Organizations define key management requirements in accordance with applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance, specifying appropriate options, levels, and parameters. Organizations manage trust stores to ensure that only approved trust anchors are in such trust stores. This includes certificates with visibility external to organizational information systems and certificates related to the internal operations of systems. Related controls: SC-13, SC-17.
References: NIST Special Publications 800-56, 800-57. |
link |
40 |
| FedRAMP_High_R4 |
SC-13 |
FedRAMP_High_R4_SC-13 |
FedRAMP High SC-13 |
System And Communications Protection |
Cryptographic Protection |
Shared |
n/a |
The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.
Supplemental Guidance: Cryptography can be employed to support a variety of security solutions including, for example, the protection of classified and Controlled Unclassified Information, the provision of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances for such information but lack the necessary formal access approvals. Cryptography can also be used to support random number generation and hash generation. Generally applicable cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography. This control does not impose any requirements on organizations to use cryptography. However, if cryptography is required based on the selection of other security controls, organizations define each type of cryptographic use and the type of cryptography required (e.g., protection of classified information: NSA-approved cryptography; provision of digital signatures: FIPS-validated cryptography). Related controls: AC-2, AC-3, AC-7, AC-17, AC-18, AU-9, AU-10, CM-11, CP-9, IA-3, IA-7, MA-4, MP-2, MP-4, MP-5, SA-4, SC-8, SC-12, SC-28, SI-7.
References: FIPS Publication 140; Web: http://csrc.nist.gov/cryptval, http://www.cnss.gov. |
link |
1 |
| FedRAMP_Moderate_R4 |
SC-12 |
FedRAMP_Moderate_R4_SC-12 |
FedRAMP Moderate SC-12 |
System And Communications Protection |
Cryptographic Key Establishment And Management |
Shared |
n/a |
The organization establishes and manages cryptographic keys for required cryptography employed within the information system in accordance with [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction].
Supplemental Guidance: Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Organizations define key management requirements in accordance with applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance, specifying appropriate options, levels, and parameters. Organizations manage trust stores to ensure that only approved trust anchors are in such trust stores. This includes certificates with visibility external to organizational information systems and certificates related to the internal operations of systems. Related controls: SC-13, SC-17.
References: NIST Special Publications 800-56, 800-57. |
link |
40 |
| FedRAMP_Moderate_R4 |
SC-13 |
FedRAMP_Moderate_R4_SC-13 |
FedRAMP Moderate SC-13 |
System And Communications Protection |
Cryptographic Protection |
Shared |
n/a |
The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.
Supplemental Guidance: Cryptography can be employed to support a variety of security solutions including, for example, the protection of classified and Controlled Unclassified Information, the provision of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances for such information but lack the necessary formal access approvals. Cryptography can also be used to support random number generation and hash generation. Generally applicable cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography. This control does not impose any requirements on organizations to use cryptography. However, if cryptography is required based on the selection of other security controls, organizations define each type of cryptographic use and the type of cryptography required (e.g., protection of classified information: NSA-approved cryptography; provision of digital signatures: FIPS-validated cryptography). Related controls: AC-2, AC-3, AC-7, AC-17, AC-18, AU-9, AU-10, CM-11, CP-9, IA-3, IA-7, MA-4, MP-2, MP-4, MP-5, SA-4, SC-8, SC-12, SC-28, SI-7.
References: FIPS Publication 140; Web: http://csrc.nist.gov/cryptval, http://www.cnss.gov. |
link |
1 |
| hipaa |
0314.09q3Organizational.2-09.q |
hipaa-0314.09q3Organizational.2-09.q |
0314.09q3Organizational.2-09.q |
03 Portable Media Security |
0314.09q3Organizational.2-09.q 09.07 Media Handling |
Shared |
n/a |
The organization implements cryptographic mechanisms to protect the confidentiality and integrity of sensitive (non-public) information stored on digital media during transport outside of controlled areas. |
|
9 |
| hipaa |
0810.01n2Organizational.5-01.n |
hipaa-0810.01n2Organizational.5-01.n |
0810.01n2Organizational.5-01.n |
08 Network Protection |
0810.01n2Organizational.5-01.n 01.04 Network Access Control |
Shared |
n/a |
Transmitted information is secured and, at a minimum, encrypted over open, public networks. |
|
17 |
| hipaa |
0903.10f1Organizational.1-10.f |
hipaa-0903.10f1Organizational.1-10.f |
0903.10f1Organizational.1-10.f |
09 Transmission Protection |
0903.10f1Organizational.1-10.f 10.03 Cryptographic Controls |
Shared |
n/a |
Encryption is used to protect covered information on mobile/removable media and across communication lines based on pre-determined criteria. |
|
3 |
| hipaa |
0904.10f2Organizational.1-10.f |
hipaa-0904.10f2Organizational.1-10.f |
0904.10f2Organizational.1-10.f |
09 Transmission Protection |
0904.10f2Organizational.1-10.f 10.03 Cryptographic Controls |
Shared |
n/a |
Key management is implemented based on specific roles and responsibilities, and in consideration of national and international regulations, restrictions, and issues. |
|
10 |
| hipaa |
0913.09s1Organizational.5-09.s |
hipaa-0913.09s1Organizational.5-09.s |
0913.09s1Organizational.5-09.s |
09 Transmission Protection |
0913.09s1Organizational.5-09.s 09.08 Exchange of Information |
Shared |
n/a |
Strong cryptography protocols are used to safeguard covered information during transmission over less trusted/open public networks. |
|
5 |
| hipaa |
0928.09v1Organizational.45-09.v |
hipaa-0928.09v1Organizational.45-09.v |
0928.09v1Organizational.45-09.v |
09 Transmission Protection |
0928.09v1Organizational.45-09.v 09.08 Exchange of Information |
Shared |
n/a |
Stronger controls are implemented to protect certain electronic messages, and electronic messages are protected throughout the duration of its end-to-end transport path, using cryptographic mechanisms unless protected by alternative measures. |
|
9 |
| hipaa |
0945.09y1Organizational.3-09.y |
hipaa-0945.09y1Organizational.3-09.y |
0945.09y1Organizational.3-09.y |
09 Transmission Protection |
0945.09y1Organizational.3-09.y 09.09 Electronic Commerce Services |
Shared |
n/a |
Protocols used to communicate between all involved parties are secured using cryptographic techniques (e.g., SSL). |
|
6 |
| hipaa |
099.09m2Organizational.11-09.m |
hipaa-099.09m2Organizational.11-09.m |
099.09m2Organizational.11-09.m |
09 Transmission Protection |
099.09m2Organizational.11-09.m 09.06 Network Security Management |
Shared |
n/a |
The organization uses FIPS-validated cryptographic mechanisms during transmission to prevent unauthorized disclosure of information and detect changes to information unless otherwise protected by organization-defined alternative physical measures. |
|
3 |
| hipaa |
1005.01d1System.1011-01.d |
hipaa-1005.01d1System.1011-01.d |
1005.01d1System.1011-01.d |
10 Password Management |
1005.01d1System.1011-01.d 01.02 Authorized Access to Information Systems |
Shared |
n/a |
The organization transmits passwords only when cryptographically-protected and stores passwords using an approved hash algorithm. |
|
6 |
| hipaa |
1007.01d2System.2-01.d |
hipaa-1007.01d2System.2-01.d |
1007.01d2System.2-01.d |
10 Password Management |
1007.01d2System.2-01.d 01.02 Authorized Access to Information Systems |
Shared |
n/a |
Passwords are encrypted during transmission and storage on all system components. |
|
1 |
| hipaa |
1903.06d1Organizational.3456711-06.d |
hipaa-1903.06d1Organizational.3456711-06.d |
1903.06d1Organizational.3456711-06.d |
19 Data Protection & Privacy |
1903.06d1Organizational.3456711-06.d 06.01 Compliance with Legal Requirements |
Shared |
n/a |
The confidentiality and integrity of covered information at rest is protected using an encryption method appropriate to the medium where it is stored; where the organization chooses not to encrypt covered information, a documented rationale for not doing so is maintained or alternative compensating controls are used if the method is approved and reviewed annually by the CISO. |
|
5 |
| ISO27001-2013 |
A.10.1.1 |
ISO27001-2013_A.10.1.1 |
ISO 27001:2013 A.10.1.1 |
Cryptography |
Policy on the use of cryptographic controls |
Shared |
n/a |
A policy on the use of cryptographic controls for protection of information shall be developed and implemented. |
link |
18 |
| ISO27001-2013 |
A.10.1.2 |
ISO27001-2013_A.10.1.2 |
ISO 27001:2013 A.10.1.2 |
Cryptography |
Key Management |
Shared |
n/a |
A policy on the use, protection and lifetime of cryptographic keys shall be developed and implemented through their whole lifecycle. |
link |
15 |
| ISO27001-2013 |
A.14.1.2 |
ISO27001-2013_A.14.1.2 |
ISO 27001:2013 A.14.1.2 |
System Acquisition, Development And Maintenance |
Securing application services on public networks |
Shared |
n/a |
Information involved in application services passing over public networks shall be protected from fraudulent activity, contract dispute and unauthorized disclosure and modification. |
link |
32 |
| ISO27001-2013 |
A.14.1.3 |
ISO27001-2013_A.14.1.3 |
ISO 27001:2013 A.14.1.3 |
System Acquisition, Development And Maintenance |
Protecting application services transactions |
Shared |
n/a |
Information involved in application service transactions shall be protected to prevent incomplete transmission, mis-routing, unauthorized message alteration, unauthorized disclosure, unauthorized message duplication or replay. |
link |
29 |
| ISO27001-2013 |
A.18.1.5 |
ISO27001-2013_A.18.1.5 |
ISO 27001:2013 A.18.1.5 |
Compliance |
Regulation of cryptographic controls |
Shared |
n/a |
Cryptographic controls shall be used in compliance with all relevant agreements, legislation and regulations. |
link |
2 |
| NIST_SP_800-171_R2_3 |
.13.10 |
NIST_SP_800-171_R2_3.13.10 |
NIST SP 800-171 R2 3.13.10 |
System and Communications Protection |
Establish and manage cryptographic keys for cryptography employed in organizational systems. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Cryptographic key management and establishment can be performed using manual procedures or mechanisms supported by manual procedures. Organizations define key management requirements in accordance with applicable federal laws, Executive Orders, policies, directives, regulations, and standards specifying appropriate options, levels, and parameters. [SP 800-56A] and [SP 800-57-1] provide guidance on cryptographic key management and key establishment. |
link |
40 |
| NIST_SP_800-171_R2_3 |
.13.11 |
NIST_SP_800-171_R2_3.13.11 |
NIST SP 800-171 R2 3.13.11 |
System and Communications Protection |
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Cryptography can be employed to support many security solutions including the protection of controlled unclassified information, the provision of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances for such information but lack the necessary formal access approvals. Cryptography can also be used to support random number generation and hash generation. Cryptographic standards include FIPS-validated cryptography and/or NSA-approved cryptography. See [NIST CRYPTO]; [NIST CAVP]; and [NIST CMVP]. |
link |
1 |
| NIST_SP_800-53_R4 |
SC-12 |
NIST_SP_800-53_R4_SC-12 |
NIST SP 800-53 Rev. 4 SC-12 |
System And Communications Protection |
Cryptographic Key Establishment And Management |
Shared |
n/a |
The organization establishes and manages cryptographic keys for required cryptography employed within the information system in accordance with [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction].
Supplemental Guidance: Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Organizations define key management requirements in accordance with applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance, specifying appropriate options, levels, and parameters. Organizations manage trust stores to ensure that only approved trust anchors are in such trust stores. This includes certificates with visibility external to organizational information systems and certificates related to the internal operations of systems. Related controls: SC-13, SC-17.
References: NIST Special Publications 800-56, 800-57. |
link |
40 |
| NIST_SP_800-53_R4 |
SC-13 |
NIST_SP_800-53_R4_SC-13 |
NIST SP 800-53 Rev. 4 SC-13 |
System And Communications Protection |
Cryptographic Protection |
Shared |
n/a |
The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.
Supplemental Guidance: Cryptography can be employed to support a variety of security solutions including, for example, the protection of classified and Controlled Unclassified Information, the provision of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances for such information but lack the necessary formal access approvals. Cryptography can also be used to support random number generation and hash generation. Generally applicable cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography. This control does not impose any requirements on organizations to use cryptography. However, if cryptography is required based on the selection of other security controls, organizations define each type of cryptographic use and the type of cryptography required (e.g., protection of classified information: NSA-approved cryptography; provision of digital signatures: FIPS-validated cryptography). Related controls: AC-2, AC-3, AC-7, AC-17, AC-18, AU-9, AU-10, CM-11, CP-9, IA-3, IA-7, MA-4, MP-2, MP-4, MP-5, SA-4, SC-8, SC-12, SC-28, SI-7.
References: FIPS Publication 140; Web: http://csrc.nist.gov/cryptval, http://www.cnss.gov. |
link |
1 |
| NIST_SP_800-53_R5 |
SC-12 |
NIST_SP_800-53_R5_SC-12 |
NIST SP 800-53 Rev. 5 SC-12 |
System and Communications Protection |
Cryptographic Key Establishment and Management |
Shared |
n/a |
Establish and manage cryptographic keys when cryptography is employed within the system in accordance with the following key management requirements: [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction]. |
link |
40 |
| NIST_SP_800-53_R5 |
SC-13 |
NIST_SP_800-53_R5_SC-13 |
NIST SP 800-53 Rev. 5 SC-13 |
System and Communications Protection |
Cryptographic Protection |
Shared |
n/a |
a. Determine the [Assignment: organization-defined cryptographic uses]; and
b. Implement the following types of cryptography required for each specified cryptographic use: [Assignment: organization-defined types of cryptography for each specified cryptographic use]. |
link |
1 |
| PCI_DSS_v4.0 |
3.6.1 |
PCI_DSS_v4.0_3.6.1 |
PCI DSS v4.0 3.6.1 |
Requirement 03: Protect Stored Account Data |
Cryptographic keys used to protect stored account data are secured |
Shared |
n/a |
Procedures are defined and implemented to protect cryptographic keys used to Protect Stored Account Data against disclosure and misuse that include:
• Access to keys is restricted to the fewest number of custodians necessary.
• Key-encrypting keys are at least as strong as the data-encrypting keys they protect.
• Key-encrypting keys are stored separately from data-encrypting keys.
• Keys are stored securely in the fewest possible locations and forms. |
link |
7 |
| PCI_DSS_v4.0 |
3.6.1.1 |
PCI_DSS_v4.0_3.6.1.1 |
PCI DSS v4.0 3.6.1.1 |
Requirement 03: Protect Stored Account Data |
Cryptographic keys used to protect stored account data are secured |
Shared |
n/a |
A documented description of the cryptographic architecture is maintained that includes:
• Details of all algorithms, protocols, and keys used for the protection of stored account data, including key strength and expiry date.
• Preventing the use of the same cryptographic keys in production and test environments. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
• Description of the key usage for each key.
• Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, as outlined in Requirement 12.3.4. |
link |
7 |
| PCI_DSS_v4.0 |
3.6.1.2 |
PCI_DSS_v4.0_3.6.1.2 |
PCI DSS v4.0 3.6.1.2 |
Requirement 03: Protect Stored Account Data |
Cryptographic keys used to protect stored account data are secured |
Shared |
n/a |
Secret and private keys used to encrypt/decrypt stored account data are stored in one (or more) of the following forms at all times:
• Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the dataencrypting key.
• Within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device.
• As at least two full-length key components or key shares, in accordance with an industry-accepted method. |
link |
8 |
| PCI_DSS_v4.0 |
3.6.1.3 |
PCI_DSS_v4.0_3.6.1.3 |
PCI DSS v4.0 3.6.1.3 |
Requirement 03: Protect Stored Account Data |
Cryptographic keys used to protect stored account data are secured |
Shared |
n/a |
Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary. |
link |
7 |
| PCI_DSS_v4.0 |
3.6.1.4 |
PCI_DSS_v4.0_3.6.1.4 |
PCI DSS v4.0 3.6.1.4 |
Requirement 03: Protect Stored Account Data |
Cryptographic keys used to protect stored account data are secured |
Shared |
n/a |
Cryptographic keys are stored in the fewest possible locations. |
link |
7 |
| PCI_DSS_v4.0 |
3.7.1 |
PCI_DSS_v4.0_3.7.1 |
PCI DSS v4.0 3.7.1 |
Requirement 03: Protect Stored Account Data |
Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented |
Shared |
n/a |
Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to Protect Stored Account Data. |
link |
7 |
| PCI_DSS_v4.0 |
3.7.2 |
PCI_DSS_v4.0_3.7.2 |
PCI DSS v4.0 3.7.2 |
Requirement 03: Protect Stored Account Data |
Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented |
Shared |
n/a |
Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to Protect Stored Account Data. |
link |
8 |
| PCI_DSS_v4.0 |
3.7.3 |
PCI_DSS_v4.0_3.7.3 |
PCI DSS v4.0 3.7.3 |
Requirement 03: Protect Stored Account Data |
Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented |
Shared |
n/a |
Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to Protect Stored Account Data. |
link |
9 |
| PCI_DSS_v4.0 |
3.7.4 |
PCI_DSS_v4.0_3.7.4 |
PCI DSS v4.0 3.7.4 |
Requirement 03: Protect Stored Account Data |
Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented |
Shared |
n/a |
Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated application vendor or key owner, and based on industry best practices and guidelines, including the following:
• A defined cryptoperiod for each key type in use.
• A process for key changes at the end of the defined cryptoperiod. |
link |
7 |
| PCI_DSS_v4.0 |
3.7.5 |
PCI_DSS_v4.0_3.7.5 |
PCI DSS v4.0 3.7.5 |
Requirement 03: Protect Stored Account Data |
Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented |
Shared |
n/a |
Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to Protect Stored Account Data, as deemed necessary when:
• The key has reached the end of its defined cryptoperiod.
• The integrity of the key has been weakened, including when personnel with knowledge of a cleartext key component leaves the company, or the role for which the key component was known.
• When keys are suspected of or known to be compromised.
• Retired or replaced keys are not used for encryption operations. |
link |
7 |
| PCI_DSS_v4.0 |
3.7.6 |
PCI_DSS_v4.0_3.7.6 |
PCI DSS v4.0 3.7.6 |
Requirement 03: Protect Stored Account Data |
Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented |
Shared |
n/a |
Where manual cleartext cryptographic keymanagement operations are performed by personnel, key-management policies and procedures are implemented include managing these operations using split knowledge and dual control. |
link |
7 |
| PCI_DSS_v4.0 |
3.7.7 |
PCI_DSS_v4.0_3.7.7 |
PCI DSS v4.0 3.7.7 |
Requirement 03: Protect Stored Account Data |
Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented |
Shared |
n/a |
Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys. |
link |
7 |
| PCI_DSS_v4.0 |
3.7.8 |
PCI_DSS_v4.0_3.7.8 |
PCI DSS v4.0 3.7.8 |
Requirement 03: Protect Stored Account Data |
Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented |
Shared |
n/a |
Key management policies and procedures are implemented to include that cryptographic key custodians formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities. |
link |
7 |
| PCI_DSS_v4.0 |
3.7.9 |
PCI_DSS_v4.0_3.7.9 |
PCI DSS v4.0 3.7.9 |
Requirement 03: Protect Stored Account Data |
Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented |
Shared |
n/a |
Where a service provider shares cryptographic keys with its customers for transmission or storage of account data, guidance on secure transmission, storage and updating of such keys is documented and distributed to the service providers' customers. |
link |
7 |
| PCI_DSS_v4.0 |
4.2.1 |
PCI_DSS_v4.0_4.2.1 |
PCI DSS v4.0 4.2.1 |
Requirement 04: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks |
PAN is protected with strong cryptography during transmission |
Shared |
n/a |
Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:
• Only trusted keys and certificates are accepted.
• Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. This bullet is a best practice until its effective date; refer to applicability notes below for details.
• The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations.
• The encryption strength is appropriate for the encryption methodology in use. |
link |
12 |
| PCI_DSS_v4.0 |
4.2.1.1 |
PCI_DSS_v4.0_4.2.1.1 |
PCI DSS v4.0 4.2.1.1 |
Requirement 04: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks |
PAN is protected with strong cryptography during transmission |
Shared |
n/a |
An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained. |
link |
8 |
| 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 |
| SWIFT_CSCF_v2022 |
1.4 |
SWIFT_CSCF_v2022_1.4 |
SWIFT CSCF v2022 1.4 |
1. Restrict Internet Access & Protect Critical Systems from General IT Environment |
Control/Protect Internet access from operator PCs and systems within the secure zone. |
Shared |
n/a |
All general-purpose and dedicated operator PCs, as well as systems within the secure zone, have controlled direct internet access in line with business. |
link |
11 |
| 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 |