Az Policy Advertizer

Canada_Federal_PBMM_3-1-2020

CM_8

Canada_Federal_PBMM_3-1-2020_CM_8

Canada Federal PBMM 3-1-2020 CM 8

Information System Component Inventory

Shared

1. The organization develops and documents an inventory of information system components that accurately reflects the current information system. 2. The organization develops and documents an inventory of information system components that includes all components within the authorization boundary of the information system. 3. The organization develops and documents an inventory of information system components that is at the level of granularity deemed necessary for tracking and reporting. 4. The organization develops and documents an inventory of information system components that includes unique asset identifier, NetBIOS name, baseline configuration name, OS Name, OS Version, system owner information. 5. The organization reviews and updates the information system component inventory at least monthly.

To enable efficient decision-making and risk mitigation strategies.

Canada_Federal_PBMM_3-1-2020

CM_8(1)

Canada_Federal_PBMM_3-1-2020_CM_8(1)

Canada Federal PBMM 3-1-2020 CM 8(1)

Information System Component Inventory

Information System Component Inventory | Updates During Installations / Removals

Shared

The organization updates the inventory of information system components as an integral part of component installations, removals, and information system updates.

To facilitate accurate asset management and effective security control implementation.

Canada_Federal_PBMM_3-1-2020

CM_8(2)

Canada_Federal_PBMM_3-1-2020_CM_8(2)

Canada Federal PBMM 3-1-2020 CM 8(2)

Information System Component Inventory

Information System Component Inventory | Automated Maintenance

Shared

The organization employs automated mechanisms to help maintain an up-to-date, complete, accurate, and readily available inventory of information system components.

To facilitate accurate asset management and effective security control implementation.

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.

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.

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.

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.

CIS_Azure_2.0.0

8.3

CIS_Azure_2.0.0_8.3

CIS Microsoft Azure Foundations Benchmark recommendation 8.3

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.

CIS_Azure_2.0.0

8.4

CIS_Azure_2.0.0_8.4

CIS Microsoft Azure Foundations Benchmark recommendation 8.4

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.

CIS_Azure_Foundations_v2.1.0

8.3

CIS_Azure_Foundations_v2.1.0_8.3

CIS Azure Foundations v2.1.0 8.3

Key Vault

Ensure that the Expiration Date is set for all Secrets in RBAC Key Vaults

Shared

n/a

Ensure that the Expiration Date is set for all Secrets in RBAC Key Vaults.

CIS_Azure_Foundations_v2.1.0

8.4

CIS_Azure_Foundations_v2.1.0_8.4

CIS Azure Foundations v2.1.0 8.4

Key Vault

Ensure that the Expiration Date is set for all Secrets in Non-RBAC Key Vaults

Shared

n/a

Ensure that the Expiration Date is set for all Secrets in Non-RBAC Key Vaults.

CIS_Controls_v8.1

3.1

CIS_Controls_v8.1_3.1

CIS Controls v8.1 3.1

Data Protection

Establish and maintain a data management process

Shared

1. Establish and maintain a data management process. 2. In the process, address data sensitivity, data owner, handling of data, data retention limits, and disposal requirements, based on sensitivity and retention standards for the enterprise. 3. Review and update documentation annually, or when significant enterprise changes occur that could impact this safeguard.

To ensure proper handling, protection, and disposal of data.

CIS_Controls_v8.1

4.1

CIS_Controls_v8.1_4.1

CIS Controls v8.1 4.1

Secure Configuration of Enterprise Assets and Software

Establish and maintain a secure configuration process.

Shared

1. Establish and maintain a secure configuration process for enterprise assets (end-user devices, including portable and mobile; non-computing/IoT devices; and servers) and software (operating systems and applications). 2. Review and update documentation annually, or when significant enterprise changes occur that could impact this safeguard.

To ensure data integrity and safety of enterprise assets.

CIS_Controls_v8.1

6.2

CIS_Controls_v8.1_6.2

CIS Controls v8.1 6.2

Access Control Management

Establish an access revoking process

Shared

1. Establish and follow a process, preferably automated, for revoking access to enterprise assets, through disabling accounts immediately upon termination, rights revocation, or role change of a user. 2. Disabling accounts, instead of deleting accounts, may be necessary to preserve audit trails.

