| Compliance |
The following 14 compliance controls are associated with this Policy definition 'Key Vault secrets should have an expiration date' (98728c90-32c7-4049-8429-847dc0f4fe37)
| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
| Azure_Security_Benchmark_v3.0 |
DP-6 |
Azure_Security_Benchmark_v3.0_DP-6 |
Azure Security Benchmark DP-6 |
Data Protection |
Use a secure key management process |
Shared |
**Security Principle:**
Document and implement an enterprise cryptographic key management standard, processes, and procedures to control your key lifecycle. When there is a need to use customer-managed key in the services, use a secured key vault service for key generation, distribution, and storage. Rotate and revoke your keys based on the defined schedule and when there is a key retirement or compromise.
**Azure Guidance:**
Use Azure Key Vault to create and control your encryption keys life cycle, including key generation, distribution, and storage. Rotate and revoke your keys in Azure Key Vault and your service based on the defined schedule and when there is a key retirement or compromise.
When there is a need to use customer-managed key (CMK) in the workload services or applications, ensure you follow the best practices:
- Use a key hierarchy to generate a separate data encryption key (DEK) with your key encryption key (KEK) in your key vault.
- Ensure keys are registered with Azure Key Vault and implement via key IDs in each service or application.
If you need to bring your own key (BYOK) to the services (i.e., importing HSM-protected keys from your on-premises HSMs into Azure Key Vault), follow the recommended guideline to perform the key generation and key transfer.
Note: Refer to the below for the FIPS 140-2 level for Azure Key Vault types and FIPS compliance level.
- Software-protected keys in vaults (Premium & Standard SKUs): FIPS 140-2 Level 1
- HSM-protected keys in vaults (Premium SKU): FIPS 140-2 Level 2
- HSM-protected keys in Managed HSM: FIPS 140-2 Level 3
**Implementation and additional context:**
Azure Key Vault overview:
https://docs.microsoft.com/azure/key-vault/general/overview
Azure data encryption at rest--Key Hierarchy:
https://docs.microsoft.com/azure/security/fundamentals/encryption-atrest#key-hierarchy
BYOK(Bring Your Own Key) specification:
https://docs.microsoft.com/azure/key-vault/keys/byok-specification |
n/a |
link |
2 |
| 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 |
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.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 |
| 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 |
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 |
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 |
.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 |
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 |
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-15 |
NZ_ISM_v3.5_CR-15 |
NZISM Security Benchmark CR-15 |
Cryptography |
17.9.25 Contents of KMPs |
Customer |
n/a |
When agencies implement the recommended contents for Key Management Plans (KMPs) they will have a good starting point for the protection of cryptographic systems and their material within their agencies. |
link |
4 |
| RBI_ITF_NBFC_v2017 |
3.1.h |
RBI_ITF_NBFC_v2017_3.1.h |
RBI IT Framework 3.1.h |
Information and Cyber Security |
Public Key Infrastructure (PKI)-3.1 |
|
n/a |
The IS Policy must provide for a IS framework with the following basic tenets:
Public Key Infrastructure (PKI) - NBFCs may increase the usage of PKI to ensure confidentiality of data, access control, data integrity, authentication and nonrepudiation. |
link |
32 |
| 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 |
|