compliance controls are associated with this Policy definition 'Kubernetes clusters should not allow container privilege escalation' (1c6e92c9-99f0-4e55-9cf2-0c234dc48f99)
Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
Azure_Security_Benchmark_v2.0 |
PV-2 |
Azure_Security_Benchmark_v2.0_PV-2 |
Azure Security Benchmark PV-2 |
Posture and Vulnerability Management |
Sustain secure configurations for Azure services |
Customer |
Use Azure Security Center to monitor your configuration baseline and use Azure Policy [deny] and [deploy if not exist] rule to enforce secure configuration across Azure compute resources, including VMs, containers, and others.
Understand Azure Policy effects: https://docs.microsoft.com/azure/governance/policy/concepts/effects
Create and manage policies to enforce compliance: https://docs.microsoft.com/azure/governance/policy/tutorials/create-and-manage |
n/a |
link |
19 |
Azure_Security_Benchmark_v3.0 |
PV-2 |
Azure_Security_Benchmark_v3.0_PV-2 |
Microsoft cloud security benchmark PV-2 |
Posture and Vulnerability Management |
Audit and enforce secure configurations |
Shared |
**Security Principle:**
Continuously monitor and alert when there is a deviation from the defined configuration baseline. Enforce the desired configuration according to the baseline configuration by denying the non-compliant configuration or deploy a configuration.
**Azure Guidance:**
Use Microsoft Defender for Cloud to configure Azure Policy to audit and enforce configurations of your Azure resources. Use Azure Monitor to create alerts when there is a configuration deviation detected on the resources.
Use Azure Policy [deny] and [deploy if not exist] rule to enforce secure configuration across Azure resources.
For resource configuration audit and enforcement not supported by Azure Policy, you may need to write your own scripts or use third-party tooling to implement the configuration audit and enforcement.
**Implementation and additional context:**
Understand Azure Policy effects:
https://docs.microsoft.com/azure/governance/policy/concepts/effects
Create and manage policies to enforce compliance:
https://docs.microsoft.com/azure/governance/policy/tutorials/create-and-manage
Get compliance data of Azure resources:
https://docs.microsoft.com/azure/governance/policy/how-to/get-compliance-data |
n/a |
link |
27 |
|
C.04.7 - Evaluated |
C.04.7 - Evaluated |
404 not found |
|
|
|
n/a |
n/a |
|
39 |
Canada_Federal_PBMM_3-1-2020 |
AC_11(1) |
Canada_Federal_PBMM_3-1-2020_AC_11(1) |
Canada Federal PBMM 3-1-2020 AC 11(1) |
Session Lock |
Session Lock | Pattern-Hiding Displays |
Shared |
The information system conceals, via the session lock, information previously visible on the display with a publicly viewable image. |
To ensure the confidentiality and integrity of the data. |
|
1 |
Canada_Federal_PBMM_3-1-2020 |
CM_5 |
Canada_Federal_PBMM_3-1-2020_CM_5 |
Canada Federal PBMM 3-1-2020 CM 5 |
Access Restrictions for Change |
Access Restrictions for Change |
Shared |
The organization defines, documents, approves, and enforces physical and logical access restrictions associated with changes to the information system. |
To ensure controlled and secure access throughout the change process. |
|
1 |
Canada_Federal_PBMM_3-1-2020 |
CM_5(1) |
Canada_Federal_PBMM_3-1-2020_CM_5(1) |
Canada Federal PBMM 3-1-2020 CM 5(1) |
Access Restrictions for Change |
Access Restrictions for Change | Automated Access Enforcement / Auditing |
Shared |
The information system enforces access restrictions and supports auditing of the enforcement actions. |
To ensure accountability and transparency in access control measures. |
|
1 |
CIS_Controls_v8.1 |
4.1 |
CIS_Controls_v8.1_4.1 |
CIS Controls v8.1 4.1 |
Secure Configuration of Enterprise Assets and Software |
Establish and maintain a secure configuration process. |
Shared |
1. Establish and maintain a secure configuration process for enterprise assets (end-user devices, including portable and mobile; non-computing/IoT devices; and servers) and software (operating systems and applications).
2. Review and update documentation annually, or when significant enterprise changes occur that could impact this safeguard. |
To ensure data integrity and safety of enterprise assets. |
|
44 |
CMMC_2.0_L2 |
CM.L2-3.4.1 |
CMMC_2.0_L2_CM.L2-3.4.1 |
404 not found |
|
|
|
n/a |
n/a |
|
25 |
CMMC_2.0_L2 |
CM.L2-3.4.2 |
CMMC_2.0_L2_CM.L2-3.4.2 |
404 not found |
|
|
|
n/a |
n/a |
|
27 |
CSA_v4.0.12 |
CCC_03 |
CSA_v4.0.12_CCC_03 |
CSA Cloud Controls Matrix v4.0.12 CCC 03 |
Change Control and Configuration Management |
Change Management Technology |
Shared |
n/a |
Manage the risks associated with applying changes to organization
assets, including application, systems, infrastructure, configuration, etc.,
regardless of whether the assets are managed internally or externally (i.e.,
outsourced). |
|
31 |
CSA_v4.0.12 |
CCC_04 |
CSA_v4.0.12_CCC_04 |
CSA Cloud Controls Matrix v4.0.12 CCC 04 |
Change Control and Configuration Management |
Unauthorized Change Protection |
Shared |
n/a |
Restrict the unauthorized addition, removal, update, and management
of organization assets. |
|
25 |
CSA_v4.0.12 |
IAM_07 |
CSA_v4.0.12_IAM_07 |
CSA Cloud Controls Matrix v4.0.12 IAM 07 |
Identity & Access Management |
User Access Changes and Revocation |
Shared |
n/a |
De-provision or respectively modify access of movers / leavers or
system identity changes in a timely manner in order to effectively adopt and
communicate identity and access management policies. |
|
56 |
CSA_v4.0.12 |
TVM_04 |
CSA_v4.0.12_TVM_04 |
CSA Cloud Controls Matrix v4.0.12 TVM 04 |
Threat & Vulnerability Management |
Detection Updates |
Shared |
n/a |
Define, implement and evaluate processes, procedures and technical
measures to update detection tools, threat signatures, and indicators of compromise
on a weekly, or more frequent basis. |
|
50 |
Cyber_Essentials_v3.1 |
1 |
Cyber_Essentials_v3.1_1 |
Cyber Essentials v3.1 1 |
Cyber Essentials |
Firewalls |
Shared |
n/a |
Aim: to make sure that only secure and necessary network services can be accessed from the internet. |
|
37 |
Cyber_Essentials_v3.1 |
3 |
Cyber_Essentials_v3.1_3 |
Cyber Essentials v3.1 3 |
Cyber Essentials |
Security Update Management |
Shared |
n/a |
Aim: ensure that devices and software are not vulnerable to known security issues for which fixes are available. |
|
38 |
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 |
Cyber_Essentials_v3.1 |
5 |
Cyber_Essentials_v3.1_5 |
Cyber Essentials v3.1 5 |
Cyber Essentials |
Malware protection |
Shared |
n/a |
Aim: to restrict execution of known malware and untrusted software, from causing damage or accessing data. |
|
60 |
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 |
FedRAMP_High_R4 |
CM-6 |
FedRAMP_High_R4_CM-6 |
FedRAMP High CM-6 |
Configuration Management |
Configuration Settings |
Shared |
n/a |
The organization:
a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements;
b. Implements the configuration settings;
c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and
d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures.
Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline.
Common secure configurations (also referred to as security configuration checklists, lockdown
and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects 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 (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4.
References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. |
link |
23 |
FedRAMP_Moderate_R4 |
CM-6 |
FedRAMP_Moderate_R4_CM-6 |
FedRAMP Moderate CM-6 |
Configuration Management |
Configuration Settings |
Shared |
n/a |
The organization:
a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements;
b. Implements the configuration settings;
c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and
d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures.
Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline.
Common secure configurations (also referred to as security configuration checklists, lockdown
and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects 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 (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4.
References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. |
link |
23 |
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 |
HITRUST_CSF_v11.3 |
01.l |
HITRUST_CSF_v11.3_01.l |
HITRUST CSF v11.3 01.l |
Network Access Control |
To prevent unauthorized access to networked services. |
Shared |
Ports, services, and applications installed on a computer or network systems, which are not specifically required for business functionality, to be disabled or removed. |
Physical and logical access to diagnostic and configuration ports shall be controlled. |
|
26 |
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 |
09.j |
HITRUST_CSF_v11.3_09.j |
HITRUST CSF v11.3 09.j |
Protection Against Malicious and Mobile Code |
To ensure that integrity of information and software is protected from malicious or unauthorized code |
Shared |
1. Technologies are to be implemented for timely installation, upgrade and renewal of anti-malware protective measures.
2. Automatic periodic scans of information systems is to be implemented.
3. Anti-malware software that offers a centralized infrastructure that compiles information on file reputations is to be implemented.
4. Post-malicious code update, signature deployment, scanning files, email, and web traffic is to be verified by automated systems, while BYOD users require anti-malware, network-based malware detection is to be used on servers without host-based solutions use.
5. Anti-malware audit logs checks to be performed.
6. Protection against malicious code is to be based on malicious code detection and repair software, security awareness, appropriate system access, and change management controls. |
Detection, prevention, and recovery controls shall be implemented to protect against malicious code, and appropriate user awareness procedures on malicious code shall be provided. |
|
37 |
HITRUST_CSF_v11.3 |
09.m |
HITRUST_CSF_v11.3_09.m |
HITRUST CSF v11.3 09.m |
Network Security Management |
To ensure the protection of information in networks and protection of the supporting network infrastructure. |
Shared |
1. Vendor default encryption keys, default SNMP community strings on wireless devices, default passwords/passphrases on access points, and other security-related wireless vendor defaults is to be changed prior to authorization of implementation of wireless access points.
2. Wireless encryption keys to be changed when anyone with knowledge of the keys leaves or changes.
3. All authorized and unauthorized wireless access to the information system is to be monitored and installation of wireless access points (WAP) is to be prohibited unless explicitly authorized. |
Networks shall be managed and controlled in order to protect the organization from threats and to maintain security for the systems and applications using the network, including information in transit. |
|
24 |
HITRUST_CSF_v11.3 |
10.m |
HITRUST_CSF_v11.3_10.m |
HITRUST CSF v11.3 10.m |
Technical Vulnerability Management |
To reduce the risks resulting from exploitation of published technical vulnerabilities, technical vulnerability management shall be implemented in an effective, systematic, and repeatable way with measurements taken to confirm its effectiveness. |
Shared |
1. The necessary secure services, protocols required for the function of the system are to be enabled.
2. Security features to be implemented for any required services that are considered to be insecure.
3. Laptops, workstations, and servers to be configured so they will not auto-run content from removable media.
4. Configuration standards to be consistent with industry-accepted system hardening standards.
5. An enterprise security posture review within every 365 days is to be conducted.
6. Vulnerability scanning tools to be regularly updated with all relevant information system vulnerabilities. |
Timely information about technical vulnerabilities of information systems being used shall be obtained; the organization’s exposure to such vulnerabilities evaluated; and appropriate measures taken to address the associated risk. |
|
47 |
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 |
NIST_SP_800-171_R2_3 |
.4.1 |
NIST_SP_800-171_R2_3.4.1 |
NIST SP 800-171 R2 3.4.1 |
Configuration Management |
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Baseline configurations are documented, formally reviewed, and agreed-upon specifications for systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and changes to systems. Baseline configurations include information about system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and update and patch information on operating systems and applications; and configuration settings and parameters), network topology, and the logical placement of those components within the system architecture. Baseline configurations of systems also reflect the current enterprise architecture. Maintaining effective baseline configurations requires creating new baselines as organizational systems change over time. Baseline configuration maintenance includes reviewing and updating the baseline configuration when changes are made based on security risks and deviations from the established baseline configuration. Organizations can implement centralized system component inventories that include components from multiple organizational systems. In such situations, organizations ensure that the resulting inventories include system-specific information required for proper component accountability (e.g., system association, system owner). Information deemed necessary for effective accountability of system components includes hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include manufacturer, device type, model, serial number, and physical location. [SP 800-128] provides guidance on security-focused configuration management. |
link |
31 |
NIST_SP_800-171_R2_3 |
.4.2 |
NIST_SP_800-171_R2_3.4.2 |
NIST SP 800-171 R2 3.4.2 |
Configuration Management |
Establish and enforce security configuration settings for information technology products employed in organizational systems. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture or functionality of the system. Information technology products for which security-related configuration settings can be defined include mainframe computers, servers, workstations, input and output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security parameters are those parameters impacting the security state of systems including the parameters required to satisfy other security requirements. Security parameters include: registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. [SP 800-70] and [SP 800-128] provide guidance on security configuration settings. |
link |
25 |
NIST_SP_800-171_R3_3 |
.4.6 |
NIST_SP_800-171_R3_3.4.6 |
404 not found |
|
|
|
n/a |
n/a |
|
24 |
NIST_SP_800-53_R4 |
CM-6 |
NIST_SP_800-53_R4_CM-6 |
NIST SP 800-53 Rev. 4 CM-6 |
Configuration Management |
Configuration Settings |
Shared |
n/a |
The organization:
a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements;
b. Implements the configuration settings;
c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and
d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures.
Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline.
Common secure configurations (also referred to as security configuration checklists, lockdown
and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects 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 (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4.
References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. |
link |
23 |
NIST_SP_800-53_R5 |
CM-6 |
NIST_SP_800-53_R5_CM-6 |
NIST SP 800-53 Rev. 5 CM-6 |
Configuration Management |
Configuration Settings |
Shared |
n/a |
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. |
link |
23 |
NL_BIO_Cloud_Theme |
C.04.7(2) |
NL_BIO_Cloud_Theme_C.04.7(2) |
NL_BIO_Cloud_Theme_C.04.7(2) |
C.04 Technical Vulnerability Management |
Evaluated |
|
n/a |
Evaluations of technical vulnerabilities are recorded and reported. |
|
41 |
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 |
1.2.5 |
PCI_DSS_v4.0.1_1.2.5 |
PCI DSS v4.0.1 1.2.5 |
Install and Maintain Network Security Controls |
All services, protocols, and ports allowed are identified, approved, and have a defined business need |
Shared |
n/a |
Examine documentation to verify that a list exists of all allowed services, protocols, and ports, including business justification and approval for each. Examine configuration settings for NSCs to verify that only approved services, protocols, and ports are in use |
|
19 |
PCI_DSS_v4.0.1 |
11.3.1.2 |
PCI_DSS_v4.0.1_11.3.1.2 |
PCI DSS v4.0.1 11.3.1.2 |
Test Security of Systems and Networks Regularly |
Authenticated Vulnerability Scans |
Shared |
n/a |
Internal vulnerability scans are performed via authenticated scanning as follows:
• Systems that are unable to accept credentials for authenticated scanning are documented.
• Sufficient privileges are used for those systems that accept credentials for scanning.
• If accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with Requirement 8.2.2. |
|
1 |
PCI_DSS_v4.0.1 |
2.2.4 |
PCI_DSS_v4.0.1_2.2.4 |
PCI DSS v4.0.1 2.2.4 |
Apply Secure Configurations to All System Components |
Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled |
Shared |
n/a |
Examine system configuration standards to verify necessary services, protocols, daemons, and functions are identified and documented. Examine system configurations to verify the following: All unnecessary functionality is removed or disabled. Only required functionality, as documented in the configuration standards, is enabled |
|
25 |
RMiT_v1.0 |
10.55 |
RMiT_v1.0_10.55 |
RMiT 10.55 |
Access Control |
Access Control - 10.55 |
Shared |
n/a |
In observing paragraph 10.54, a financial institution should consider the following principles in its access control policy:
(a) adopt a 'deny all' access control policy for users by default unless explicitly authorised;
(b) employ 'least privilege' access rights or on a 'need-to-have' basis where only the minimum sufficient permissions are granted to legitimate users to perform their roles;
(c) employ time-bound access rights which restrict access to a specific period including access rights granted to service providers;
(d) employ segregation of incompatible functions where no single person is responsible for an entire operation that may provide the ability to independently modify, circumvent, and disable system security features. This may include a combination of functions such as:
(i) system development and technology operations;
(ii) security administration and system administration; and
(iii) network operation and network security;"
(e) employ dual control functions which require two or more persons to execute an activity;
(f) adopt stronger authentication for critical activities including for remote access;
(g) limit and control the use of the same user ID for multiple concurrent sessions;
(h) limit and control the sharing of user ID and passwords across multiple users; and
(i) control the use of generic user ID naming conventions in favour of more personally identifiable IDs. |
link |
8 |
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 |