To restrict access to enterprise assets.

CMMC_2.0_L2

IA.L1-3.5.2

CMMC_2.0_L2_IA.L1-3.5.2

404 not found

n/a

CMMC_L2_v1.9.0

IA.L1_3.5.1

CMMC_L2_v1.9.0_IA.L1_3.5.1

Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 IA.L1 3.5.1

Identification and Authentication

Identification

Shared

Identify information system users, processes acting on behalf of users, or devices.

To enable effective monitoring, authentication, and access control measures to be implemented within the system.

CMMC_L2_v1.9.0

SC.L2_3.13.10

CMMC_L2_v1.9.0_SC.L2_3.13.10

Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 SC.L2 3.13.10

System and Communications Protection

Key Management

Shared

Establish and manage cryptographic keys for cryptography employed in organizational systems.

To protect information assets from unauthorized access, manipulation, or disclosure.

CCC_03

CSA_v4.0.12_CCC_03

CSA Cloud Controls Matrix v4.0.12 CCC 03

Change Control and Configuration Management

Change Management Technology

Shared

n/a

Manage the risks associated with applying changes to organization assets, including application, systems, infrastructure, configuration, etc., regardless of whether the assets are managed internally or externally (i.e., outsourced).

CEK_01

CSA_v4.0.12_CEK_01

CSA Cloud Controls Matrix v4.0.12 CEK 01

Cryptography, Encryption & Key Management

Encryption and Key Management Policy and Procedures

Shared

n/a

Establish, document, approve, communicate, apply, evaluate and maintain policies and procedures for Cryptography, Encryption and Key Management. Review and update the policies and procedures at least annually.

CEK_02

CSA_v4.0.12_CEK_02

CSA Cloud Controls Matrix v4.0.12 CEK 02

Cryptography, Encryption & Key Management

CEK Roles and Responsibilities

Shared

n/a

Define and implement cryptographic, encryption and key management roles and responsibilities.

CEK_03

CSA_v4.0.12_CEK_03

CSA Cloud Controls Matrix v4.0.12 CEK 03

Cryptography, Encryption & Key Management

Data Encryption

Shared

n/a

Provide cryptographic protection to data at-rest and in-transit, using cryptographic libraries certified to approved standards.

CEK_04

CSA_v4.0.12_CEK_04

CSA Cloud Controls Matrix v4.0.12 CEK 04

Cryptography, Encryption & Key Management

Encryption Algorithm

Shared

n/a

Use encryption algorithms that are appropriate for data protection, considering the classification of data, associated risks, and usability of the encryption technology.

CEK_05

CSA_v4.0.12_CEK_05

CSA Cloud Controls Matrix v4.0.12 CEK 05

Cryptography, Encryption & Key Management

Encryption Change Management

Shared

n/a

Establish a standard change management procedure, to accommodate changes from internal and external sources, for review, approval, implementation and communication of cryptographic, encryption and key management technology changes.

CEK_10

CSA_v4.0.12_CEK_10

CSA Cloud Controls Matrix v4.0.12 CEK 10

Cryptography, Encryption & Key Management

Key Generation

Shared

n/a

Generate Cryptographic keys using industry accepted cryptographic libraries specifying the algorithm strength and the random number generator used.

CEK_11

CSA_v4.0.12_CEK_11

CSA Cloud Controls Matrix v4.0.12 CEK 11

Cryptography, Encryption & Key Management

Key Purpose

Shared

n/a

Manage cryptographic secret and private keys that are provisioned for a unique purpose.

CEK_12

CSA_v4.0.12_CEK_12

CSA Cloud Controls Matrix v4.0.12 CEK 12

Cryptography, Encryption & Key Management

Key Rotation

Shared

n/a

Rotate cryptographic keys in accordance with the calculated cryptoperiod, which includes provisions for considering the risk of information disclosure and legal and regulatory requirements.

CEK_13

CSA_v4.0.12_CEK_13

CSA Cloud Controls Matrix v4.0.12 CEK 13

Cryptography, Encryption & Key Management

Key Revocation

Shared

n/a

Define, implement and evaluate processes, procedures and technical measures to revoke and remove cryptographic keys prior to the end of its established cryptoperiod, when a key is compromised, or an entity is no longer part of the organization, which include provisions for legal and regulatory requirements.

