compliance controls are associated with this Policy definition 'Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity' (d26f7642-7545-4e18-9b75-8c9bbdee3a9a)
Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
Azure_Security_Benchmark_v3.0 |
IM-3 |
Azure_Security_Benchmark_v3.0_IM-3 |
Microsoft cloud security benchmark IM-3 |
Identity Management |
Manage application identities securely and automatically |
Shared |
**Security Principle:**
Use managed application identities instead of creating human accounts for applications to access resources and execute code. Managed application identities provide benefits such as reducing the exposure of credentials. Automate the rotation of credential to ensure the security of the identities.
**Azure Guidance:**
Use Azure managed identities, which can authenticate to Azure services and resources that support Microsoft Entra ID authentication. Managed identity credentials are fully managed, rotated, and protected by the platform, avoiding hard-coded credentials in source code or configuration files.
For services that don't support managed identities, use Microsoft Entra ID to create a service principal with restricted permissions at the resource level. It is recommended to configure service principals with certificate credentials and fall back to client secrets for authentication.
**Implementation and additional context:**
Azure managed identities:
https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview
Services that support managed identities for Azure resources:
https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities
Azure service principal:
https://docs.microsoft.com/powershell/azure/create-azure-service-principal-azureps
Create a service principal with certificates:
https://docs.microsoft.com/azure/active-directory/develop/howto-authenticate-service-principal-powershell |
n/a |
link |
3 |
Azure_Security_Benchmark_v3.0 |
PV-4 |
Azure_Security_Benchmark_v3.0_PV-4 |
Microsoft cloud security benchmark PV-4 |
Posture and Vulnerability Management |
Audit and enforce secure configurations for compute resources |
Shared |
**Security Principle:**
Continuously monitor and alert when there is a deviation from the defined configuration baseline in your compute resources. Enforce the desired configuration according to the baseline configuration by denying the non-compliant configuration or deploy a configuration in compute resources.
**Azure Guidance:**
Use Microsoft Defender for Cloud and Azure Policy guest configuration agent to regularly assess and remediate configuration deviations on your Azure compute resources, including VMs, containers, and others. In addition, you can use Azure Resource Manager templates, custom operating system images, or Azure Automation State Configuration to maintain the security configuration of the operating system. Microsoft VM templates in conjunction with Azure Automation State Configuration can assist in meeting and maintaining security requirements.
Note: Azure Marketplace VM images published by Microsoft are managed and maintained by Microsoft.
**Implementation and additional context:**
How to implement Microsoft Defender for Cloud vulnerability assessment recommendations:
https://docs.microsoft.com/azure/security-center/security-center-vulnerability-assessment-recommendations
How to create an Azure virtual machine from an ARM template:
https://docs.microsoft.com/azure/virtual-machines/windows/ps-template
Azure Automation State Configuration overview:
https://docs.microsoft.com/azure/automation/automation-dsc-overview
Create a Windows virtual machine in the Azure portal:
https://docs.microsoft.com/azure/virtual-machines/windows/quick-create-portal
Container security in Microsoft Defender for Cloud:
https://docs.microsoft.com/azure/security-center/container-security |
n/a |
link |
13 |
Canada_Federal_PBMM_3-1-2020 |
AC_14 |
Canada_Federal_PBMM_3-1-2020_AC_14 |
Canada Federal PBMM 3-1-2020 AC 14 |
Permitted Actions Without Identification or Authentication |
Permitted Actions without Identification or Authentication |
Shared |
1. The organization identifies user actions that can be performed on the information system without identification or authentication consistent with organizational missions/business functions.
2. The organization documents and provides supporting rationale in the security plan for the information system, user actions not requiring identification or authentication. |
To ensure transparency and accountability in the system's security measures. |
|
19 |
Canada_Federal_PBMM_3-1-2020 |
AC_2(4) |
Canada_Federal_PBMM_3-1-2020_AC_2(4) |
Canada Federal PBMM 3-1-2020 AC 2(4) |
Account Management |
Account Management | Automated Audit Actions |
Shared |
1. The information system automatically audits account creation, modification, enabling, disabling, and removal actions, and notifies responsible managers.
2. Related controls: AU-2, AU-12. |
To ensure accountability and transparency within the information system. |
|
53 |
Canada_Federal_PBMM_3-1-2020 |
AC_3 |
Canada_Federal_PBMM_3-1-2020_AC_3 |
Canada Federal PBMM 3-1-2020 AC 3 |
Access Enforcement |
Access Enforcement |
Shared |
The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. |
To mitigate the risk of unauthorized access. |
|
33 |
Canada_Federal_PBMM_3-1-2020 |
CM_3(6) |
Canada_Federal_PBMM_3-1-2020_CM_3(6) |
Canada Federal PBMM 3-1-2020 CM 3(6) |
Configuration Change Control |
Configuration Change Control | Cryptography Management |
Shared |
The organization ensures that cryptographic mechanisms used to provide any cryptographic-based safeguards are under configuration management. |
To uphold security and integrity measures. |
|
20 |
Canada_Federal_PBMM_3-1-2020 |
IA_1 |
Canada_Federal_PBMM_3-1-2020_IA_1 |
Canada Federal PBMM 3-1-2020 IA 1 |
Identification and Authentication Policy and Procedures |
Identification and Authentication Policy and Procedures |
Shared |
1. The organization Develops, documents, and disseminates to all personnel:
a. An identification and authentication policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
b. Procedures to facilitate the implementation of the identification and authentication policy and associated identification and authentication controls.
2. The organization Reviews and updates the current:
a. Identification and authentication policy at least every 3 years; and
b. Identification and authentication procedures at least annually. |
To ensure secure access control and compliance with established standards. |
|
19 |
Canada_Federal_PBMM_3-1-2020 |
IA_2 |
Canada_Federal_PBMM_3-1-2020_IA_2 |
Canada Federal PBMM 3-1-2020 IA 2 |
Identification and Authentication (Organizational Users) |
Identification and Authentication (Organizational Users) |
Shared |
The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). |
To prevent unauthorized access and maintain system security. |
|
19 |
Canada_Federal_PBMM_3-1-2020 |
IA_4(2) |
Canada_Federal_PBMM_3-1-2020_IA_4(2) |
Canada Federal PBMM 3-1-2020 IA 4(2) |
Identifier Management |
Identifier Management | Supervisor Authorization |
Shared |
The organization requires that the registration process to receive an individual identifier includes supervisor authorization. |
To ensure accountability and authorization by requiring supervisor approval during the registration process for individual identifiers. |
|
18 |
Canada_Federal_PBMM_3-1-2020 |
IA_4(3) |
Canada_Federal_PBMM_3-1-2020_IA_4(3) |
Canada Federal PBMM 3-1-2020 IA 4(3) |
Identifier Management |
Identifier Management | Multiple Forms of Certification |
Shared |
The organization requires multiple forms of certification of individual identification such as documentary evidence or a combination of documents and biometrics be presented to the registration authority. |
To enhance the reliability and accuracy of individual identification. |
|
18 |
Canada_Federal_PBMM_3-1-2020 |
IA_8 |
Canada_Federal_PBMM_3-1-2020_IA_8 |
Canada Federal PBMM 3-1-2020 IA 8 |
Identification and Authentication (Non-Organizational Users) |
Identification and Authentication (Non-Organizational Users) |
Shared |
The information system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users). |
To ensure secure access and accountability. |
|
16 |
CIS_Controls_v8.1 |
3.3 |
CIS_Controls_v8.1_3.3 |
CIS Controls v8.1 3.3 |
Data Protection |
Configure data access control lists |
Shared |
1. Configure data access control lists based on a user’s need to know.
2. Apply data access control lists, also known as access permissions, to local and remote file systems, databases, and applications.
|
To ensure that users have access only to the data necessary for their roles. |
|
25 |
CIS_Controls_v8.1 |
6.8 |
CIS_Controls_v8.1_6.8 |
CIS Controls v8.1 6.8 |
Access Control Management |
Define and maintain role-based access control. |
Shared |
1. Define and maintain role-based access control, through determining and documenting the access rights necessary for each role within the enterprise to successfully carry out its assigned duties.
2. Perform access control reviews of enterprise assets to validate that all privileges are authorized, on a recurring schedule at a minimum annually, or more frequently. |
To implement a system of role-based access control. |
|
30 |
CMMC_2.0_L2 |
AU.L2-3.3.1 |
CMMC_2.0_L2_AU.L2-3.3.1 |
404 not found |
|
|
|
n/a |
n/a |
|
35 |
CMMC_2.0_L2 |
AU.L2-3.3.2 |
CMMC_2.0_L2_AU.L2-3.3.2 |
404 not found |
|
|
|
n/a |
n/a |
|
33 |
CMMC_2.0_L2 |
SI.L2-3.14.6 |
CMMC_2.0_L2_SI.L2-3.14.6 |
404 not found |
|
|
|
n/a |
n/a |
|
25 |
CMMC_2.0_L2 |
SI.L2-3.14.7 |
CMMC_2.0_L2_SI.L2-3.14.7 |
404 not found |
|
|
|
n/a |
n/a |
|
19 |
CMMC_L2_v1.9.0 |
AC.L1_3.1.1 |
CMMC_L2_v1.9.0_AC.L1_3.1.1 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 AC.L1 3.1.1 |
Access Control |
Authorized Access Control |
Shared |
Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems). |
To ensure security and integrity. |
|
27 |
CMMC_L2_v1.9.0 |
AC.L2_3.1.5 |
CMMC_L2_v1.9.0_AC.L2_3.1.5 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 AC.L2 3.1.5 |
Access Control |
Least Privilege |
Shared |
Employ the principle of least privilege, including for specific security functions and privileged accounts. |
To restrict information system access. |
|
27 |
CMMC_L2_v1.9.0 |
CM.L2_3.4.1 |
CMMC_L2_v1.9.0_CM.L2_3.4.1 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 CM.L2 3.4.1 |
Configuration Management |
System Baselining |
Shared |
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. |
To ensure consistency, security, and compliance with organizational standards and requirements. |
|
17 |
CMMC_L2_v1.9.0 |
CM.L2_3.4.5 |
CMMC_L2_v1.9.0_CM.L2_3.4.5 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 CM.L2 3.4.5 |
Configuration Management |
Access Restrictions for Change |
Shared |
Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems. |
To ensure only authorized individuals have access to make changes and that proper controls are in place to safeguard system integrity and security. |
|
3 |
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. |
|
23 |
CMMC_L3 |
AC.3.021 |
CMMC_L3_AC.3.021 |
CMMC L3 AC.3.021 |
Access Control |
Authorize remote execution of privileged commands and remote access to security-relevant information. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
A privileged command is a human-initiated (interactively or via a process operating on behalf of the human) command executed on a system involving the control, monitoring, or administration of the system including security functions and associated security-relevant information. Securityrelevant information is any information within the system that can potentially impact the operation of security functions or the provision of security services in a manner that could result in failure to enforce the system security policy or maintain isolation of code and data. Privileged commands give individuals the ability to execute sensitive, security-critical, or security-relevant system functions. Controlling such access from remote locations helps to ensure that unauthorized individuals are not able to execute such commands freely with the potential to do serious or catastrophic damage to organizational systems. Note that the ability to affect the integrity of the system is considered security-relevant as that could enable the means to by-pass security functions although not directly impacting the function itself. |
link |
10 |
CSA_v4.0.12 |
CCC_06 |
CSA_v4.0.12_CCC_06 |
CSA Cloud Controls Matrix v4.0.12 CCC 06 |
Change Control and Configuration Management |
Change Management Baseline |
Shared |
n/a |
Establish change management baselines for all relevant authorized
changes on organization assets. |
|
8 |
CSA_v4.0.12 |
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. |
|
11 |
CSA_v4.0.12 |
CEK_06 |
CSA_v4.0.12_CEK_06 |
CSA Cloud Controls Matrix v4.0.12 CEK 06 |
Cryptography, Encryption & Key Management |
Encryption Change Cost Benefit Analysis |
Shared |
n/a |
Manage and adopt changes to cryptography-, encryption-, and key management-related
systems (including policies and procedures) that fully account for downstream
effects of proposed changes, including residual risk, cost, and benefits analysis. |
|
8 |
CSA_v4.0.12 |
CEK_07 |
CSA_v4.0.12_CEK_07 |
CSA Cloud Controls Matrix v4.0.12 CEK 07 |
Cryptography, Encryption & Key Management |
Encryption Risk Management |
Shared |
n/a |
Establish and maintain an encryption and key management risk program
that includes provisions for risk assessment, risk treatment, risk context,
monitoring, and feedback. |
|
8 |
CSA_v4.0.12 |
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. |
|
25 |
CSA_v4.0.12 |
DCS_05 |
CSA_v4.0.12_DCS_05 |
CSA Cloud Controls Matrix v4.0.12 DCS 05 |
Datacenter Security |
Assets Classification |
Shared |
n/a |
Classify and document the physical, and logical assets (e.g., applications)
based on the organizational business risk. |
|
6 |
CSA_v4.0.12 |
DCS_06 |
CSA_v4.0.12_DCS_06 |
CSA Cloud Controls Matrix v4.0.12 DCS 06 |
Datacenter Security |
Assets Cataloguing and Tracking |
Shared |
n/a |
Catalogue and track all relevant physical and logical assets located
at all of the CSP's sites within a secured system. |
|
7 |
CSA_v4.0.12 |
IAM_05 |
CSA_v4.0.12_IAM_05 |
CSA Cloud Controls Matrix v4.0.12 IAM 05 |
Identity & Access Management |
Least Privilege |
Shared |
n/a |
Employ the least privilege principle when implementing information
system access. |
|
27 |
CSA_v4.0.12 |
IAM_10 |
CSA_v4.0.12_IAM_10 |
CSA Cloud Controls Matrix v4.0.12 IAM 10 |
Identity & Access Management |
Management of Privileged Access Roles |
Shared |
n/a |
Define and implement an access process to ensure privileged access
roles and rights are granted for a time limited period, and implement procedures
to prevent the culmination of segregated privileged access. |
|
56 |
CSA_v4.0.12 |
UEM_04 |
CSA_v4.0.12_UEM_04 |
CSA Cloud Controls Matrix v4.0.12 UEM 04 |
Universal Endpoint Management |
Endpoint Inventory |
Shared |
n/a |
Maintain an inventory of all endpoints used to store and access company
data. |
|
6 |
CSA_v4.0.12 |
UEM_07 |
CSA_v4.0.12_UEM_07 |
CSA Cloud Controls Matrix v4.0.12 UEM 07 |
Universal Endpoint Management |
Operating Systems |
Shared |
n/a |
Manage changes to endpoint operating systems, patch levels, and/or
applications through the company's change management processes. |
|
6 |
CSA_v4.0.12 |
UEM_12 |
CSA_v4.0.12_UEM_12 |
CSA Cloud Controls Matrix v4.0.12 UEM 12 |
Universal Endpoint Management |
Remote Locate |
Shared |
n/a |
Enable remote geo-location capabilities for all managed mobile endpoints. |
|
6 |
Cyber_Essentials_v3.1 |
2 |
Cyber_Essentials_v3.1_2 |
Cyber Essentials v3.1 2 |
Cyber Essentials |
Secure Configuration |
Shared |
n/a |
Aim: ensure that computers and network devices are properly configured to reduce vulnerabilities and provide only the services required to fulfill their role. |
|
61 |
Cyber_Essentials_v3.1 |
4 |
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. |
|
74 |
EU_2555_(NIS2)_2022 |
EU_2555_(NIS2)_2022_21 |
EU_2555_(NIS2)_2022_21 |
EU 2022/2555 (NIS2) 2022 21 |
|
Cybersecurity risk-management measures |
Shared |
n/a |
Requires essential and important entities to take appropriate measures to manage cybersecurity risks. |
|
194 |
EU_GDPR_2016_679_Art. |
24 |
EU_GDPR_2016_679_Art._24 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 24 |
Chapter 4 - Controller and processor |
Responsibility of the controller |
Shared |
n/a |
n/a |
|
311 |
EU_GDPR_2016_679_Art. |
25 |
EU_GDPR_2016_679_Art._25 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 25 |
Chapter 4 - Controller and processor |
Data protection by design and by default |
Shared |
n/a |
n/a |
|
311 |
EU_GDPR_2016_679_Art. |
28 |
EU_GDPR_2016_679_Art._28 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 28 |
Chapter 4 - Controller and processor |
Processor |
Shared |
n/a |
n/a |
|
311 |
EU_GDPR_2016_679_Art. |
32 |
EU_GDPR_2016_679_Art._32 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 32 |
Chapter 4 - Controller and processor |
Security of processing |
Shared |
n/a |
n/a |
|
311 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5 |
.5 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5.5 |
FBI Criminal Justice Information Services (CJIS) v5.9.5 5.5 |
Policy and Implementation - Access Control |
Access Control |
Shared |
Refer to Section 5.13.6 for additional access control requirements related to mobile devices used to access CJI. |
Access control provides the planning and implementation of mechanisms to restrict reading, writing, processing, and transmission of CJIS information and the modification of information systems, applications, services and communication configurations allowing access to CJIS information. |
|
97 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5 |
.6 |
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. |
|
19 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5 |
.7 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5.7 |
404 not found |
|
|
|
n/a |
n/a |
|
96 |
FedRAMP_High_R4 |
AU-12 |
FedRAMP_High_R4_AU-12 |
FedRAMP High AU-12 |
Audit And Accountability |
Audit Generation |
Shared |
n/a |
The information system:
a. Provides audit record generation capability for the auditable events defined in AU-2 a. at [Assignment: organization-defined information system components];
b. Allows [Assignment: organization-defined personnel or roles] to select which auditable events are to be audited by specific components of the information system; and
c. Generates audit records for the events defined in AU-2 d. with the content defined in AU-3.
Supplemental Guidance: Audit records can be generated from many different information system components. The list of audited events is the set of events for which audits are to be generated. These events are typically a subset of all events for which the information system is capable of generating audit records. Related controls: AC-3, AU-2, AU-3, AU-6, AU-7.
References: None. |
link |
34 |
FedRAMP_High_R4 |
AU-12(1) |
FedRAMP_High_R4_AU-12(1) |
FedRAMP High AU-12 (1) |
Audit And Accountability |
System-Wide / Time-Correlated Audit Trail |
Shared |
n/a |
The information system compiles audit records from [Assignment: organization-defined information system components] into a system-wide (logical or physical) audit trail that is time- correlated to within [Assignment: organization-defined level of tolerance for relationship between time stamps of individual records in the audit trail].
Supplemental Guidance: Audit trails are time-correlated if the time stamps in the individual audit records can be reliably related to the time stamps in other audit records to achieve a time ordering of the records within organizational tolerances. Related controls: AU-8, AU-12. |
link |
31 |
FedRAMP_High_R4 |
AU-6(4) |
FedRAMP_High_R4_AU-6(4) |
FedRAMP High AU-6 (4) |
Audit And Accountability |
Central Review And Analysis |
Shared |
n/a |
The information system provides the capability to centrally review and analyze audit records from multiple components within the system.
Supplemental Guidance: Automated mechanisms for centralized reviews and analyses include, for example, Security Information Management products. Related controls: AU-2, AU-12. |
link |
30 |
FedRAMP_High_R4 |
AU-6(5) |
FedRAMP_High_R4_AU-6(5) |
FedRAMP High AU-6 (5) |
Audit And Accountability |
Integration / Scanning And Monitoring Capabilities |
Shared |
n/a |
The organization integrates analysis of audit records with analysis of [Selection (one or more): vulnerability scanning information; performance data; information system monitoring information; [Assignment: organization-defined data/information collected from other sources]] to further enhance the ability to identify inappropriate or unusual activity.
Supplemental Guidance: This control enhancement does not require vulnerability scanning, the generation of performance data, or information system monitoring. Rather, the enhancement requires that the analysis of information being otherwise produced in these areas is integrated with the analysis of audit information. Security Event and Information Management System tools can facilitate audit record aggregation/consolidation from multiple information system components as well as audit record correlation and analysis. The use of standardized audit record analysis scripts developed by organizations (with localized script adjustments, as necessary) provides more cost-effective approaches for analyzing audit record information collected. The correlation of audit record information with vulnerability scanning information is important in determining the veracity of vulnerability scans and correlating attack detection events with scanning results. Correlation with performance data can help uncover denial of service attacks or cyber attacks resulting in unauthorized use of resources. Correlation with system monitoring information can assist in uncovering attacks and in better relating audit information to operational situations. Related controls: AU-12, IR-4, RA-5. |
link |
31 |
FedRAMP_High_R4 |
SI-4 |
FedRAMP_High_R4_SI-4 |
FedRAMP High SI-4 |
System And Information Integrity |
Information System Monitoring |
Shared |
n/a |
The organization:
a. Monitors the information system to detect:
1. Attacks and indicators of potential attacks in accordance with [Assignment: organization- defined monitoring objectives]; and
2. Unauthorized local, network, and remote connections;
b. Identifies unauthorized use of the information system through [Assignment: organization- defined techniques and methods];
c. Deploys monitoring devices: (i) strategically within the information system to collect organization-determined essential information; and (ii) at ad hoc locations within the system to track specific types of transactions of interest to the organization;
d. Protects information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion;
e. Heightens the level of information system monitoring activity whenever there is an indication of increased risk to organizational operations and assets, individuals, other organizations, or the Nation based on law enforcement information, intelligence information, or other credible sources of information;
f. Obtains legal opinion with regard to information system monitoring activities in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations; and
g. Provides [Assignment: or ganization-defined information system monitoring information] to [Assignment: organization-defined personnel or roles] [Selection (one or more): as needed; [Assignment: organization-defined frequency]].
Supplemental Guidance: Information system monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at the information system boundary (i.e., part of perimeter defense and boundary protection). Internal monitoring includes the observation of events occurring within the information system. Organizations can monitor information systems, for example, by observing audit activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives may guide determination of the events. Information system monitoring capability is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software). Strategic locations for monitoring devices include, for example, selected perimeter locations and near server farms supporting critical applications, with such devices typically being employed at the managed interfaces associated with controls SC-7 and AC-17. Einstein network monitoring devices from the Department of Homeland Security can also be included as monitoring devices. The granularity of monitoring information collected is based on organizational monitoring objectives and the capability of information systems to support such objectives. Specific types of transactions of interest include, for example, Hyper Text Transfer Protocol (HTTP) traffic that bypasses HTTP proxies. Information system monitoring is an integral part of organizational continuous monitoring and incident response programs. Output from system monitoring serves as input to continuous monitoring and incident response programs. A network connection is any connection with a device that communicates through a network (e.g., local area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Local, network, and remote connections can be either wired or wireless. Related controls: AC-3, AC-4, AC-8, AC-17, AU-2, AU-6, AU-7, AU-9, AU-12, CA-7, IR-4, PE-3, RA-5, SC-7, SC-26, SC-35, SI-3, SI-7.
References: NIST Special Publications 800-61, 800-83, 800-92, 800-94, 800-137. |
link |
22 |
FedRAMP_Moderate_R4 |
AU-12 |
FedRAMP_Moderate_R4_AU-12 |
FedRAMP Moderate AU-12 |
Audit And Accountability |
Audit Generation |
Shared |
n/a |
The information system:
a. Provides audit record generation capability for the auditable events defined in AU-2 a. at [Assignment: organization-defined information system components];
b. Allows [Assignment: organization-defined personnel or roles] to select which auditable events are to be audited by specific components of the information system; and
c. Generates audit records for the events defined in AU-2 d. with the content defined in AU-3.
Supplemental Guidance: Audit records can be generated from many different information system components. The list of audited events is the set of events for which audits are to be generated. These events are typically a subset of all events for which the information system is capable of generating audit records. Related controls: AC-3, AU-2, AU-3, AU-6, AU-7.
References: None. |
link |
34 |
FedRAMP_Moderate_R4 |
SI-4 |
FedRAMP_Moderate_R4_SI-4 |
FedRAMP Moderate SI-4 |
System And Information Integrity |
Information System Monitoring |
Shared |
n/a |
The organization:
a. Monitors the information system to detect:
1. Attacks and indicators of potential attacks in accordance with [Assignment: organization- defined monitoring objectives]; and
2. Unauthorized local, network, and remote connections;
b. Identifies unauthorized use of the information system through [Assignment: organization- defined techniques and methods];
c. Deploys monitoring devices: (i) strategically within the information system to collect organization-determined essential information; and (ii) at ad hoc locations within the system to track specific types of transactions of interest to the organization;
d. Protects information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion;
e. Heightens the level of information system monitoring activity whenever there is an indication of increased risk to organizational operations and assets, individuals, other organizations, or the Nation based on law enforcement information, intelligence information, or other credible sources of information;
f. Obtains legal opinion with regard to information system monitoring activities in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations; and
g. Provides [Assignment: or ganization-defined information system monitoring information] to [Assignment: organization-defined personnel or roles] [Selection (one or more): as needed; [Assignment: organization-defined frequency]].
Supplemental Guidance: Information system monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at the information system boundary (i.e., part of perimeter defense and boundary protection). Internal monitoring includes the observation of events occurring within the information system. Organizations can monitor information systems, for example, by observing audit activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives may guide determination of the events. Information system monitoring capability is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software). Strategic locations for monitoring devices include, for example, selected perimeter locations and near server farms supporting critical applications, with such devices typically being employed at the managed interfaces associated with controls SC-7 and AC-17. Einstein network monitoring devices from the Department of Homeland Security can also be included as monitoring devices. The granularity of monitoring information collected is based on organizational monitoring objectives and the capability of information systems to support such objectives. Specific types of transactions of interest include, for example, Hyper Text Transfer Protocol (HTTP) traffic that bypasses HTTP proxies. Information system monitoring is an integral part of organizational continuous monitoring and incident response programs. Output from system monitoring serves as input to continuous monitoring and incident response programs. A network connection is any connection with a device that communicates through a network (e.g., local area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Local, network, and remote connections can be either wired or wireless. Related controls: AC-3, AC-4, AC-8, AC-17, AU-2, AU-6, AU-7, AU-9, AU-12, CA-7, IR-4, PE-3, RA-5, SC-7, SC-26, SC-35, SI-3, SI-7.
References: NIST Special Publications 800-61, 800-83, 800-92, 800-94, 800-137. |
link |
22 |
FFIEC_CAT_2017 |
3.1.1 |
FFIEC_CAT_2017_3.1.1 |
FFIEC CAT 2017 3.1.1 |
Cybersecurity Controls |
Infrastructure Management |
Shared |
n/a |
- Network perimeter defense tools (e.g., border router and firewall) are used.
- Systems that are accessed from the Internet or by external parties are protected by firewalls or other similar devices.
- All ports are monitored.
- Up to date antivirus and anti-malware tools are used.
- Systems configurations (for servers, desktops, routers, etc.) follow industry standards and are enforced.
- Ports, functions, protocols and services are prohibited if no longer needed for business purposes.
- Access to make changes to systems configurations (including virtual machines and hypervisors) is controlled and monitored.
- Programs that can override system, object, network, virtual machine, and application controls are restricted.
- System sessions are locked after a pre-defined period of inactivity and are terminated after pre-defined conditions are met.
- Wireless network environments require security settings with strong encryption for authentication and transmission. (*N/A if there are no wireless networks.) |
|
72 |
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. |
|
59 |
HITRUST_CSF_v11.3 |
01.q |
HITRUST_CSF_v11.3_01.q |
HITRUST CSF v11.3 01.q |
Operating System Access Control |
To 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. |
|
30 |
HITRUST_CSF_v11.3 |
06.h |
HITRUST_CSF_v11.3_06.h |
HITRUST CSF v11.3 06.h |
Compliance with Security Policies and Standards |
To ensure compliance with security implementation standards by regular checking of information systems. |
Shared |
1. Annual checks on the technical security configuration of systems is to be performed either manually by an individual with experience with the systems and/or with the assistance of automated software tools.
2. Technical compliance checking is to be implemented to show compliance in support of technical interoperability. |
Information systems shall be regularly checked for compliance with security implementation standards. |
|
7 |
HITRUST_CSF_v11.3 |
10.h |
HITRUST_CSF_v11.3_10.h |
HITRUST CSF v11.3 10.h |
Security of System Files |
To ensure the security of system files, access to system files and program source code shall be controlled, and IT projects and support activities conducted in a secure manner. |
Shared |
The updation of operational software, applications, and program libraries is to be performed by authorized administrators. |
There shall be procedures in place to control the installation of software on operational systems. |
|
3 |
HITRUST_CSF_v11.3 |
10.k |
HITRUST_CSF_v11.3_10.k |
HITRUST CSF v11.3 10.k |
Security In Development and Support Processes |
To ensure the security of application system software and information through the development process, project and support environments shall be strictly controlled. |
Shared |
1. The purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance for configuration management is to be formally addressed.
2. Changes to mobile device operating systems, patch levels, and/or applications is to be managed through a formal change management process.
3. A baseline configuration of the information system is to be developed, documented, and maintained under configuration control. |
The implementation of changes, including patches, service packs, and other updates and modifications, shall be controlled by the use of formal change control procedures. |
|
34 |
ISO_IEC_27002_2022 |
5.9 |
ISO_IEC_27002_2022_5.9 |
ISO IEC 27002 2022 5.9 |
Preventive,
Identifying Control |
Inventory of information and other associated assets |
Shared |
An inventory of information and other associated assets, including owners, should be developed and maintained.
|
To identify the organization’s information and other associated assets in order to preserve their information security and assign appropriate ownership. |
|
8 |
ISO_IEC_27002_2022 |
8.2 |
ISO_IEC_27002_2022_8.2 |
ISO IEC 27002 2022 8.2 |
Protection,
Preventive, Control |
Privileged access rights |
Shared |
The allocation and use of privileged access rights should be restricted and managed.
|
To ensure only authorized users, software components and services are provided with privileged access rights. |
|
29 |
ISO_IEC_27017_2015 |
12.4.3 |
ISO_IEC_27017_2015_12.4.3 |
ISO IEC 27017 2015 12.4.3 |
Operations Security |
Administrator and Operation Logs |
Shared |
For Cloud Service Customer:
If a privileged operation is delegated to the cloud service customer, the operation and performance of those operations should be logged. The cloud service customer should determine whether logging capabilities provided by the cloud service provider are appropriate or whether the cloud service customer should implement additional logging capabilities. |
To log operation and performance of those operations wherein rivileged operation is delegated to the cloud service customer. |
|
28 |
ISO_IEC_27017_2015 |
8.1.1 |
ISO_IEC_27017_2015_8.1.1 |
ISO IEC 27017 2015 8.1.1 |
Asset Management |
Inventory of Assets |
Shared |
For Cloud Service Customer:
The cloud service customer's inventory of assets should account for information and associated assets stored in the cloud computing environment. The records of the inventory should indicate where the assets are maintained, e.g., identification of the cloud service.
For Cloud Service Provider:
The inventory of assets of the cloud service provider should explicitly identify:
(i) cloud service customer data;
(ii) cloud service derived data. |
To identify the organization’s information and other associated assets in order to preserve their information security and assign appropriate ownership. |
|
8 |
New_Zealand_ISM |
14.1.9.C.01 |
New_Zealand_ISM_14.1.9.C.01 |
New_Zealand_ISM_14.1.9.C.01 |
14. Software security |
14.1.9.C.01 Maintaining hardened SOEs |
|
n/a |
Agencies MUST ensure that for all servers and workstations: a technical specification is agreed for each platform with specified controls; a standard configuration created and updated for each operating system type and version; system users do not have the ability to install or disable software without approval; and installed software and operating system patching is up to date. |
|
16 |
NIS2 |
PV._Posture_and_Vulnerability_Management_5 |
NIS2_PV._Posture_and_Vulnerability_Management_5 |
NIS2_PV._Posture_and_Vulnerability_Management_5 |
PV. Posture and Vulnerability Management |
Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure |
|
n/a |
missing value |
|
47 |
NIST_CSF_v2.0 |
PR.AA_05 |
NIST_CSF_v2.0_PR.AA_05 |
NIST CSF v2.0 PR.AA 05 |
PROTECT- Identity Management, Authentication, and Access |
Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties. |
Shared |
n/a |
To implement safeguards for managing organization’s cybersecurity risks. |
|
29 |
NIST_SP_800-171_R2_3 |
.14.6 |
NIST_SP_800-171_R2_3.14.6 |
NIST SP 800-171 R2 3.14.6 |
System and Information Integrity |
Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
System monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at the system boundary (i.e., part of perimeter defense and boundary protection). Internal monitoring includes the observation of events occurring within the system. Organizations can monitor systems, for example, by observing audit record activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives may guide determination of the events. System monitoring capability is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software). Strategic locations for monitoring devices include selected perimeter locations and near server farms supporting critical applications, with such devices being employed at managed system interfaces. The granularity of monitoring information collected is based on organizational monitoring objectives and the capability of systems to support such objectives. System monitoring is an integral part of continuous monitoring and incident response programs. Output from system monitoring serves as input to continuous monitoring and incident response programs. A network connection is any connection with a device that communicates through a network (e.g., local area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Local, network, and remote connections can be either wired or wireless. Unusual or unauthorized activities or conditions related to inbound/outbound communications traffic include internal traffic that indicates the presence of malicious code in systems or propagating among system components, the unauthorized exporting of information, or signaling to external systems. Evidence of malicious code is used to identify potentially compromised systems or system components. System monitoring requirements, including the need for specific types of system monitoring, may be referenced in other requirements. [SP 800-94] provides guidance on intrusion detection and prevention systems. |
link |
27 |
NIST_SP_800-171_R2_3 |
.14.7 |
NIST_SP_800-171_R2_3.14.7 |
NIST SP 800-171 R2 3.14.7 |
System and Information Integrity |
Identify unauthorized use of organizational systems. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
System monitoring includes external and internal monitoring. System monitoring can detect unauthorized use of organizational systems. System monitoring is an integral part of continuous monitoring and incident response programs. Monitoring is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software). Output from system monitoring serves as input to continuous monitoring and incident response programs. Unusual/unauthorized activities or conditions related to inbound and outbound communications traffic include internal traffic that indicates the presence of malicious code in systems or propagating among system components, the unauthorized exporting of information, or signaling to external systems. Evidence of malicious code is used to identify potentially compromised systems or system components. System monitoring requirements, including the need for specific types of system monitoring, may be referenced in other requirements. [SP 800-94] provides guidance on intrusion detection and prevention systems. |
link |
20 |
NIST_SP_800-171_R2_3 |
.3.1 |
NIST_SP_800-171_R2_3.3.1 |
NIST SP 800-171 R2 3.3.1 |
Audit and Accountability |
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
An event is any observable occurrence in a system, which includes unlawful or unauthorized system activity. Organizations identify event types for which a logging functionality is needed as those events which are significant and relevant to the security of systems and the environments in which those systems operate to meet specific and ongoing auditing needs. Event types can include password changes, failed logons or failed accesses related to systems, administrative privilege usage, or third-party credential usage. In determining event types that require logging, organizations consider the monitoring and auditing appropriate for each of the CUI security requirements. Monitoring and auditing requirements can be balanced with other system needs. For example, organizations may determine that systems must have the capability to log every file access both successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance. Audit records can be generated at various levels of abstraction, including at the packet level as information traverses the network. Selecting the appropriate level of abstraction is a critical aspect of an audit logging capability and can facilitate the identification of root causes to problems. Organizations consider in the definition of event types, the logging necessary to cover related events such as the steps in distributed, transaction-based processes (e.g., processes that are distributed across multiple organizations) and actions that occur in service-oriented or cloud-based architectures. Audit record content that may be necessary to satisfy this requirement includes time stamps, source and destination addresses, user or process identifiers, event descriptions, success or fail indications, filenames involved, and access control or flow control rules invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the system after the event occurred). Detailed information that organizations may consider in audit records includes full text recording of privileged commands or the individual identities of group account users. Organizations consider limiting the additional audit log information to only that information explicitly needed for specific audit requirements. This facilitates the use of audit trails and audit logs by not including information that could potentially be misleading or could make it more difficult to locate information of interest. Audit logs are reviewed and analyzed as often as needed to provide important information to organizations to facilitate risk-based decision making. [SP 800-92] provides guidance on security log management. |
link |
50 |
NIST_SP_800-171_R2_3 |
.3.2 |
NIST_SP_800-171_R2_3.3.2 |
NIST SP 800-171 R2 3.3.2 |
Audit and Accountability |
Ensure that the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
This requirement ensures that the contents of the audit record include the information needed to link the audit event to the actions of an individual to the extent feasible. Organizations consider logging for traceability including results from monitoring of account usage, remote access, wireless connectivity, mobile device connection, communications at system boundaries, configuration settings, physical access, nonlocal maintenance, use of maintenance tools, temperature and humidity, equipment delivery and removal, system component inventory, use of mobile code, and use of Voice over Internet Protocol (VoIP). |
link |
36 |
NIST_SP_800-171_R3_3 |
.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. |
|
24 |
NIST_SP_800-171_R3_3 |
.12.5 |
NIST_SP_800-171_R3_3.12.5 |
NIST 800-171 R3 3.12.5 |
Security Assessment Control |
Information Exchange |
Shared |
The types of agreements selected are based on factors such as the relationship between the organizations exchanging information (e.g., government to government, government to business, business to business, government or business to service provider, government or business to individual) and the level of access to the organizational system by users of the other system. Types of agreements can include interconnection security agreements, information exchange security agreements, memoranda of understanding or agreement, service-level agreements, or other types of agreements. Organizations may incorporate agreement information into formal contracts, especially for information exchanges established between federal agencies and nonfederal organizations (e.g., service providers, contractors, system developers, and system integrators). Examples of the types of information contained in exchange agreements include the interface characteristics, security requirements, controls, and responsibilities for each system. |
a. Approve and manage the exchange of CUI between the system and other systems using [Selection (one or more): interconnection security agreements; information exchange security agreements; memoranda of understanding or agreement; service level agreements; user agreements; nondisclosure agreements].
b. Document, as part of the exchange agreements, interface characteristics, security requirements, and responsibilities for each system.
c. Review and update the exchange agreements periodically. |
|
25 |
NIST_SP_800-171_R3_3 |
.16.2 |
NIST_SP_800-171_R3_3.16.2 |
NIST 800-171 R3 3.16.2 |
System and Services Acquisition Control |
Unsupported System Components |
Shared |
Support for system components includes software patches, firmware updates, replacement parts, and maintenance contracts. An example of unsupported components includes when vendors no longer provide critical software patches or product updates, which can result in opportunities for adversaries to exploit weaknesses or deficiencies in the installed components. Exceptions to replacing unsupported system components include systems that provide critical mission or business capabilities when newer technologies are unavailable or when the systems are so isolated that installing replacement components is not an option.
Alternative sources for support address the need to provide continued support for system components that are no longer supported by the original manufacturers, developers, or vendors when such components remain essential to organizational mission and business functions. If necessary, organizations can establish in-house support by developing customized patches for critical software components or obtain the services of external providers who provide ongoing support for the designated unsupported components through contractual relationships. Such contractual relationships can include open-source software value-added vendors. The increased risk of using unsupported system components can be mitigated, for example, by prohibiting the connection of such components to public or uncontrolled networks or implementing other forms of isolation. |
a. Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer.
b. Provide options for risk mitigation or alternative sources for continued support for unsupported components if components cannot be replaced. |
|
1 |
NIST_SP_800-171_R3_3 |
.4.10 |
NIST_SP_800-171_R3_3.4.10 |
NIST 800-171 R3 3.4.10 |
Configuration Management Control |
System Component Inventory |
Shared |
System components are discrete, identifiable assets (i.e., hardware, software, and firmware elements) that compose a system. Organizations may implement centralized system component inventories that include components from all systems. In such situations, organizations ensure that the inventories include system-specific information required for component accountability. The information necessary for effective accountability of system components includes the system name, software owners, software version numbers, hardware inventory specifications, software license information — and for networked components — the machine names and network addresses for all implemented protocols (e.g., IPv4, IPv6). Inventory specifications include component type, physical location, date of receipt, manufacturer, cost, model, serial number, and supplier information. |
a. Develop and document an inventory of system components.
b. Review and update the system component inventory periodically.
c. Update the system component inventory as part of installations, removals, and system updates. |
|
8 |
NIST_SP_800-171_R3_3 |
.4.2 |
NIST_SP_800-171_R3_3.4.2 |
404 not found |
|
|
|
n/a |
n/a |
|
14 |
NIST_SP_800-171_R3_3 |
.4.5 |
NIST_SP_800-171_R3_3.4.5 |
404 not found |
|
|
|
n/a |
n/a |
|
3 |
NIST_SP_800-171_R3_3 |
.5.1 |
NIST_SP_800-171_R3_3.5.1 |
404 not found |
|
|
|
n/a |
n/a |
|
10 |
NIST_SP_800-53_R4 |
AU-12 |
NIST_SP_800-53_R4_AU-12 |
NIST SP 800-53 Rev. 4 AU-12 |
Audit And Accountability |
Audit Generation |
Shared |
n/a |
The information system:
a. Provides audit record generation capability for the auditable events defined in AU-2 a. at [Assignment: organization-defined information system components];
b. Allows [Assignment: organization-defined personnel or roles] to select which auditable events are to be audited by specific components of the information system; and
c. Generates audit records for the events defined in AU-2 d. with the content defined in AU-3.
Supplemental Guidance: Audit records can be generated from many different information system components. The list of audited events is the set of events for which audits are to be generated. These events are typically a subset of all events for which the information system is capable of generating audit records. Related controls: AC-3, AU-2, AU-3, AU-6, AU-7.
References: None. |
link |
34 |
NIST_SP_800-53_R4 |
AU-12(1) |
NIST_SP_800-53_R4_AU-12(1) |
NIST SP 800-53 Rev. 4 AU-12 (1) |
Audit And Accountability |
System-Wide / Time-Correlated Audit Trail |
Shared |
n/a |
The information system compiles audit records from [Assignment: organization-defined information system components] into a system-wide (logical or physical) audit trail that is time- correlated to within [Assignment: organization-defined level of tolerance for relationship between time stamps of individual records in the audit trail].
Supplemental Guidance: Audit trails are time-correlated if the time stamps in the individual audit records can be reliably related to the time stamps in other audit records to achieve a time ordering of the records within organizational tolerances. Related controls: AU-8, AU-12. |
link |
31 |
NIST_SP_800-53_R4 |
AU-6(4) |
NIST_SP_800-53_R4_AU-6(4) |
NIST SP 800-53 Rev. 4 AU-6 (4) |
Audit And Accountability |
Central Review And Analysis |
Shared |
n/a |
The information system provides the capability to centrally review and analyze audit records from multiple components within the system.
Supplemental Guidance: Automated mechanisms for centralized reviews and analyses include, for example, Security Information Management products. Related controls: AU-2, AU-12. |
link |
30 |
NIST_SP_800-53_R4 |
AU-6(5) |
NIST_SP_800-53_R4_AU-6(5) |
NIST SP 800-53 Rev. 4 AU-6 (5) |
Audit And Accountability |
Integration / Scanning And Monitoring Capabilities |
Shared |
n/a |
The organization integrates analysis of audit records with analysis of [Selection (one or more): vulnerability scanning information; performance data; information system monitoring information; [Assignment: organization-defined data/information collected from other sources]] to further enhance the ability to identify inappropriate or unusual activity.
Supplemental Guidance: This control enhancement does not require vulnerability scanning, the generation of performance data, or information system monitoring. Rather, the enhancement requires that the analysis of information being otherwise produced in these areas is integrated with the analysis of audit information. Security Event and Information Management System tools can facilitate audit record aggregation/consolidation from multiple information system components as well as audit record correlation and analysis. The use of standardized audit record analysis scripts developed by organizations (with localized script adjustments, as necessary) provides more cost-effective approaches for analyzing audit record information collected. The correlation of audit record information with vulnerability scanning information is important in determining the veracity of vulnerability scans and correlating attack detection events with scanning results. Correlation with performance data can help uncover denial of service attacks or cyber attacks resulting in unauthorized use of resources. Correlation with system monitoring information can assist in uncovering attacks and in better relating audit information to operational situations. Related controls: AU-12, IR-4, RA-5. |
link |
31 |
NIST_SP_800-53_R4 |
SI-4 |
NIST_SP_800-53_R4_SI-4 |
NIST SP 800-53 Rev. 4 SI-4 |
System And Information Integrity |
Information System Monitoring |
Shared |
n/a |
The organization:
a. Monitors the information system to detect:
1. Attacks and indicators of potential attacks in accordance with [Assignment: organization- defined monitoring objectives]; and
2. Unauthorized local, network, and remote connections;
b. Identifies unauthorized use of the information system through [Assignment: organization- defined techniques and methods];
c. Deploys monitoring devices: (i) strategically within the information system to collect organization-determined essential information; and (ii) at ad hoc locations within the system to track specific types of transactions of interest to the organization;
d. Protects information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion;
e. Heightens the level of information system monitoring activity whenever there is an indication of increased risk to organizational operations and assets, individuals, other organizations, or the Nation based on law enforcement information, intelligence information, or other credible sources of information;
f. Obtains legal opinion with regard to information system monitoring activities in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations; and
g. Provides [Assignment: or ganization-defined information system monitoring information] to [Assignment: organization-defined personnel or roles] [Selection (one or more): as needed; [Assignment: organization-defined frequency]].
Supplemental Guidance: Information system monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at the information system boundary (i.e., part of perimeter defense and boundary protection). Internal monitoring includes the observation of events occurring within the information system. Organizations can monitor information systems, for example, by observing audit activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives may guide determination of the events. Information system monitoring capability is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software). Strategic locations for monitoring devices include, for example, selected perimeter locations and near server farms supporting critical applications, with such devices typically being employed at the managed interfaces associated with controls SC-7 and AC-17. Einstein network monitoring devices from the Department of Homeland Security can also be included as monitoring devices. The granularity of monitoring information collected is based on organizational monitoring objectives and the capability of information systems to support such objectives. Specific types of transactions of interest include, for example, Hyper Text Transfer Protocol (HTTP) traffic that bypasses HTTP proxies. Information system monitoring is an integral part of organizational continuous monitoring and incident response programs. Output from system monitoring serves as input to continuous monitoring and incident response programs. A network connection is any connection with a device that communicates through a network (e.g., local area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Local, network, and remote connections can be either wired or wireless. Related controls: AC-3, AC-4, AC-8, AC-17, AU-2, AU-6, AU-7, AU-9, AU-12, CA-7, IR-4, PE-3, RA-5, SC-7, SC-26, SC-35, SI-3, SI-7.
References: NIST Special Publications 800-61, 800-83, 800-92, 800-94, 800-137. |
link |
22 |
NIST_SP_800-53_R5.1.1 |
AC.6 |
NIST_SP_800-53_R5.1.1_AC.6 |
NIST SP 800-53 R5.1.1 AC.6 |
Access Control |
Least Privilege |
Shared |
Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks. |
Organizations employ least privilege for specific duties and systems. The principle of least privilege is also applied to system processes, ensuring that the processes have access to systems and operate at privilege levels no higher than necessary to accomplish organizational missions or business functions. Organizations consider the creation of additional processes, roles, and accounts as necessary to achieve least privilege. Organizations apply least privilege to the development, implementation, and operation of organizational systems. |
|
25 |
NIST_SP_800-53_R5.1.1 |
CM.5 |
NIST_SP_800-53_R5.1.1_CM.5 |
NIST SP 800-53 R5.1.1 CM.5 |
Configuration Management Control |
Access Restrictions for Change |
Shared |
Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system. |
Changes to the hardware, software, or firmware components of systems or the operational procedures related to the system can potentially have significant effects on the security of the systems or individuals’ privacy. Therefore, organizations permit only qualified and authorized individuals to access systems for purposes of initiating changes. Access restrictions include physical and logical access controls (see AC-3 and PE-3), software libraries, workflow automation, media libraries, abstract layers (i.e., changes implemented into external interfaces rather than directly into systems), and change windows (i.e., changes occur only during specified times). |
|
3 |
NIST_SP_800-53_R5.1.1 |
CM.6 |
NIST_SP_800-53_R5.1.1_CM.6 |
NIST SP 800-53 R5.1.1 CM.6 |
Configuration Management Control |
Configuration Settings |
Shared |
a. Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using [Assignment: organization-defined common secure configurations];
b. Implement the configuration settings;
c. Identify, document, and approve any deviations from established configuration settings for [Assignment: organization-defined system components] based on [Assignment: organization-defined operational requirements]; and
d. Monitor and control changes to the configuration settings in accordance with organizational policies and procedures. |
Configuration settings are the parameters that can be changed in the hardware, software, or firmware components of the system that affect the security and privacy posture or functionality of the system. Information technology products for which configuration settings can be defined include mainframe computers, servers, workstations, operating systems, mobile devices, input/output devices, protocols, and applications. Parameters that impact the security posture of systems include registry settings; account, file, or directory permission settings; and settings for functions, protocols, ports, services, and remote connections. Privacy parameters are parameters impacting the privacy posture of systems, including the parameters required to satisfy other privacy controls. Privacy parameters include settings for access controls, data processing preferences, and processing and retention permissions. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for systems. The established settings become part of the configuration baseline for the system.
Common secure configurations (also known as security configuration checklists, lockdown and hardening guides, and security reference guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for information technology products and platforms as well as instructions for configuring those products or platforms to meet operational requirements. Common secure configurations can be developed by a variety of organizations, including information technology product developers, manufacturers, vendors, federal agencies, consortia, academia, industry, and other organizations in the public and private sectors.
Implementation of a common secure configuration may be mandated at the organization level, mission and business process level, system level, or at a higher level, including by a regulatory agency. Common secure configurations include the United States Government Configuration Baseline [USGCB] and security technical implementation guides (STIGs), which affect the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol provide an effective method to uniquely identify, track, and control configuration settings. |
|
12 |
NIST_SP_800-53_R5.1.1 |
CM.8 |
NIST_SP_800-53_R5.1.1_CM.8 |
NIST SP 800-53 R5.1.1 CM.8 |
Configuration Management Control |
System Component Inventory |
Shared |
a. Develop and document an inventory of system components that:
1. Accurately reflects the system;
2. Includes all components within the system;
3. Does not include duplicate accounting of components or components assigned to any other system;
4. Is at the level of granularity deemed necessary for tracking and reporting; and
5. Includes the following information to achieve system component accountability: [Assignment: organization-defined information deemed necessary to achieve effective system component accountability]; and
b. Review and update the system component inventory [Assignment: organization-defined frequency]. |
System components are discrete, identifiable information technology assets that include hardware, software, and firmware. Organizations may choose to implement centralized system component inventories that include components from all organizational systems. In such situations, organizations ensure that the inventories include system-specific information required for component accountability. The information necessary for effective accountability of system components includes the system name, software owners, software version numbers, hardware inventory specifications, software license information, and for networked components, the machine names and network addresses across all implemented protocols (e.g., IPv4, IPv6). Inventory specifications include date of receipt, cost, model, serial number, manufacturer, supplier information, component type, and physical location.
Preventing duplicate accounting of system components addresses the lack of accountability that occurs when component ownership and system association is not known, especially in large or complex connected systems. Effective prevention of duplicate accounting of system components necessitates use of a unique identifier for each component. For software inventory, centrally managed software that is accessed via other systems is addressed as a component of the system on which it is installed and managed. Software installed on multiple organizational systems and managed at the system level is addressed for each individual system and may appear more than once in a centralized component inventory, necessitating a system association for each software instance in the centralized inventory to avoid duplicate accounting of components. Scanning systems implementing multiple network protocols (e.g., IPv4 and IPv6) can result in duplicate components being identified in different address spaces. The implementation of CM-8(7) can help to eliminate duplicate accounting of components. |
|
7 |
NIST_SP_800-53_R5.1.1 |
IA.8 |
NIST_SP_800-53_R5.1.1_IA.8 |
NIST SP 800-53 R5.1.1 IA.8 |
Identification and Authentication Control |
Identification and Authentication (non-organizational Users) |
Shared |
Uniquely identify and authenticate non-organizational users or processes acting on behalf of non-organizational users. |
Non-organizational users include system users other than organizational users explicitly covered by IA-2. Non-organizational users are uniquely identified and authenticated for accesses other than those explicitly identified and documented in AC-14. Identification and authentication of non-organizational users accessing federal systems may be required to protect federal, proprietary, or privacy-related information (with exceptions noted for national security systems). Organizations consider many factors—including security, privacy, scalability, and practicality—when balancing the need to ensure ease of use for access to federal information and systems with the need to protect and adequately mitigate risk. |
|
2 |
NIST_SP_800-53_R5.1.1 |
SA.22 |
NIST_SP_800-53_R5.1.1_SA.22 |
NIST SP 800-53 R5.1.1 SA.22 |
System and Services Acquisition Control |
Unsupported System Components |
Shared |
a. Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or
b. Provide the following options for alternative sources for continued support for unsupported components [Selection (one or more): in-house support;
[Assignment: organization-defined support from external providers]
]. |
Support for system components includes software patches, firmware updates, replacement parts, and maintenance contracts. An example of unsupported components includes when vendors no longer provide critical software patches or product updates, which can result in an opportunity for adversaries to exploit weaknesses in the installed components. Exceptions to replacing unsupported system components include systems that provide critical mission or business capabilities where newer technologies are not available or where the systems are so isolated that installing replacement components is not an option.
Alternative sources for support address the need to provide continued support for system components that are no longer supported by the original manufacturers, developers, or vendors when such components remain essential to organizational mission and business functions. If necessary, organizations can establish in-house support by developing customized patches for critical software components or, alternatively, obtain the services of external providers who provide ongoing support for the designated unsupported components through contractual relationships. Such contractual relationships can include open-source software value-added vendors. The increased risk of using unsupported system components can be mitigated, for example, by prohibiting the connection of such components to public or uncontrolled networks, or implementing other forms of isolation. |
|
1 |
NIST_SP_800-53_R5 |
AU-12 |
NIST_SP_800-53_R5_AU-12 |
NIST SP 800-53 Rev. 5 AU-12 |
Audit and Accountability |
Audit Record Generation |
Shared |
n/a |
a. Provide audit record generation capability for the event types the system is capable of auditing as defined in [AU-2a](#au-2_smt.a) on [Assignment: organization-defined system components];
b. Allow [Assignment: organization-defined personnel or roles] to select the event types that are to be logged by specific components of the system; and
c. Generate audit records for the event types defined in [AU-2c](#au-2_smt.c) that include the audit record content defined in [AU-3](#au-3). |
link |
34 |
NIST_SP_800-53_R5 |
AU-12(1) |
NIST_SP_800-53_R5_AU-12(1) |
NIST SP 800-53 Rev. 5 AU-12 (1) |
Audit and Accountability |
System-wide and Time-correlated Audit Trail |
Shared |
n/a |
Compile audit records from [Assignment: organization-defined system components] into a system-wide (logical or physical) audit trail that is time-correlated to within [Assignment: organization-defined level of tolerance for the relationship between time stamps of individual records in the audit trail]. |
link |
31 |
NIST_SP_800-53_R5 |
AU-6(4) |
NIST_SP_800-53_R5_AU-6(4) |
NIST SP 800-53 Rev. 5 AU-6 (4) |
Audit and Accountability |
Central Review and Analysis |
Shared |
n/a |
Provide and implement the capability to centrally review and analyze audit records from multiple components within the system. |
link |
30 |
NIST_SP_800-53_R5 |
AU-6(5) |
NIST_SP_800-53_R5_AU-6(5) |
NIST SP 800-53 Rev. 5 AU-6 (5) |
Audit and Accountability |
Integrated Analysis of Audit Records |
Shared |
n/a |
Integrate analysis of audit records with analysis of [Selection (OneOrMore): vulnerability scanning information;performance data;system monitoring information; [Assignment: organization-defined data/information collected from other sources] ] to further enhance the ability to identify inappropriate or unusual activity. |
link |
31 |
NIST_SP_800-53_R5 |
SI-4 |
NIST_SP_800-53_R5_SI-4 |
NIST SP 800-53 Rev. 5 SI-4 |
System and Information Integrity |
System Monitoring |
Shared |
n/a |
a. Monitor the system to detect:
1. Attacks and indicators of potential attacks in accordance with the following monitoring objectives: [Assignment: organization-defined monitoring objectives]; and
2. Unauthorized local, network, and remote connections;
b. Identify unauthorized use of the system through the following techniques and methods: [Assignment: organization-defined techniques and methods];
c. Invoke internal monitoring capabilities or deploy monitoring devices:
1. Strategically within the system to collect organization-determined essential information; and
2. At ad hoc locations within the system to track specific types of transactions of interest to the organization;
d. Analyze detected events and anomalies;
e. Adjust the level of system monitoring activity when there is a change in risk to organizational operations and assets, individuals, other organizations, or the Nation;
f. Obtain legal opinion regarding system monitoring activities; and
g. Provide [Assignment: organization-defined system monitoring information] to [Assignment: organization-defined personnel or roles] [Selection (OneOrMore): as needed; [Assignment: organization-defined frequency] ] . |
link |
22 |
NL_BIO_Cloud_Theme |
U.15.1(2) |
NL_BIO_Cloud_Theme_U.15.1(2) |
NL_BIO_Cloud_Theme_U.15.1(2) |
U.15 Logging and monitoring |
Events Logged |
|
n/a |
The malware protection is carried out on various environments, such as on mail servers, (desktop) computers and when accessing the organization's network. The scan for malware includes: all files received over networks or through any form of storage medium, even before use; all attachments and downloads even before use; virtual machines; network traffic. |
|
46 |
NZ_ISM_v3.5 |
SS-3 |
NZ_ISM_v3.5_SS-3 |
NZISM Security Benchmark SS-3 |
Software security |
14.1.9 Maintaining hardened SOEs |
Customer |
n/a |
Whilst a SOE can be sufficiently hardened when it is deployed, its security will progressively degrade over time. Agencies can address the degradation of the security of a SOE by ensuring that patches are continually applied, system users are not able to disable or bypass security functionality and antivirus and other security software is appropriately maintained with the latest signatures and updates.
End Point Agents monitor traffic and apply security policies on applications, storage interfaces and data in real-time. Administrators actively block or monitor and log policy breaches. The End Point Agent can also create forensic monitoring to facilitate incident investigation.
End Point Agents can monitor user activity, such as the cut, copy, paste, print, print screen operations and copying data to external drives and other devices. The Agent can then apply policies to limit such activity. |
link |
15 |
NZISM_v3.7 |
16.1.33.C.01. |
NZISM_v3.7_16.1.33.C.01. |
NZISM v3.7 16.1.33.C.01. |
Identification, Authentication and Passwords |
16.1.33.C.01. - To promote security and accountability within the agency's systems. |
Shared |
n/a |
Agencies MUST NOT use shared credentials to access accounts. |
|
25 |
NZISM_v3.7 |
16.1.33.C.02. |
NZISM_v3.7_16.1.33.C.02. |
NZISM v3.7 16.1.33.C.02. |
Identification, Authentication and Passwords |
16.1.33.C.02. - To promote security and accountability within the agency's systems. |
Shared |
n/a |
Agencies SHOULD NOT use shared credentials to access accounts. |
|
25 |
NZISM_v3.7 |
16.1.34.C.01. |
NZISM_v3.7_16.1.34.C.01. |
NZISM v3.7 16.1.34.C.01. |
Identification, Authentication and Passwords |
16.1.34.C.01. - To promote security and accountability within the agency's systems. |
Shared |
n/a |
If agencies choose to allow shared, non user-specific accounts they MUST ensure that an independent means of determining the identification of the system user is implemented. |
|
25 |
NZISM_v3.7 |
16.1.35.C.02. |
NZISM_v3.7_16.1.35.C.02. |
NZISM v3.7 16.1.35.C.02. |
Identification, Authentication and Passwords |
16.1.35.C.02. - To implement additional authentication factors to enhance security.
|
Shared |
n/a |
Agencies SHOULD ensure that they combine the use of multiple methods when identifying and authenticating system users. |
|
25 |
NZISM_v3.7 |
16.1.36.C.01. |
NZISM_v3.7_16.1.36.C.01. |
NZISM v3.7 16.1.36.C.01. |
Identification, Authentication and Passwords |
16.1.36.C.01. - To enhance overall security posture. |
Shared |
n/a |
Agencies MUST NOT allow storage of unprotected authentication information that grants system access, or decrypts an encrypted device, to be located on, or with the system or device, to which the authentication information grants access. |
|
17 |
NZISM_v3.7 |
16.1.37.C.01. |
NZISM_v3.7_16.1.37.C.01. |
NZISM v3.7 16.1.37.C.01. |
Identification, Authentication and Passwords |
16.1.37.C.01. - To enhance overall security posture. |
Shared |
n/a |
Agencies MUST ensure that system authentication data is protected when in transit on agency networks or All-of-Government systems. |
|
17 |
NZISM_v3.7 |
16.1.39.C.01. |
NZISM_v3.7_16.1.39.C.01. |
NZISM v3.7 16.1.39.C.01. |
Identification, Authentication and Passwords |
16.1.39.C.01. - To enhance overall security posture. |
Shared |
n/a |
Where systems contain NZEO or other nationalities releasability marked or protectively marked information, agencies MUST provide a mechanism that allows system users and processes to identify users who are foreign nationals, including seconded foreign nationals. |
|
17 |
NZISM_v3.7 |
16.1.39.C.02. |
NZISM_v3.7_16.1.39.C.02. |
NZISM v3.7 16.1.39.C.02. |
Identification, Authentication and Passwords |
16.1.39.C.02. - To enhance overall security posture. |
Shared |
n/a |
Agencies using NZEO systems SHOULD ensure that identification includes specific nationality for all foreign nationals, including seconded foreign nationals. |
|
17 |
NZISM_v3.7 |
16.1.41.C.02. |
NZISM_v3.7_16.1.41.C.02. |
NZISM v3.7 16.1.41.C.02. |
Identification, Authentication and Passwords |
16.1.41.C.02. - To enhance overall security posture. |
Shared |
n/a |
Agencies MUST NOT:
1. allow predictable reset passwords;
2. reuse passwords when resetting multiple accounts;
3. store passwords in the clear on the system;
4. allow passwords to be reused within eight password changes; and
5. allow system users to use sequential passwords. |
|
17 |
NZISM_v3.7 |
16.1.43.C.01. |
NZISM_v3.7_16.1.43.C.01. |
NZISM v3.7 16.1.43.C.01. |
Identification, Authentication and Passwords |
16.1.43.C.01. - To enhance overall security posture. |
Shared |
n/a |
Agencies SHOULD disable LAN Manager for password authentication on workstations and servers. |
|
17 |
NZISM_v3.7 |
16.1.48.C.02. |
NZISM_v3.7_16.1.48.C.02. |
NZISM v3.7 16.1.48.C.02. |
Identification, Authentication and Passwords |
16.1.48.C.02. - To enhance overall security posture. |
Shared |
n/a |
Agencies SHOULD seek legal advice on the exact wording of logon banners. |
|
16 |
NZISM_v3.7 |
16.1.49.C.01. |
NZISM_v3.7_16.1.49.C.01. |
NZISM v3.7 16.1.49.C.01. |
Identification, Authentication and Passwords |
16.1.49.C.01. - To enhance overall security posture. |
Shared |
n/a |
Agencies SHOULD configure systems to display the date and time of the system user's previous login during the login process. |
|
15 |
NZISM_v3.7 |
16.1.50.C.01. |
NZISM_v3.7_16.1.50.C.01. |
NZISM v3.7 16.1.50.C.01. |
Identification, Authentication and Passwords |
16.1.50.C.01. - To enhance overall security posture. |
Shared |
n/a |
Agencies SHOULD NOT permit the display of last logged on username, credentials or other identifying details. |
|
15 |
NZISM_v3.7 |
16.1.50.C.02. |
NZISM_v3.7_16.1.50.C.02. |
NZISM v3.7 16.1.50.C.02. |
Identification, Authentication and Passwords |
16.1.50.C.02. - To enhance overall security posture. |
Shared |
n/a |
Agencies SHOULD NOT permit the caching of credentials unless specifically required. |
|
15 |
NZISM_v3.7 |
16.2.3.C.01. |
NZISM_v3.7_16.2.3.C.01. |
NZISM v3.7 16.2.3.C.01. |
System Access and Passwords |
16.2.3.C.01. - To enhance overall security posture. |
Shared |
n/a |
Agencies MUST NOT allow access to NZEO information from systems and facilities not under the sole control of the government of New Zealand and New Zealand citizens. |
|
14 |
NZISM_v3.7 |
16.2.3.C.02. |
NZISM_v3.7_16.2.3.C.02. |
NZISM v3.7 16.2.3.C.02. |
System Access and Passwords |
16.2.3.C.02. - To enhance overall security posture. |
Shared |
n/a |
Unless a multilateral or bilateral security agreement is in place, agencies SHOULD NOT allow access to classified information from systems and facilities not under the sole control of the government of New Zealand and New Zealand citizens. |
|
11 |
PCI_DSS_v4.0.1 |
2.2.1 |
PCI_DSS_v4.0.1_2.2.1 |
PCI DSS v4.0.1 2.2.1 |
Apply Secure Configurations to All System Components |
Configuration standards are developed, implemented, and maintained to cover all system components, address all known security vulnerabilities, be consistent with industry-accepted system hardening standards or vendor hardening recommendations, be updated as new vulnerability issues are identified, and be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment |
Shared |
n/a |
Examine system configuration standards to verify they define processes that include all elements specified in this requirement. Examine policies and procedures and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.3.1. Examine configuration settings and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before or immediately after a system component is connected to a production environment |
|
15 |
PCI_DSS_v4.0.1 |
7.2.1 |
PCI_DSS_v4.0.1_7.2.1 |
PCI DSS v4.0.1 7.2.1 |
Restrict Access to System Components and Cardholder Data by Business Need to Know |
An access control model is defined and includes granting access as follows: Appropriate access depending on the entity’s business and access needs. Access to system components and data resources that is based on users’ job classification and functions. The least privileges required (for example, user, administrator) to perform a job function |
Shared |
n/a |
Examine documented policies and procedures and interview personnel to verify the access control model is defined in accordance with all elements specified in this requirement. Examine access control model settings and verify that access needs are appropriately defined in accordance with all elements specified in this requirement |
|
43 |
PCI_DSS_v4.0.1 |
7.2.2 |
PCI_DSS_v4.0.1_7.2.2 |
PCI DSS v4.0.1 7.2.2 |
Restrict Access to System Components and Cardholder Data by Business Need to Know |
Access is assigned to users, including privileged users, based on: Job classification and function. Least privileges necessary to perform job responsibilities |
Shared |
n/a |
Examine policies and procedures to verify they cover assigning access to users in accordance with all elements specified in this requirement. Examine user access settings, including for privileged users, and interview responsible management personnel to verify that privileges assigned are in accordance with all elements specified in this requirement. Interview personnel responsible for assigning access to verify that privileged user access is assigned in accordance with all elements specified in this requirement |
|
43 |
PCI_DSS_v4.0.1 |
7.2.5 |
PCI_DSS_v4.0.1_7.2.5 |
PCI DSS v4.0.1 7.2.5 |
Restrict Access to System Components and Cardholder Data by Business Need to Know |
All application and system accounts and related access privileges are assigned and managed as follows: Based on the least privileges necessary for the operability of the system or application. Access is limited to the systems, applications, or processes that specifically require their use |
Shared |
n/a |
Examine policies and procedures to verify they define processes to manage and assign application and system accounts and related access privileges in accordance with all elements specified in this requirement. Examine privileges associated with system and application accounts and interview responsible personnel to verify that application and system accounts and related access privileges are assigned and managed in accordance with all elements specified in this requirement |
|
44 |
PCI_DSS_v4.0.1 |
7.2.6 |
PCI_DSS_v4.0.1_7.2.6 |
PCI DSS v4.0.1 7.2.6 |
Restrict Access to System Components and Cardholder Data by Business Need to Know |
All user access to query repositories of stored cardholder data is restricted as follows: Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges. Only the responsible administrator(s) can directly access or query repositories of stored CHD |
Shared |
n/a |
Examine policies and procedures and interview personnel to verify processes are defined for granting user access to query repositories of stored cardholder data, in accordance with all elements specified in this requirement. Examine configuration settings for querying repositories of stored cardholder data to verify they are in accordance with all elements specified in this requirement |
|
41 |
PCI_DSS_v4.0.1 |
7.3.1 |
PCI_DSS_v4.0.1_7.3.1 |
PCI DSS v4.0.1 7.3.1 |
Restrict Access to System Components and Cardholder Data by Business Need to Know |
An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components |
Shared |
n/a |
Examine vendor documentation and system settings to verify that access is managed for each system component via an access control system(s) that restricts access based on a user’s need to know and covers all system components |
|
27 |
PCI_DSS_v4.0.1 |
9.5.1 |
PCI_DSS_v4.0.1_9.5.1 |
PCI DSS v4.0.1 9.5.1 |
Restrict Physical Access to Cardholder Data |
Protection Measures for POI Devices Against Tampering and Unauthorized Substitution |
Shared |
n/a |
POI devices that capture payment card data via direct physical interaction with the payment card form factor are protected from tampering and unauthorized substitution, including the following:
• Maintaining a list of POI devices.
• Periodically inspecting POI devices to look for tampering or unauthorized substitution.
• Training personnel to be aware of suspicious behavior and to report tampering or unauthorized substitution of devices. |
|
10 |
PCI_DSS_v4.0.1 |
9.5.1.1 |
PCI_DSS_v4.0.1_9.5.1.1 |
PCI DSS v4.0.1 9.5.1.1 |
Restrict Physical Access to Cardholder Data |
Maintenance of an Up-to-Date List of POI Devices |
Shared |
n/a |
An up-to-date list of POI devices is maintained, including:
• Make and model of the device.
• Location of device.
• Device serial number or other methods of unique identification. |
|
8 |
RBI_CSF_Banks_v2016 |
13.1 |
RBI_CSF_Banks_v2016_13.1 |
|
Advanced Real-Timethreat Defenceand Management |
Advanced Real-Timethreat Defenceand Management-13.1 |
|
n/a |
Build a robust defence against the installation, spread, and execution of malicious code at multiple points in the enterprise. |
|
21 |
RBI_CSF_Banks_v2016 |
17.1 |
RBI_CSF_Banks_v2016_17.1 |
|
Audit Log Settings |
Audit Log Settings-17.1 |
|
n/a |
Implement and periodically validate settings for capturing of appropriate logs/audit trails of each device, system software and application software , ensuring that logs include minimum information to uniquely identify the log for example by including a date, timestamp, source addresses, destination addresses, and various other useful elements of each packet and/or event and/or transaction. |
|
14 |
RBI_CSF_Banks_v2016 |
8.4 |
RBI_CSF_Banks_v2016_8.4 |
|
User Access Control / Management |
User Access Control / Management-8.4 |
|
n/a |
Implement centralised authentication and authorisation system or accessing and administering applications, operating systems, databases, network and security devices/systems, point of connectivity (local/remote, etc.) including enforcement of strong password policy, two-factor/multi-factor authentication depending on risk assessment and following the principle of least privileges and separation of duties. |
|
3 |
RBI_ITF_NBFC_v2017 |
3.1.b |
RBI_ITF_NBFC_v2017_3.1.b |
RBI IT Framework 3.1.b |
Information and Cyber Security |
Segregation of Functions-3.1 |
|
n/a |
The IS Policy must provide for a IS framework with the following basic tenets:
Segregation of functions: There should be segregation of the duties of the Security Officer/Group (both physical security as well as cyber security) dealing exclusively with information systems security and the Information Technology division which actually implements the computer systems. The information security function should be adequately resourced in terms of the number of staff, level of skill and tools or techniques like risk assessment, security architecture, vulnerability assessment, forensic assessment, etc. Further, there should be a clear segregation of responsibilities relating to system administration, database administration and transaction processing. |
link |
6 |
RMiT_v1.0 |
10.54 |
RMiT_v1.0_10.54 |
RMiT 10.54 |
Access Control |
Access Control - 10.54 |
Shared |
n/a |
A financial institution must implement an appropriate access controls policy for the identification, authentication and authorisation of users (internal and external users such as third party service providers). This must address both logical and physical technology access controls which are commensurate with the level of risk of unauthorised access to its technology systems. |
link |
14 |
RMiT_v1.0 |
10.61 |
RMiT_v1.0_10.61 |
RMiT 10.61 |
Access Control |
Access Control - 10.61 |
Shared |
n/a |
A financial institution must ensure'
(a) access controls to enterprise-wide systems are effectively managed and monitored; and
(b) user activities in critical systems are logged for audit and investigations. Activity logs must be maintained for at least three years and regularly reviewed in a timely manner. |
link |
6 |
Sarbanes_Oxley_Act_(1)_2022_1 |
Sarbanes_Oxley_Act_(1)_2022_1 |
Sarbanes_Oxley_Act_(1)_2022_1 |
Sarbanes Oxley Act 2022 1 |
PUBLIC LAW |
Sarbanes Oxley Act 2022 (SOX) |
Shared |
n/a |
n/a |
|
92 |
SOC_2 |
CC6.8 |
SOC_2_CC6.8 |
SOC 2 Type 2 CC6.8 |
Logical and Physical Access Controls |
Prevent or detect against unauthorized or malicious software |
Shared |
The customer is responsible for implementing this recommendation. |
Restricts Application and Software Installation — The ability to install applications
and software is restricted to authorized individuals.
• Detects Unauthorized Changes to Software and Configuration Parameters — Processes are in place to detect changes to software and configuration parameters that
may be indicative of unauthorized or malicious software.
• Uses a Defined Change Control Process — A management-defined change control
process is used for the implementation of software.
• Uses Antivirus and Anti-Malware Software — Antivirus and anti-malware software
is implemented and maintained to provide for the interception or detection and remediation of malware.
• Scans Information Assets from Outside the Entity for Malware and Other Unauthorized Software — Procedures are in place to scan information assets that have been
transferred or returned to the entity’s custody for malware and other unauthorized
software and to remove any items detected prior to its implementation on the network. |
|
47 |
SOC_2 |
CC8.1 |
SOC_2_CC8.1 |
SOC 2 Type 2 CC8.1 |
Change Management |
Changes to infrastructure, data, and software |
Shared |
The customer is responsible for implementing this recommendation. |
Manages Changes Throughout the System Life Cycle — A process for managing
system changes throughout the life cycle of the system and its components (infrastructure, data, software, and procedures) is used to support system availability and
processing integrity.
• Authorizes Changes — A process is in place to authorize system changes prior to
development.
• Designs and Develops Changes — A process is in place to design and develop system changes.
• Documents Changes — A process is in place to document system changes to support ongoing maintenance of the system and to support system users in performing
their responsibilities.
• Tracks System Changes — A process is in place to track system changes prior to
implementation.
• Configures Software — A process is in place to select and implement the configuration parameters used to control the functionality of software.
• Tests System Changes — A process is in place to test system changes prior to implementation.
• Approves System Changes — A process is in place to approve system changes prior
to implementation.
• Deploys System Changes — A process is in place to implement system changes.
• Identifies and Evaluates System Changes — Objectives affected by system changes
are identified and the ability of the modified system to meet the objectives is evaluated throughout the system development life cycle.
• Identifies Changes in Infrastructure, Data, Software, and Procedures Required to
Remediate Incidents — Changes in infrastructure, data, software, and procedures
required to remediate incidents to continue to meet objectives are identified and the
change process is initiated upon identification.
• Creates Baseline Configuration of IT Technology — A baseline configuration of IT
and control systems is created and maintained.
• Provides for Changes Necessary in Emergency Situations — A process is in place
for authorizing, designing, testing, approving, and implementing changes necessary
in emergency situations (that is, changes that need to be implemented in an urgent
time frame).
Additional points of focus that apply only in an engagement using the trust services criteria for
confidentiality:
• Protects Confidential Information — The entity protects confidential information
during system design, development, testing, implementation, and change processes
to meet the entity’s objectives related to confidentiality.
Additional points of focus that apply only in an engagement using the trust services criteria for
privacy:
• Protects Personal Information — The entity protects personal information during
system design, development, testing, implementation, and change processes to meet
the entity’s objectives related to privacy. |
|
52 |
SOC_2023 |
CC1.4 |
SOC_2023_CC1.4 |
SOC 2023 CC1.4 |
Control Environment |
To ensure organizational resilience, innovation, and competitiveness in the long run. |
Shared |
n/a |
Entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives by establishing policies and procedures, evaluating the competence required and address its shortcomings, attracts, develops and retains individuals through mentoring and training and plan and prepare for succession by developing contingency plans for assignments of responsibilities important for internal control. |
|
8 |
SOC_2023 |
CC2.3 |
SOC_2023_CC2.3 |
SOC 2023 CC2.3 |
Information and Communication |
To facilitate effective internal communication. |
Shared |
n/a |
Entity to communicate with external parties regarding matters affecting the functioning of internal control. |
|
219 |
SOC_2023 |
CC5.3 |
SOC_2023_CC5.3 |
SOC 2023 CC5.3 |
Control Activities |
To maintain alignment with organizational objectives and regulatory requirements. |
Shared |
n/a |
Entity deploys control activities through policies that establish what is expected and in procedures that put policies into action by establishing Policies and Procedures to Support Deployment of Management’s Directives, Responsibility and Accountability for Executing Policies and Procedures, perform tasks in a timely manner, taking corrective actions, perform using competent personnel and reassess policies and procedures. |
|
230 |
SOC_2023 |
CC6.1 |
SOC_2023_CC6.1 |
SOC 2023 CC6.1 |
Logical and Physical Access Controls |
To 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. |
|
129 |
SOC_2023 |
CC6.2 |
SOC_2023_CC6.2 |
SOC 2023 CC6.2 |
Logical and Physical Access Controls |
To ensure effective access control and ensuring the security of the organization's systems and data. |
Shared |
n/a |
1. Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity.
2. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized. |
|
50 |
SOC_2023 |
CC6.3 |
SOC_2023_CC6.3 |
404 not found |
|
|
|
n/a |
n/a |
|
56 |
SOC_2023 |
CC6.7 |
SOC_2023_CC6.7 |
404 not found |
|
|
|
n/a |
n/a |
|
52 |
SOC_2023 |
CC7.2 |
SOC_2023_CC7.2 |
SOC 2023 CC7.2 |
Systems Operations |
To maintain robust security measures and ensure operational resilience. |
Shared |
n/a |
The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analysed to determine whether they represent security events. |
|
168 |
SOC_2023 |
CC7.4 |
SOC_2023_CC7.4 |
SOC 2023 CC7.4 |
Systems Operations |
To effectively manage security incidents, minimize their impact, and protect assets, operations, and reputation. |
Shared |
n/a |
The entity responds to identified security incidents by:
a. Executing a defined incident-response program to understand, contain, remediate, and communicate security incidents by assigning roles and responsibilities;
b. Establishing procedures to contain security incidents;
c. Mitigating ongoing security incidents, End Threats Posed by Security Incidents;
d. Restoring operations;
e. Developing and Implementing Communication Protocols for Security Incidents;
f. Obtains Understanding of Nature of Incident and Determines Containment Strategy;
g. Remediation Identified Vulnerabilities;
h. Communicating Remediation Activities; and,
i. Evaluating the Effectiveness of Incident Response and periodic incident evaluations. |
|
214 |
SOC_2023 |
CC8.1 |
SOC_2023_CC8.1 |
SOC 2023 CC8.1 |
Change Management |
To minimise risks, ensure quality, optimise efficiency, and enhance resilience in the face of change. |
Shared |
n/a |
The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives by Managing Changes Throughout the System Life Cycle, authorizing changes, designing and developing changes, documenting all changes, tracking system changes, configuring software's, testing system changes, approving system changes, deploying system changes, identifying and evaluating system changes, creating baseline configurations for IT technologies and providing necessary changes in emergency situations. |
|
148 |
SOC_2023 |
CM_8b |
SOC_2023_CM_8b |
404 not found |
|
|
|
n/a |
n/a |
|
7 |
SWIFT_CSCF_2024 |
1.2 |
SWIFT_CSCF_2024_1.2 |
SWIFT Customer Security Controls Framework 2024 1.2 |
Privileged Account Control |
Operating System Privileged Account Control |
Shared |
Tightly protecting administrator-level accounts within the operating system reduces the opportunity for an attacker to use the privileges of the account as part of an attack (for example, executing commands or deleting evidence). |
To restrict and control the allocation and usage of administrator-level operating system accounts. |
|
53 |
SWIFT_CSCF_2024 |
9.2 |
SWIFT_CSCF_2024_9.2 |
404 not found |
|
|
|
n/a |
n/a |
|
16 |
|
U.15.1 - Events logged |
U.15.1 - Events logged |
404 not found |
|
|
|
n/a |
n/a |
|
40 |
UK_NCSC_CAF_v3.2 |
B2.a |
UK_NCSC_CAF_v3.2_B2.a |
NCSC Cyber Assurance Framework (CAF) v3.2 B2.a |
Identity and Access Control |
Identity Verification, Authentication and Authorisation |
Shared |
1. The process of initial identity verification is robust enough to provide a high level of confidence of a user’s identity profile before allowing an authorised user access to networks and information systems that support the essential function.
2. Only authorised and individually authenticated users can physically access and logically connect to the networks or information systems on which that essential function depends.
3. The number of authorised users and systems that have access to all the networks and information systems supporting the essential function is limited to the minimum necessary.
4. Use additional authentication mechanisms, such as multi-factor (MFA), for privileged access to all systems that operate or support the essential function.
5. Use additional authentication mechanisms, such as multi-factor (MFA), when there is individual authentication and authorisation of all remote user access to all the networks and information systems that support the essential function.
6. The list of users and systems with access to networks and systems supporting and delivering the essential functions reviewed on a regular basis, at least every six months. |
The organisation understands, documents and manages access to networks and information systems supporting the operation of essential functions. Users (or automated functions) that can access data or systems are appropriately verified, authenticated and authorised. Robustly verify, authenticate and authorise access to the networks and information systems supporting the essential function. |
|
32 |
UK_NCSC_CAF_v3.2 |
B4.b |
UK_NCSC_CAF_v3.2_B4.b |
NCSC Cyber Assurance Framework (CAF) v3.2 B4.b |
System Security |
Secure Configuration |
Shared |
1. Identify, document and actively manage (e.g. maintain security configurations, patching, updating according to good practice) the assets that need to be carefully configured to maintain the security of the essential function.
2. All platforms conform to secure, defined baseline build, or the latest known good configuration version for that environment.
3. Closely and effectively manage changes in the environment, ensuring that network and system configurations are secure and documented.
4. Regularly review and validate that your network and information systems have the expected, secure settings and configuration.
5. Only permitted software can be installed and standard users cannot change settings that would impact security or the business operation.
6. If automated decision-making technologies are in use, their operation is well understood, and decisions can be replicated. |
Securely configure the network and information systems that support the operation of essential functions. |
|
37 |