compliance controls are associated with this Policy definition 'Kubernetes cluster pod hostPath volumes should only use allowed host paths' (098fc59e-46c7-4d99-9b16-64990e543d75)
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 |
CA_3 |
Canada_Federal_PBMM_3-1-2020_CA_3 |
Canada Federal PBMM 3-1-2020 CA 3 |
Information System Connections |
System Interconnections |
Shared |
1. The organization authorizes connection from information system to other information system through the use of Interconnection Security Agreements.
2. The organization documents, for each interconnection, the interface characteristics, security requirements, and the nature of the information communicated.
3. The organization reviews and updates Interconnection Security Agreements annually. |
To establish and maintain secure connections between information systems. |
|
77 |
Canada_Federal_PBMM_3-1-2020 |
CA_3(3) |
Canada_Federal_PBMM_3-1-2020_CA_3(3) |
Canada Federal PBMM 3-1-2020 CA 3(3) |
Information System Connections |
System Interconnections | Classified Non-National Security System Connections |
Shared |
The organization prohibits the direct connection of any internal network or system to an external network without the use of security controls approved by the information owner. |
To ensure the integrity and security of internal systems against external threats. |
|
77 |
Canada_Federal_PBMM_3-1-2020 |
CA_3(5) |
Canada_Federal_PBMM_3-1-2020_CA_3(5) |
Canada Federal PBMM 3-1-2020 CA 3(5) |
Information System Connections |
System Interconnections | Restrictions on External Network Connections |
Shared |
The organization employs allow-all, deny-by-exception; deny-all policy for allowing any systems to connect to external information systems. |
To enhance security posture against unauthorized access. |
|
77 |
Canada_Federal_PBMM_3-1-2020 |
CA_7 |
Canada_Federal_PBMM_3-1-2020_CA_7 |
Canada Federal PBMM 3-1-2020 CA 7 |
Continuous Monitoring |
Continuous Monitoring |
Shared |
1. The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes establishment of organization-defined metrics to be monitored.
2. The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes establishment of at least monthly monitoring and assessments of at least operating system scans, database, and web application scan.
3. The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes ongoing security control assessments in accordance with the organizational continuous monitoring strategy.
4. The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes ongoing security status monitoring of organization-defined metrics in accordance with the organizational continuous monitoring strategy.
5. The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes correlation and analysis of security-related information generated by assessments and monitoring.
6. The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes response actions to address results of the analysis of security-related information.
7. The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes reporting the security status of organization and the information system to organization-defined personnel or roles at organization-defined frequency. |
To ensure the ongoing effectiveness of security controls and maintain the security posture in alignment with organizational objectives and requirements. |
|
125 |
Canada_Federal_PBMM_3-1-2020 |
SI_3 |
Canada_Federal_PBMM_3-1-2020_SI_3 |
Canada Federal PBMM 3-1-2020 SI 3 |
Malicious Code Protection |
Malicious Code Protection |
Shared |
1. The organization employs malicious code protection mechanisms at information system entry and exit points to detect and eradicate malicious code.
2. The organization updates malicious code protection mechanisms whenever new releases are available in accordance with organizational configuration management policy and procedures.
3. The organization configures malicious code protection mechanisms to:
a. Perform periodic scans of the information system at least weekly and real-time scans of files from external sources at endpoints and network entry/exit points as the files are downloaded, opened, or executed in accordance with organizational security policy; and
b. Block and quarantine malicious code; send alert to the key role as defined in the system and information integrity policy in response to malicious code detection.
4. The organization addresses the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the information system. |
To mitigate potential impacts on system availability. |
|
52 |
Canada_Federal_PBMM_3-1-2020 |
SI_3(1) |
Canada_Federal_PBMM_3-1-2020_SI_3(1) |
Canada Federal PBMM 3-1-2020 SI 3(1) |
Malicious Code Protection |
Malicious Code Protection | Central Management |
Shared |
The organization centrally manages malicious code protection mechanisms. |
To centrally manage malicious code protection mechanisms. |
|
51 |
Canada_Federal_PBMM_3-1-2020 |
SI_3(2) |
Canada_Federal_PBMM_3-1-2020_SI_3(2) |
Canada Federal PBMM 3-1-2020 SI 3(2) |
Malicious Code Protection |
Malicious Code Protection | Automatic Updates |
Shared |
The information system automatically updates malicious code protection mechanisms. |
To ensure automatic updates in malicious code protection mechanisms. |
|
51 |
Canada_Federal_PBMM_3-1-2020 |
SI_3(7) |
Canada_Federal_PBMM_3-1-2020_SI_3(7) |
Canada Federal PBMM 3-1-2020 SI 3(7) |
Malicious Code Protection |
Malicious Code Protection | Non Signature-Based Detection |
Shared |
The information system implements non-signature-based malicious code detection mechanisms. |
To enhance overall security posture.
|
|
51 |
Canada_Federal_PBMM_3-1-2020 |
SI_4 |
Canada_Federal_PBMM_3-1-2020_SI_4 |
Canada Federal PBMM 3-1-2020 SI 4 |
Information System Monitoring |
Information System Monitoring |
Shared |
1. The organization monitors the information system to detect:
a. Attacks and indicators of potential attacks in accordance with organization-defined monitoring objectives; and
b. Unauthorized local, network, and remote connections;
2. The organization identifies unauthorized use of the information system through organization-defined techniques and methods.
3. The organization 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.
4. The organization protects information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion.
5. The organization 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 Canada based on law enforcement information, intelligence information, or other credible sources of information.
6. The organization obtains legal opinion with regard to information system monitoring activities in accordance with organizational policies, directives and standards.
7. The organization provides organization-defined information system monitoring information to organization-defined personnel or roles at an organization-defined frequency. |
To enhance overall security posture.
|
|
95 |
Canada_Federal_PBMM_3-1-2020 |
SI_4(1) |
Canada_Federal_PBMM_3-1-2020_SI_4(1) |
Canada Federal PBMM 3-1-2020 SI 4(1) |
Information System Monitoring |
Information System Monitoring | System-Wide Intrusion Detection System |
Shared |
The organization connects and configures individual intrusion detection tools into an information system-wide intrusion detection system. |
To enhance overall security posture.
|
|
95 |
Canada_Federal_PBMM_3-1-2020 |
SI_4(2) |
Canada_Federal_PBMM_3-1-2020_SI_4(2) |
Canada Federal PBMM 3-1-2020 SI 4(2) |
Information System Monitoring |
Information System Monitoring | Automated Tools for Real-Time Analysis |
Shared |
The organization employs automated tools to support near real-time analysis of events. |
To enhance overall security posture.
|
|
94 |
Canada_Federal_PBMM_3-1-2020 |
SI_8(1) |
Canada_Federal_PBMM_3-1-2020_SI_8(1) |
Canada Federal PBMM 3-1-2020 SI 8(1) |
Spam Protection |
Spam Protection | Central Management of Protection Mechanisms |
Shared |
The organization centrally manages spam protection mechanisms. |
To enhance overall security posture. |
|
88 |
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 |
CMMC_L2_v1.9.0 |
SC.L1_3.13.1 |
CMMC_L2_v1.9.0_SC.L1_3.13.1 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 SC.L1 3.13.1 |
System and Communications Protection |
Boundary Protection |
Shared |
Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems. |
To protect information assets from external attacks and insider threats. |
|
43 |
CMMC_L2_v1.9.0 |
SC.L1_3.13.5 |
CMMC_L2_v1.9.0_SC.L1_3.13.5 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 SC.L1 3.13.5 |
System and Communications Protection |
Public Access System Separation |
Shared |
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. |
To control access, monitor traffic, and mitigate the risk of unauthorized access or exploitation of internal resources. |
|
43 |
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 |
DSP_05 |
CSA_v4.0.12_DSP_05 |
CSA Cloud Controls Matrix v4.0.12 DSP 05 |
Data Security and Privacy Lifecycle Management |
Data Flow Documentation |
Shared |
n/a |
Create data flow documentation to identify what data is processed,
stored or transmitted where. Review data flow documentation at defined intervals,
at least annually, and after any change. |
|
57 |
CSA_v4.0.12 |
DSP_10 |
CSA_v4.0.12_DSP_10 |
CSA Cloud Controls Matrix v4.0.12 DSP 10 |
Data Security and Privacy Lifecycle Management |
Sensitive Data Transfer |
Shared |
n/a |
Define, implement and evaluate processes, procedures and technical
measures that ensure any transfer of personal or sensitive data is protected
from unauthorized access and only processed within scope as permitted by the
respective laws and regulations. |
|
45 |
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 |
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 |
FFIEC_CAT_2017 |
4.1.1 |
FFIEC_CAT_2017_4.1.1 |
FFIEC CAT 2017 4.1.1 |
External Dependency Management |
Connections |
Shared |
n/a |
- The critical business processes that are dependent on external connectivity have been identified.
- The institution ensures that third-party connections are authorized.
- A network diagram is in place and identifies all external connections.
- Data flow diagrams are in place and document information flow to external parties. |
|
43 |
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 |
.13.1 |
NIST_SP_800-171_R3_3.13.1 |
NIST 800-171 R3 3.13.1 |
System and Communications Protection Control |
Boundary Protection |
Shared |
Managed interfaces include gateways, routers, firewalls, network-based malicious code analysis, virtualization systems, and encrypted tunnels implemented within a security architecture. Subnetworks that are either physically or logically separated from internal networks are referred to as demilitarized zones or DMZs. Restricting or prohibiting interfaces within organizational systems includes restricting external web traffic to designated web servers within managed interfaces, prohibiting external traffic that appears to be spoofing internal addresses, and prohibiting internal traffic that appears to be spoofing external addresses. |
a. Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system.
b. Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
c. Connect to external systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture. |
|
43 |
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.1.1 |
CM.7 |
NIST_SP_800-53_R5.1.1_CM.7 |
NIST SP 800-53 R5.1.1 CM.7 |
Configuration Management Control |
Least Functionality |
Shared |
a. Configure the system to provide only [Assignment: organization-defined mission essential capabilities]; and
b. Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: [Assignment: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services]. |
Systems provide a wide variety of functions and services. Some of the functions and services routinely provided by default may not be necessary to support essential organizational missions, functions, or operations. Additionally, it is sometimes convenient to provide multiple services from a single system component, but doing so increases risk over limiting the services provided by that single component. Where feasible, organizations limit component functionality to a single function per component. Organizations consider removing unused or unnecessary software and disabling unused or unnecessary physical and logical ports and protocols to prevent unauthorized connection of components, transfer of information, and tunneling. Organizations employ network scanning tools, intrusion detection and prevention systems, and end-point protection technologies, such as firewalls and host-based intrusion detection systems, to identify and prevent the use of prohibited functions, protocols, ports, and services. Least functionality can also be achieved as part of the fundamental design and development of the system (see SA-8, SC-2, and SC-3). |
|
17 |
NIST_SP_800-53_R5.1.1 |
SC.7 |
NIST_SP_800-53_R5.1.1_SC.7 |
NIST SP 800-53 R5.1.1 SC.7 |
System and Communications Protection |
Boundary Protection |
Shared |
a. Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system;
b. Implement subnetworks for publicly accessible system components that are [Selection: physically; logically] separated from internal organizational networks; and
c. Connect to external networks or systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security and privacy architecture. |
Managed interfaces include gateways, routers, firewalls, guards, network-based malicious code analysis, virtualization systems, or encrypted tunnels implemented within a security architecture. Subnetworks that are physically or logically separated from internal networks are referred to as demilitarized zones or DMZs. Restricting or prohibiting interfaces within organizational systems includes restricting external web traffic to designated web servers within managed interfaces, prohibiting external traffic that appears to be spoofing internal addresses, and prohibiting internal traffic that appears to be spoofing external addresses. Commercial telecommunications services are provided by network components and consolidated management systems shared by customers. These services may also include third party-provided access lines and other service elements. Such services may represent sources of increased risk despite contract security provisions. Boundary protection may be implemented as a common control for all or part of an organizational network such that the boundary to be protected is greater than a system-specific boundary (i.e., an authorization boundary). |
|
43 |
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 |
NZISM_v3.7 |
12.4.4.C.02. |
NZISM_v3.7_12.4.4.C.02. |
NZISM v3.7 12.4.4.C.02. |
Product Patching and Updating |
12.4.4.C.02. - To minimise the risk of disruptions or vulnerabilities introduced by the patches. |
Shared |
n/a |
Agencies MUST implement a patch management strategy, including an evaluation or testing process. |
|
28 |
NZISM_v3.7 |
12.4.4.C.04. |
NZISM_v3.7_12.4.4.C.04. |
NZISM v3.7 12.4.4.C.04. |
Product Patching and Updating |
12.4.4.C.04. - To mitigate the risk of exploitation by malicious actors and to ensure the ongoing security and integrity of the agency's IT systems and data. |
Shared |
n/a |
Agencies SHOULD apply all critical security patches as soon as possible and preferably within two (2) days of the release of the patch or update. |
|
28 |
NZISM_v3.7 |
12.4.4.C.05. |
NZISM_v3.7_12.4.4.C.05. |
NZISM v3.7 12.4.4.C.05. |
Product Patching and Updating |
12.4.4.C.05. - To reduce the potential attack surface for malicious actors. |
Shared |
n/a |
Agencies SHOULD apply all non-critical security patches as soon as possible. |
|
26 |
NZISM_v3.7 |
12.4.4.C.06. |
NZISM_v3.7_12.4.4.C.06. |
NZISM v3.7 12.4.4.C.06. |
Product Patching and Updating |
12.4.4.C.06. - To maintain the integrity and effectiveness of the patching process. |
Shared |
n/a |
Agencies SHOULD ensure that security patches are applied through a vendor recommended patch or upgrade process. |
|
25 |
NZISM_v3.7 |
14.1.8.C.01. |
NZISM_v3.7_14.1.8.C.01. |
NZISM v3.7 14.1.8.C.01. |
Standard Operating Environments |
14.1.8.C.01. - To minimise vulnerabilities and enhance system security |
Shared |
n/a |
Agencies SHOULD develop a hardened SOE for workstations and servers, covering:
1. removal of unneeded software and operating system components;
2. removal or disabling of unneeded services, ports and BIOS settings;
3. disabling of unused or undesired functionality in software and operating systems;
4. implementation of access controls on relevant objects to limit system users and programs to the minimum access required;
5. installation of antivirus and anti-malware software;
6. installation of software-based firewalls limiting inbound and outbound network connections;
7. configuration of either remote logging or the transfer of local event logs to a central server; and
8. protection of audit and other logs through the use of a one way pipe to reduce likelihood of compromise key transaction records. |
|
31 |
NZISM_v3.7 |
14.3.10.C.01. |
NZISM_v3.7_14.3.10.C.01. |
NZISM v3.7 14.3.10.C.01. |
Web Applications |
14.3.10.C.01. - To maintain control over network traffic and reduces the likelihood of exposure to malicious content or activities. |
Shared |
n/a |
Agencies SHOULD implement allow listing for all HTTP traffic being communicated through their gateways. |
|
24 |
NZISM_v3.7 |
14.3.10.C.02. |
NZISM_v3.7_14.3.10.C.02. |
NZISM v3.7 14.3.10.C.02. |
Web Applications |
14.3.10.C.02. - To maintain control over network traffic and reduces the likelihood of exposure to malicious content or activities. |
Shared |
n/a |
Agencies using an allow list on their gateways to specify the external addresses, to which encrypted connections are permitted, SHOULD specify allow list addresses by domain name or IP address. |
|
23 |
NZISM_v3.7 |
14.3.10.C.03. |
NZISM_v3.7_14.3.10.C.03. |
NZISM v3.7 14.3.10.C.03. |
Web Applications |
14.3.10.C.03. - To maintain control over network traffic and reduces the likelihood of exposure to malicious content or activities. |
Shared |
n/a |
If agencies do not allow list websites they SHOULD deny list websites to prevent access to known malicious websites. |
|
22 |
NZISM_v3.7 |
14.3.10.C.04. |
NZISM_v3.7_14.3.10.C.04. |
NZISM v3.7 14.3.10.C.04. |
Web Applications |
14.3.10.C.04. - To maintain control over network traffic and reduces the likelihood of exposure to malicious content or activities. |
Shared |
n/a |
Agencies deny listing websites SHOULD update the deny list on a frequent basis to ensure that it remains effective. |
|
22 |
NZISM_v3.7 |
17.8.10.C.01. |
NZISM_v3.7_17.8.10.C.01. |
NZISM v3.7 17.8.10.C.01. |
Internet Protocol Security (IPSec) |
17.8.10.C.01. - To enhance overall cybersecurity posture. |
Shared |
n/a |
Agencies SHOULD use tunnel mode for IPSec connections. |
|
22 |
NZISM_v3.7 |
17.8.10.C.02. |
NZISM_v3.7_17.8.10.C.02. |
NZISM v3.7 17.8.10.C.02. |
Internet Protocol Security (IPSec) |
17.8.10.C.02. - To enhance overall cybersecurity posture. |
Shared |
n/a |
Agencies choosing to use transport mode SHOULD additionally use an IP tunnel for IPSec connections. |
|
35 |
NZISM_v3.7 |
19.1.10.C.01. |
NZISM_v3.7_19.1.10.C.01. |
NZISM v3.7 19.1.10.C.01. |
Gateways |
19.1.10.C.01. - To ensure that the security requirements are consistently upheld throughout the network hierarchy, from the lowest to the highest networks. |
Shared |
n/a |
When agencies have cascaded connections between networks involving multiple gateways they MUST ensure that the assurance levels specified for network devices between the overall lowest and highest networks are met by the gateway between the highest network and the next highest network within the cascaded connection. |
|
50 |
NZISM_v3.7 |
19.1.11.C.01. |
NZISM_v3.7_19.1.11.C.01. |
NZISM v3.7 19.1.11.C.01. |
Gateways |
19.1.11.C.01. - To ensure network protection through gateway mechanisms. |
Shared |
n/a |
Agencies MUST ensure that:
1. all agency networks are protected from networks in other security domains by one or more gateways;
2. all gateways contain mechanisms to filter or limit data flow at the network and content level to only the information necessary for business purposes; and
3. all gateway components, discrete and virtual, are physically located within an appropriately secured server room. |
|
49 |
NZISM_v3.7 |
19.1.11.C.02. |
NZISM_v3.7_19.1.11.C.02. |
NZISM v3.7 19.1.11.C.02. |
Gateways |
19.1.11.C.02. - To maintain security and integrity across domains. |
Shared |
n/a |
For gateways between networks in different security domains, any shared components MUST be managed by the system owners of the highest security domain or by a mutually agreed party. |
|
48 |
NZISM_v3.7 |
22.3.11.C.01. |
NZISM_v3.7_22.3.11.C.01. |
NZISM v3.7 22.3.11.C.01. |
Virtual Local Area Networks |
22.3.11.C.01. - To ensure data security and integrity. |
Shared |
n/a |
Unused ports on the switches MUST be disabled. |
|
18 |
NZISM_v3.7 |
22.3.11.C.02. |
NZISM_v3.7_22.3.11.C.02. |
NZISM v3.7 22.3.11.C.02. |
Virtual Local Area Networks |
22.3.11.C.02. - To ensure data security and integrity. |
Shared |
n/a |
Unused ports on the switches SHOULD be disabled. |
|
18 |
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 |
1.4.4 |
PCI_DSS_v4.0.1_1.4.4 |
PCI DSS v4.0.1 1.4.4 |
Install and Maintain Network Security Controls |
System components that store cardholder data are not directly accessible from untrusted networks |
Shared |
n/a |
Examine the data-flow diagram and network diagram to verify that it is documented that system components storing cardholder data are not directly accessible from the untrusted networks. Examine configurations of NSCs to verify that controls are implemented such that system components storing cardholder data are not directly accessible from untrusted networks |
|
43 |
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 |
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 |
SWIFT_CSCF_2024 |
1.1 |
SWIFT_CSCF_2024_1.1 |
SWIFT Customer Security Controls Framework 2024 1.1 |
Physical and Environmental Security |
Swift Environment Protection |
Shared |
1. Segmentation between the user's Swift infrastructure and the larger enterprise network reduces the attack surface and has shown to be an effective way to defend against cyber-attacks that commonly involve a compromise of the general enterprise IT environment.
2. Effective segmentation includes network-level separation, access restrictions, and connectivity restrictions. |
To ensure the protection of the user’s Swift infrastructure from potentially compromised elements of the general IT environment and external environment. |
|
69 |
SWIFT_CSCF_2024 |
1.5 |
SWIFT_CSCF_2024_1.5 |
SWIFT Customer Security Controls Framework 2024 1.5 |
Physical and Environmental Security |
Customer Environment Protection |
Shared |
1. Segmentation between the customer’s connectivity infrastructure and its larger enterprise network reduces the attack surface and has shown to be an effective way to defend against cyber-attacks that commonly involve compromise of the general enterprise IT environment.
2. Effective segmentation will include network-level separation, access restrictions, and connectivity restrictions. |
To ensure the protection of the customer’s connectivity infrastructure from external environment and potentially compromised elements of the general IT environment. |
|
57 |
SWIFT_CSCF_2024 |
9.1 |
SWIFT_CSCF_2024_9.1 |
404 not found |
|
|
|
n/a |
n/a |
|
57 |