CEK_14

CSA_v4.0.12_CEK_14

CSA Cloud Controls Matrix v4.0.12 CEK 14

Cryptography, Encryption & Key Management

Key Destruction

Shared

n/a

Define, implement and evaluate processes, procedures and technical measures to destroy keys stored outside a secure environment and revoke keys stored in Hardware Security Modules (HSMs) when they are no longer needed, which include provisions for legal and regulatory requirements.

CEK_20

CSA_v4.0.12_CEK_20

CSA Cloud Controls Matrix v4.0.12 CEK 20

Cryptography, Encryption & Key Management

Key Recovery

Shared

n/a

Define, implement and evaluate processes, procedures and technical measures to assess the risk to operational continuity versus the risk of the keying material and the information it protects being exposed if control of the keying material is lost, which include provisions for legal and regulatory requirements.

IAM_02

CSA_v4.0.12_IAM_02

CSA Cloud Controls Matrix v4.0.12 IAM 02

Identity & Access Management

Strong Password Policy and Procedures

Shared

n/a

Establish, document, approve, communicate, implement, apply, evaluate and maintain strong password policies and procedures. Review and update the policies and procedures at least annually.

IAM_11

CSA_v4.0.12_IAM_11

CSA Cloud Controls Matrix v4.0.12 IAM 11

Identity & Access Management

CSCs Approval for Agreed Privileged Access Roles

Shared

n/a

Define, implement and evaluate processes and procedures for customers to participate, where applicable, in the granting of access for agreed, high risk (as defined by the organizational risk assessment) privileged access roles.

IAM_13

CSA_v4.0.12_IAM_13

CSA Cloud Controls Matrix v4.0.12 IAM 13

Identity & Access Management

Uniquely Identifiable Users

Shared

n/a

Define, implement and evaluate processes, procedures and technical measures that ensure users are identifiable through unique IDs or which can associate individuals to the usage of user IDs.

IAM_14

CSA_v4.0.12_IAM_14

CSA Cloud Controls Matrix v4.0.12 IAM 14

Identity & Access Management

Strong Authentication

Shared

n/a

Define, implement and evaluate processes, procedures and technical measures for authenticating access to systems, application and data assets, including multifactor authentication for at least privileged user and sensitive data access. Adopt digital certificates or alternatives which achieve an equivalent level of security for system identities.

Cyber_Essentials_v3.1

Cyber_Essentials_v3.1_4

Cyber Essentials v3.1 4

Cyber Essentials

User Access Control

Shared

n/a

Aim: ensure that user accounts (1) are assigned to authorised individuals only, and (2) provide access to only those applications, computers and networks the user needs to carry out their role.

EU_2555_(NIS2)_2022

EU_2555_(NIS2)_2022_21

EU 2022/2555 (NIS2) 2022 21

Cybersecurity risk-management measures

Shared

n/a

Requires essential and important entities to take appropriate measures to manage cybersecurity risks.

189

EU_GDPR_2016_679_Art._24

EU General Data Protection Regulation (GDPR) 2016/679 Art. 24

Chapter 4 - Controller and processor

Responsibility of the controller

Shared

n/a

306

EU_GDPR_2016_679_Art._25

EU General Data Protection Regulation (GDPR) 2016/679 Art. 25

Chapter 4 - Controller and processor

Data protection by design and by default

Shared

n/a

306

EU_GDPR_2016_679_Art._28

EU General Data Protection Regulation (GDPR) 2016/679 Art. 28

Chapter 4 - Controller and processor

Processor

Shared

n/a

306

FBI_Criminal_Justice_Information_Services_v5.9.5_5

EU_GDPR_2016_679_Art._32

EU General Data Protection Regulation (GDPR) 2016/679 Art. 32

Chapter 4 - Controller and processor

Security of processing

Shared

n/a

306

FBI_Criminal_Justice_Information_Services_v5.9.5_5.1

FBI Criminal Justice Information Services (CJIS) v5.9.5 5.1

Policy and Implementation - Systems And Communications Protection

Systems And Communications Protection

Shared

In addition, applications, services, or information systems must have the capability to ensure system integrity through the detection and protection against unauthorized changes to software and information.

Examples of systems and communications safeguards range from boundary and transmission protection to securing an agency's virtualized environment.

110

FBI_Criminal_Justice_Information_Services_v5.9.5_5

FBI_Criminal_Justice_Information_Services_v5.9.5_5.6

FBI Criminal Justice Information Services (CJIS) v5.9.5 5.6

Policy and Implementation - Identification And Authentication

Identification And Authentication

Shared

Ensure and maintain the proper identification and authentications measures with appropriate security safeguards to avoid issues like identity theft.

1. Identification is a unique, auditable representation of an identity within an information system usually in the form of a simple character string for each individual user, machine, software component, or any other entity. 2. Authentication refers to mechanisms or processes to verify the identity of a user, process, or device, as a prerequisite to allowing access to a system's resources.

FBI_Criminal_Justice_Information_Services_v5.9.5_5

FBI_Criminal_Justice_Information_Services_v5.9.5_5.7

404 not found

n/a

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

FedRAMP_Moderate_R4

IA-5

FedRAMP_Moderate_R4_IA-5

FedRAMP Moderate IA-5

Identification And Authentication

Authenticator Management

Shared

n/a

ISO_IEC_27017_2015_10.1.2

FFIEC_CAT_2017

3.1.2

FFIEC_CAT_2017_3.1.2

FFIEC CAT 2017 3.1.2

Cybersecurity Controls

Access and Data Management

Shared

n/a

Employee access is granted to systems and confidential data based on job responsibilities and the principles of least privilege.'FFIEC_Cybersecurity Control'!F8 - Employee access to systems and confidential data provides for separation of duties. - Elevated privileges (e.g., administrator privileges) are limited and tightly controlled (e.g., assigned to individuals, not shared, and require stronger 'FFIEC_Cybersecurity Control'!F7password controls). - User access reviews are performed periodically for all systems and applications based on the risk to the application or system. - Changes to physical and logical user access, including those that result from voluntary and involuntary terminations, are submitted to and approved by appropriate personnel. - Identification and authentication are required and managed for access to systems, applications, and hardware. - Access controls include password complexity and limits to password attempts and reuse. - All default passwords and unnecessary default accounts are changed before system implementation. - Customer access to Internet-based products or services requires authentication controls (e.g., layered controls, multifactor) that are commensurate with the risk. - Production and non-production environments are segregated to prevent unauthorized access or changes to information assets. (*N/A if no production environment exists at the institution or the institution’s third party.) - Physical security controls are used to prevent unauthorized access to information systems and telecommunication systems. - All passwords are encrypted in storage and in transit. - Confidential data are encrypted when transmitted across public or untrusted networks (e.g., Internet). - Mobile devices (e.g., laptops, tablets, and removable media) are encrypted if used to store confidential data. (*N/A if mobile devices are not used.) - Remote access to critical systems by employees, contractors, and third parties uses encrypted connections and multifactor authentication. - Administrative, physical, or technical controls are in place to prevent users without administrative responsibilities from installing unauthorized software. - Customer service (e.g., the call center) utilizes formal procedures to authenticate customers commensurate with the risk of the transaction or request. - Data is disposed of or destroyed according to documented requirements and within expected time frames.

HITRUST_CSF_v11.3

01.q

HITRUST_CSF_v11.3_01.q

HITRUST CSF v11.3 01.q

Operating System Access Control

Prevent unauthorized access to operating systems and implement authentication technique to verify user.

Shared

1. Each user ID in the information system to be assigned to a specific named individual to ensure accountability. 2. Multi-factor authentication to be implemented for network and local access to privileged accounts. 3. Users to be uniquely identified and authenticated for local access and remote access. 4. Biometric-based electronic signatures and multifactor authentication to be implemented to ensure exclusive ownership validation and enhanced security for both remote and local network access to privileged and non-privileged accounts.

All users shall have a unique identifier (user ID) for their personal use only, and an authentication technique shall be implemented to substantiate the claimed identity of a user.

ISO_IEC_27002_2022

8.24

ISO_IEC_27002_2022_8.24

ISO IEC 27002 2022 8.24

Protection, Preventive Control

Use of cryptography

Shared

Rules for the effective use of cryptography, including cryptographic key management, should be defined and implemented.

To ensure proper and effective use of cryptography to protect the confidentiality, authenticity or integrity of information according to business and information security requirements, and taking into consideration legal, statutory, regulatory and contractual requirements related to cryptography.

ISO_IEC_27017_2015

10.1.2

ISO IEC 27017 2015 10.1.2

Cryptography

Key Management

Shared

For Cloud Service Customer: The cloud service customer should identify the cryptographic keys for each cloud service, and implement procedures for key management. Where the cloud service provides key management functionality for use by the cloud service customer, the cloud service customer should request the following information on the procedures used to manage keys related to the cloud service: (i) type of keys; (ii) specifications of the key management system, including procedures for each stage of the key life-cycle, i.e., generating, changing or updating, storing, retiring, retrieving, retaining and destroying; (iii) recommended key management procedures for use by the cloud service customer. The cloud service customer should not permit the cloud service provider to store and manage the encryption keys for cryptographic operations when the cloud service customer employs its own key management or a separate and distinct key management service.

New_Zealand_ISM

17.1.58.C.01

New_Zealand_ISM_17.1.58.C.01

17. Cryptography

17.1.58.C.01 Key Refresh and Retirement

n/a

Agencies SHOULD establish cryptoperiods for all keys and cryptographic implementations in their systems and operations.

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.

NIST_SP_800-171_R3_3.1.16

.1.16

NIST 800-171 R3 3.1.16

Access Control

Wireless Access

Shared

Establishing usage restrictions, configuration requirements, and connection requirements for wireless access to the system provides criteria to support access authorization decisions. These restrictions and requirements reduce susceptibility to unauthorized system access through wireless technologies. Wireless networks use authentication protocols that provide credential protection and mutual authentication. Organizations authenticate individuals and devices to protect wireless access to the system. Special attention is given to the variety of devices with potential wireless access to the system, including small form factor mobile devices (e.g., smart phones, smart watches). Wireless networking capabilities that are embedded within system components represent a significant potential vulnerability that can be exploited by adversaries. Disabling wireless capabilities when not needed for essential missions or business functions can help reduce susceptibility to threats by adversaries involving wireless technologies.

a. Establish usage restrictions, configuration requirements, and connection requirements for each type of wireless access to the system. b. Authorize each type of wireless access to the system prior to establishing such connections. c. Disable, when not intended for use, wireless networking capabilities prior to issuance and deployment.

.1.5

NIST_SP_800-171_R3_3.1.5

NIST 800-171 R3 3.1.5

Access Control

Least Privilege

Shared

Organizations employ the principle of least privilege for specific duties and authorized access for users and system processes. Least privilege is applied to the development, implementation, and operation of the system. Organizations consider creating additional processes, roles, and system accounts to achieve least privilege. Security functions include establishing system accounts and assigning privileges, installing software, configuring access authorizations, configuring settings for events to be audited, establishing vulnerability scanning parameters, and establishing intrusion detection parameters. Security-relevant information includes threat and vulnerability information, filtering rules for routers or firewalls, configuration parameters for security services, security architecture, cryptographic key management information, and access control lists.

a. Allow only authorized system access for users (or processes acting on behalf of users) that is necessary to accomplish assigned organizational tasks. b. Authorize access to [Assignment: organization-defined security functions and security-relevant information]. c. Review the privileges assigned to roles or classes of users periodically to validate the need for such privileges. d. Reassign or remove privileges, as necessary.

NIST_SP_800-171_R3_3.13.10

.13.10

NIST 800-171 R3 3.13.10

System and Communications Protection Control

Cryptographic Key Establishment and Management

Shared

Cryptographic key establishment and management include key generation, distribution, storage, access, rotation, and destruction. Cryptographic keys can be established and managed using either manual procedures or automated mechanisms supported by manual procedures. Organizations satisfy key establishment and management requirements in accordance with applicable federal laws, Executive Orders, policies, directives, regulations, and standards that specify appropriate options, levels, and parameters. This requirement is related to 03.13.11.

Establish and manage cryptographic keys in the system in accordance with the following key management requirements: [Assignment: organization-defined requirements for key establishment and management].

.5.1

NIST_SP_800-171_R3_3.5.1

404 not found

n/a

.5.5

NIST_SP_800-171_R3_3.5.5

404 not found

n/a

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

NIST_SP_800-53_R5.1.1_CM.3.6

NIST_SP_800-53_R5.1.1

CM.3.6

NIST SP 800-53 R5.1.1 CM.3.6

Configuration Management Control

Configuration Change Control | Cryptography Management

Shared

Ensure that cryptographic mechanisms used to provide the following controls are under configuration management: [Assignment: organization-defined controls].

The controls referenced in the control enhancement refer to security and privacy controls from the control catalog. Regardless of the cryptographic mechanisms employed, processes and procedures are in place to manage those mechanisms. For example, if system components use certificates for identification and authentication, a process is implemented to address the expiration of those certificates.

NIST_SP_800-53_R5.1.1

IA.2

NIST_SP_800-53_R5.1.1_IA.2

NIST SP 800-53 R5.1.1 IA.2

Identification and Authentication Control

Identification and Authentication (organizational Users)

Shared

Uniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users.

Organizations can satisfy the identification and authentication requirements by complying with the requirements in [HSPD 12]. Organizational users include employees or individuals who organizations consider to have an equivalent status to employees (e.g., contractors and guest researchers). Unique identification and authentication of users applies to all accesses other than those that are explicitly identified in AC-14 and that occur through the authorized use of group authenticators without individual authentication. Since processes execute on behalf of groups and roles, organizations may require unique identification of individuals in group accounts or for detailed accountability of individual activity. Organizations employ passwords, physical authenticators, or biometrics to authenticate user identities or, in the case of multi-factor authentication, some combination thereof. Access to organizational systems is defined as either local access or network access. Local access is any access to organizational systems by users or processes acting on behalf of users, where access is obtained through direct connections without the use of networks. Network access is access to organizational systems by users (or processes acting on behalf of users) where access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks. Internal networks include local area networks and wide area networks. The use of encrypted virtual private networks for network connections between organization-controlled endpoints and non-organization-controlled endpoints may be treated as internal networks with respect to protecting the confidentiality and integrity of information traversing the network. Identification and authentication requirements for non-organizational users are described in IA-8.

NIST_SP_800-53_R5.1.1

SC.12

NIST_SP_800-53_R5.1.1_SC.12

NIST SP 800-53 R5.1.1 SC.12

System and Communications Protection

Cryptographic Key Establishment and Management

Shared

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

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 laws, executive orders, directives, regulations, policies, standards, and guidelines and specify appropriate options, parameters, and levels. Organizations manage trust stores to ensure that only approved trust anchors are part of such trust stores. This includes certificates with visibility external to organizational systems and certificates related to the internal operations of systems. [NIST CMVP] and [NIST CAVP] provide additional information on validated cryptographic modules and algorithms that can be used in cryptographic key management and establishment.

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.

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.

16.3.5.C.01.

NZISM_v3.7_16.3.5.C.01.

NZISM v3.7 16.3.5.C.01.

Privileged User Access

16.3.5.C.01. - enhance overall security posture.

Shared

n/a

Agencies MUST: 1. ensure strong change management practices are implemented; 2. ensure that the use of privileged accounts is controlled and accountable; 3. ensure that system administrators are assigned and consistently use, an individual account for the performance of their administration tasks; 4. keep privileged accounts to a minimum; and 5. allow the use of privileged accounts for administrative work only.

16.3.5.C.02.

NZISM_v3.7_16.3.5.C.02.

NZISM v3.7 16.3.5.C.02.

Privileged User Access

16.3.5.C.02. - enhance overall security posture.

Shared

n/a

Agencies SHOULD: 1. ensure strong change management practices are implemented; 2. ensure that the use of privileged accounts is controlled and accountable; 3. ensure that system administrators are assigned an individual account for the performance of their administration tasks; 4. keep privileged accounts to a minimum; and 5. allow the use of privileged accounts for administrative work only.

16.5.10.C.02.

NZISM_v3.7_16.5.10.C.02.

NZISM v3.7 16.5.10.C.02.

Remote Access

16.5.10.C.02. - enhance security and reduce the risk of unauthorized access or misuse.

Shared

n/a

Agencies SHOULD authenticate both the remote system user and device during the authentication process.

19.1.22.C.02.

NZISM_v3.7_19.1.22.C.02.

NZISM v3.7 19.1.22.C.02.

Gateways

19.1.22.C.02. - ensure transparency, accountability, and adherence to established procedures for maintaining network security and integrity.

Shared

n/a

Agencies MUST document any changes to gateways in accordance with the agency's Change Management Policy.

3.3.6.C.05.

NZISM_v3.7_3.3.6.C.05.

NZISM v3.7 3.3.6.C.05.

Information Technology Security Managers

3.3.6.C.05. - enhance the integrity and security of agency IT operations.

Shared

n/a

ITSMs SHOULD be included in the agency's change management and change control processes to ensure that risks are properly identified and controls are properly applied to manage those risks.

6.3.6.C.01.

NZISM_v3.7_6.3.6.C.01.

NZISM v3.7 6.3.6.C.01.

Change Management

6.3.6.C.01. - maintain the integrity and security of systems.

Shared

n/a

Agencies MUST ensure that for routine and urgent changes: 1. the change management process, as defined in the relevant information security documentation, is followed; 2. the proposed change is approved by the relevant authority; 3. any proposed change that could impact the security or accreditation status of a system is submitted to the Accreditation Authority for approval; and 4. all associated information security documentation is updated to reflect the change.

6.3.6.C.02.

NZISM_v3.7_6.3.6.C.02.

NZISM v3.7 6.3.6.C.02.

Change Management

6.3.6.C.02. - maintain operational integrity and security posture.

Shared

n/a

Agencies SHOULD ensure that for routine and urgent changes: 1. the change management process, as defined in the relevant information security documentation, is followed; 2. the proposed change is approved by the relevant authority; 3. any proposed change that could impact the security of a system or accreditation status is submitted to the Accreditation Authority for approval; and 4. all associated information security documentation is updated to reflect the change.

6.3.7.C.01.

NZISM_v3.7_6.3.7.C.01.

NZISM v3.7 6.3.7.C.01.

Change Management

6.3.7.C.01. - foster systematic and responsive management of critical alterations.

Shared

n/a

An agency's change management process MUST define appropriate actions to be followed before and after urgent changes are implemented.

6.3.7.C.02.

NZISM_v3.7_6.3.7.C.02.

NZISM v3.7 6.3.7.C.02.

Change Management

6.3.7.C.02. - facilitate structured management of critical alterations.

Shared

n/a

An agency's change management process SHOULD define appropriate actions to be followed before and after urgent changes are implemented.

6.3.7.C.03.

NZISM_v3.7_6.3.7.C.03.

NZISM v3.7 6.3.7.C.03.

Change Management

6.3.7.C.03. - ensure systematic and effective management of changes.

Shared

n/a

Agencies SHOULD follow this change management process outline: 1. produce a written change request; 2. submit the change request to all stakeholders for approval; 3. document the changes to be implemented; 4. test the approved changes; 5. notification to user of the change schedule and likely effect or outage; 6. implement the approved changes after successful testing; 7. update the relevant information security documentation including the SRMP, SSP and SOPs 8. notify and educate system users of the changes that have been implemented as close as possible to the time the change is applied; and 9. continually educate system users in regards to changes.

3.6.1

PCI_DSS_v4.0.1_3.6.1

PCI DSS v4.0.1 3.6.1

Protect Stored Account Data

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

Shared

n/a

Examine documented key-management policies and procedures to verify that processes to protect cryptographic keys used to protect stored account data against disclosure and misuse are defined to include all elements specified in this requirement

3.6.1.1

PCI_DSS_v4.0.1_3.6.1.1

PCI DSS v4.0.1 3.6.1.1

Protect Stored Account Data

Additional requirement for service providers only: 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. 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, to support meeting Requirement 12.3.4

Shared

n/a

Additional testing procedure for service provider assessments only: Interview responsible personnel and examine documentation to verify that a document exists to describe the cryptographic architecture that includes all elements specified in this requirement

3.7.1

PCI_DSS_v4.0.1_3.7.1

PCI DSS v4.0.1 3.7.1

Protect Stored Account Data

Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data

Shared

n/a

Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define generation of strong cryptographic keys. Observe the method for generating keys to verify that strong keys are generated

3.7.2

PCI_DSS_v4.0.1_3.7.2

PCI DSS v4.0.1 3.7.2

Protect Stored Account Data

Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data

Shared

n/a

Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define secure distribution of cryptographic keys. Observe the method for distributing keys to verify that keys are distributed securely

3.7.3

PCI_DSS_v4.0.1_3.7.3

PCI DSS v4.0.1 3.7.3

Protect Stored Account Data

Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data

Shared

n/a

Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define secure storage of cryptographic keys. Observe the method for storing keys to verify that keys are stored securely

3.7.5

PCI_DSS_v4.0.1_3.7.5

PCI DSS v4.0.1 3.7.5

Protect Stored Account Data

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. The key is suspected of or known to be compromised. Retired or replaced keys are not used for encryption operations

Shared

n/a

Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define retirement, replacement, or destruction of keys in accordance with all elements specified in this requirement. Interview personnel to verify that processes are implemented in accordance with all elements specified in this requirement

3.7.6

PCI_DSS_v4.0.1_3.7.6

PCI DSS v4.0.1 3.7.6

Protect Stored Account Data

Where manual cleartext cryptographic key-management operations are performed by personnel, key-management policies and procedures are implemented, including managing these operations using split knowledge and dual control

Shared

n/a

Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define using split knowledge and dual control. Interview personnel and/or observe processes to verify that manual cleartext keys are managed with split knowledge and dual control

3.7.7

PCI_DSS_v4.0.1_3.7.7

PCI DSS v4.0.1 3.7.7

Protect Stored Account Data

Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys

Shared

n/a

Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define prevention of unauthorized substitution of cryptographic keys. Interview personnel and/or observe processes to verify that unauthorized substitution of keys is prevented

3.7.8

PCI_DSS_v4.0.1_3.7.8

PCI DSS v4.0.1 3.7.8

Protect Stored Account Data

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

Shared

n/a

Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define acknowledgments for key custodians in accordance with all elements specified in this requirement. Examine documentation or other evidence showing that key custodians have provided acknowledgments in accordance with all elements specified in this requirement

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.

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

CC2.3

SOC_2023_CC2.3

SOC 2023 CC2.3

Information and Communication

Facilitate effective internal communication.

Shared

n/a

Entity to communicate with external parties regarding matters affecting the functioning of internal control.

214

CC5.3

SOC_2023_CC5.3

SOC 2023 CC5.3

Control Activities

Maintain alignment with organizational objectives and regulatory requirements.

Shared

n/a

Entity deploys control activities through policies that establish what is expected and in procedures that put policies into action by establishing Policies and Procedures to Support Deployment of Management’s Directives, Responsibility and Accountability for Executing Policies and Procedures, perform tasks in a timely manner, taking corrective actions, perform using competent personnel and reassess policies and procedures.

225

CC6.1

SOC_2023_CC6.1

SOC 2023 CC6.1

Logical and Physical Access Controls

Mitigate security events and ensuring the confidentiality, integrity, and availability of critical information assets.

Shared

n/a

Entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives by identifying and managing the inventory of information assets, restricting logical access, identification and authentication of users, consider network segmentation, manage points of access, restricting access of information assets, managing identification and authentication, managing credentials for infrastructure and software, using encryption to protect data and protect using encryption keys.

127

CC7.4

SOC_2023_CC7.4

SOC 2023 CC7.4

Systems Operations

Effectively manage security incidents, minimize their impact, and protect assets, operations, and reputation.

Shared

n/a

The entity responds to identified security incidents by: a. Executing a defined incident-response program to understand, contain, remediate, and communicate security incidents by assigning roles and responsibilities; b. Establishing procedures to contain security incidents; c. Mitigating ongoing security incidents, End Threats Posed by Security Incidents; d. Restoring operations; e. Developing and Implementing Communication Protocols for Security Incidents; f. Obtains Understanding of Nature of Incident and Determines Containment Strategy; g. Remediation Identified Vulnerabilities; h. Communicating Remediation Activities; and, i. Evaluating the Effectiveness of Incident Response and periodic incident evaluations.

209

CC8.1

SOC_2023_CC8.1

SOC 2023 CC8.1

Change Management

Minimise risks, ensure quality, optimise efficiency, and enhance resilience in the face of change.

Shared

n/a

The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives by Managing Changes Throughout the System Life Cycle, authorizing changes, designing and developing changes, documenting all changes, tracking system changes, configuring software's, testing system changes, approving system changes, deploying system changes, identifying and evaluating system changes, creating baseline configurations for IT technologies and providing necessary changes in emergency situations.

143