compliance controls are associated with this Policy definition 'Kubernetes cluster containers should only use allowed capabilities' (c26596ff-4d70-4e6a-9a30-c2506bd2f80c)
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 |
|
55 |
Canada_Federal_PBMM_3-1-2020 |
AC_1 |
Canada_Federal_PBMM_3-1-2020_AC_1 |
Canada Federal PBMM 3-1-2020 AC 1 |
Access Control Policy and Procedures |
Access Control Policy and Procedures |
Shared |
1. The organization develops, documents, and disseminates to personnel or roles with access control responsibilities:
a. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
b. Procedures to facilitate the implementation of the access control policy and associated access controls.
2. The organization reviews and updates the current:
a. Access control policy at least every 3 years; and
b. Access control procedures at least annually. |
To establish and maintain effective access control measures. |
|
16 |
Canada_Federal_PBMM_3-1-2020 |
AC_17(100) |
Canada_Federal_PBMM_3-1-2020_AC_17(100) |
Canada Federal PBMM 3-1-2020 AC 17(100) |
Remote Access |
Remote Access | Remote Access to Privileged Accounts using Dedicated Management Console |
Shared |
Remote access to privileged accounts is performed on dedicated management consoles governed entirely by the system’s security policies and used exclusively for this purpose (e.g. Internet access not allowed). |
To reduce the risk of unauthorized access or compromise of privileged accounts. |
|
16 |
Canada_Federal_PBMM_3-1-2020 |
AC_2(7) |
Canada_Federal_PBMM_3-1-2020_AC_2(7) |
Canada Federal PBMM 3-1-2020 AC 2(7) |
Account Management |
Account Management | Role-Based Schemes |
Shared |
1. The organization establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles;
2. The organization monitors privileged role assignments; and
3. The organization disables (or revokes) privileged user assignments within 24 hours or sooner when privileged role assignments are no longer appropriate. |
To strengthen the security posture and safeguard sensitive data and critical resources.
|
|
19 |
Canada_Federal_PBMM_3-1-2020 |
AC_2(9) |
Canada_Federal_PBMM_3-1-2020_AC_2(9) |
Canada Federal PBMM 3-1-2020 AC 2(9) |
Account Management |
Account Management | Restrictions on Use of Shared Groups / Accounts |
Shared |
The organization only permits the use of shared/group accounts that meet organization-defined conditions for establishing shared/group accounts. |
To maintain security and accountability. |
|
14 |
Canada_Federal_PBMM_3-1-2020 |
AC_3 |
Canada_Federal_PBMM_3-1-2020_AC_3 |
Canada Federal PBMM 3-1-2020 AC 3 |
Access Enforcement |
Access Enforcement |
Shared |
The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. |
To mitigate the risk of unauthorized access. |
|
33 |
Canada_Federal_PBMM_3-1-2020 |
AC_6 |
Canada_Federal_PBMM_3-1-2020_AC_6 |
Canada Federal PBMM 3-1-2020 AC 6 |
Least Privilege |
Least Privilege |
Shared |
The organization employs the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions. |
To mitigate the risk of unauthorized access, data breaches, and system compromises. |
|
17 |
Canada_Federal_PBMM_3-1-2020 |
AC_6(2) |
Canada_Federal_PBMM_3-1-2020_AC_6(2) |
Canada Federal PBMM 3-1-2020 AC 6(2) |
Least Privilege |
Least Privilege | Non-Privileged Access for Non-Security Functions |
Shared |
The organization requires that users of information system accounts, or roles, with access to any security function, use non-privileged accounts or roles, when accessing non-security functions. |
To enhance security measures and minimise the risk of unauthorized access or misuse of privileges. |
|
17 |
Canada_Federal_PBMM_3-1-2020 |
AU_9(4) |
Canada_Federal_PBMM_3-1-2020_AU_9(4) |
Canada Federal PBMM 3-1-2020 AU 9(4) |
Protection of Audit Information |
Protection of Audit Information | Access by Subset of Privileged Users |
Shared |
The organization authorizes access to management of audit functionality to only an organization-defined subset of privileged users. |
To enhance security and maintain the integrity of audit processes. |
|
8 |
Canada_Federal_PBMM_3-1-2020 |
CA_2(2) |
Canada_Federal_PBMM_3-1-2020_CA_2(2) |
Canada Federal PBMM 3-1-2020 CA 2(2) |
Security Assessments |
Security Assessments | Specialized Assessments |
Shared |
The organization includes as part of security control assessments that they will be announced and done at least annually and include at least vulnerability scanning and penetration testing. |
To comprehensively evaluate security controls and identify potential weaknesses or vulnerabilities in the information system. |
|
6 |
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. |
|
124 |
Canada_Federal_PBMM_3-1-2020 |
CP_4 |
Canada_Federal_PBMM_3-1-2020_CP_4 |
Canada Federal PBMM 3-1-2020 CP 4 |
Contingency Plan Testing and Exercises |
Contingency Plan Testing |
Shared |
1. The organization tests the contingency plan for the information system at least annually for moderate impact systems; at least every three years for low impact systems using organization-defined tests to determine the effectiveness of the plan and the organizational readiness to execute the plan.
2. The organization reviews the contingency plan test results.
3. The organization initiates corrective actions, if needed. |
To enhance preparedness and resilience. |
|
6 |
Canada_Federal_PBMM_3-1-2020 |
IR_9(1) |
Canada_Federal_PBMM_3-1-2020_IR_9(1) |
Canada Federal PBMM 3-1-2020 IR 9(1) |
Information Spillage Response |
Information Spillage Response | Responsible Personnel |
Shared |
The organization assigns incident response personnel as documented within the Incident Management Plan with responsibility for responding to information spills. |
To assign a personnel for information spillage response. |
|
6 |
Canada_Federal_PBMM_3-1-2020 |
IR_9(3) |
Canada_Federal_PBMM_3-1-2020_IR_9(3) |
Canada Federal PBMM 3-1-2020 IR 9(3) |
Information Spillage Response |
Information Spillage Response | Post-Spill Operations |
Shared |
The organization implements organization-defined procedures to ensure that organizational personnel impacted by information spills can continue to carry out assigned tasks while contaminated systems are undergoing corrective actions. |
To ensure plan is in place for post-spill operations. |
|
6 |
Canada_Federal_PBMM_3-1-2020 |
IR_9(4) |
Canada_Federal_PBMM_3-1-2020_IR_9(4) |
Canada Federal PBMM 3-1-2020 IR 9(4) |
Information Spillage Response |
Information Spillage Response | Exposure to Unauthorized Personnel |
Shared |
The organization employs organization-defined security safeguards for personnel exposed to information not within assigned access authorizations. |
To mitigate the risk of information spillage. |
|
4 |
Canada_Federal_PBMM_3-1-2020 |
MP_2 |
Canada_Federal_PBMM_3-1-2020_MP_2 |
404 not found |
|
|
|
n/a |
n/a |
|
5 |
Canada_Federal_PBMM_3-1-2020 |
PS_6 |
Canada_Federal_PBMM_3-1-2020_PS_6 |
Canada Federal PBMM 3-1-2020 PS 6 |
Access Agreements |
Access Agreements |
Shared |
1. The organization develops and documents access agreements for organizational information systems.
2. The organization reviews and updates the access agreements at least annually.
3. The organization ensures that individuals requiring access to organizational information and information systems:
a. Sign appropriate access agreements prior to being granted access; and
b. Re-sign access agreements to maintain access to organizational information systems when access agreements have been updated or at least annually. |
To develop and document access agreements for organizational information systems. |
|
2 |
CIS_Controls_v8.1 |
10.7 |
CIS_Controls_v8.1_10.7 |
CIS Controls v8.1 10.7 |
Malware Defenses |
Use behaviour based anti-malware software |
Shared |
Use behaviour based anti-malware software |
To ensure that a generic anti-malware software is not used. |
|
99 |
CIS_Controls_v8.1 |
13.1 |
CIS_Controls_v8.1_13.1 |
CIS Controls v8.1 13.1 |
Network Monitoring and Defense |
Centralize security event alerting |
Shared |
1. Centralize security event alerting across enterprise assets for log correlation and analysis.
2. Best practice implementation requires the use of a SIEM, which includes vendor-defined event correlation alerts.
3.A log analytics platform configured with security-relevant correlation alerts also satisfies this safeguard. |
To ensure that any security event is immediately alerted enterprise-wide. |
|
101 |
CIS_Controls_v8.1 |
13.3 |
CIS_Controls_v8.1_13.3 |
CIS Controls v8.1 13.3 |
Network Monitoring and Defense |
Deploy a network intrusion detection solution |
Shared |
1. Deploy a network intrusion detection solution on enterprise assets, where appropriate.
2. Example implementations include the use of a Network Intrusion Detection System (NIDS) or equivalent cloud service provider (CSP) service. |
To enhance the organization's cybersecurity. |
|
99 |
CIS_Controls_v8.1 |
18.4 |
CIS_Controls_v8.1_18.4 |
CIS Controls v8.1 18.4 |
Penetration Testing |
Validate security measures |
Shared |
Validate security measures after each penetration test. If deemed necessary, modify rulesets and capabilities to detect the techniques used during testing. |
To ensure ongoing alignment with evolving threat landscapes and bolstering the overall security posture of the enterprise. |
|
93 |
CIS_Controls_v8.1 |
3.3 |
CIS_Controls_v8.1_3.3 |
CIS Controls v8.1 3.3 |
Data Protection |
Configure data access control lists |
Shared |
1. Configure data access control lists based on a user’s need to know.
2. Apply data access control lists, also known as access permissions, to local and remote file systems, databases, and applications.
|
To ensure that users have access only to the data necessary for their roles. |
|
25 |
CIS_Controls_v8.1 |
4.7 |
CIS_Controls_v8.1_4.7 |
CIS Controls v8.1 4.7 |
Secure Configuration of Enterprise Assets and Software |
Manage default accounts on enterprise assets and software |
Shared |
1. Manage default accounts on enterprise assets and software, such as root, administrator, and other pre-configured vendor accounts.
2. Example implementations can include: disabling default accounts or making them unusable. |
To ensure access to default accounts is restricted. |
|
26 |
CIS_Controls_v8.1 |
5.3 |
CIS_Controls_v8.1_5.3 |
CIS Controls v8.1 5.3 |
Account Management |
Disable dormant accounts |
Shared |
Delete or disable any dormant accounts after a period of 45 days of inactivity, where supported. |
To implement time based expiry of access to systems. |
|
25 |
CIS_Controls_v8.1 |
6.1 |
CIS_Controls_v8.1_6.1 |
CIS Controls v8.1 6.1 |
Access Control Management |
Establish an access granting process |
Shared |
Establish and follow a process, preferably automated, for granting access to enterprise assets upon new hire, rights grant, or role change of a user.
|
To implement role based access controls. |
|
23 |
CIS_Controls_v8.1 |
6.2 |
CIS_Controls_v8.1_6.2 |
CIS Controls v8.1 6.2 |
Access Control Management |
Establish an access revoking process |
Shared |
1. Establish and follow a process, preferably automated, for revoking access to enterprise assets, through disabling accounts immediately upon termination, rights revocation, or role change of a user.
2. Disabling accounts, instead of deleting accounts, may be necessary to preserve audit trails. |
To restrict access to enterprise assets. |
|
24 |
CIS_Controls_v8.1 |
6.8 |
CIS_Controls_v8.1_6.8 |
CIS Controls v8.1 6.8 |
Access Control Management |
Define and maintain role-based access control. |
Shared |
1. Define and maintain role-based access control, through determining and documenting the access rights necessary for each role within the enterprise to successfully carry out its assigned duties.
2. Perform access control reviews of enterprise assets to validate that all privileges are authorized, on a recurring schedule at a minimum annually, or more frequently. |
To implement a system of role-based access control. |
|
30 |
CIS_Controls_v8.1 |
8.11 |
CIS_Controls_v8.1_8.11 |
CIS Controls v8.1 8.11 |
Audit Log Management |
Conduct audit log reviews |
Shared |
1. Conduct reviews of audit logs to detect anomalies or abnormal events that could indicate a potential threat.
2. Conduct reviews on a weekly, or more frequent, basis.
|
To ensure the integrity of the data in audit logs. |
|
62 |
CIS_Controls_v8.1 |
9.3 |
CIS_Controls_v8.1_9.3 |
CIS Controls v8.1 9.3 |
Email and Web Browser Protections |
Maintain and enforce network-based URL filters |
Shared |
1. Enforce and update network-based URL filters to limit an enterprise asset from connecting to potentially malicious or unapproved websites.
2. Example implementations include category-based filtering, reputation-based filtering, or through the use of block lists.
3. Enforce filters for all enterprise assets. |
To prevent users from connecting to unsafe websites. |
|
9 |
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 |
AC.L1_3.1.1 |
CMMC_L2_v1.9.0_AC.L1_3.1.1 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 AC.L1 3.1.1 |
Access Control |
Authorized Access Control |
Shared |
Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems). |
To ensure security and integrity. |
|
27 |
CMMC_L2_v1.9.0 |
AC.L2_3.1.5 |
CMMC_L2_v1.9.0_AC.L2_3.1.5 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 AC.L2 3.1.5 |
Access Control |
Least Privilege |
Shared |
Employ the principle of least privilege, including for specific security functions and privileged accounts. |
To restrict information system access. |
|
27 |
CMMC_L2_v1.9.0 |
RA.L2_3.11.3 |
CMMC_L2_v1.9.0_RA.L2_3.11.3 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 RA.L2 3.11.3 |
Risk Assessment |
Vulnerability Remediation |
Shared |
Remediate vulnerabilities in accordance with risk assessments. |
To reduce the likelihood of security breaches and minimize potential impacts on operations and assets. |
|
14 |
CMMC_L2_v1.9.0 |
SC.L2_3.13.3 |
CMMC_L2_v1.9.0_SC.L2_3.13.3 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 SC.L2 3.13.3 |
System and Communications Protection |
Role Separation |
Shared |
Separate user functionality from system management functionality. |
To enforce least privilege principles, enhance accountability, and mitigate the impact of potential security incidents or breaches. |
|
1 |
CMMC_L2_v1.9.0 |
SI.L2_3.14.3 |
CMMC_L2_v1.9.0_SI.L2_3.14.3 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 SI.L2 3.14.3 |
System and Information Integrity |
Security Alerts & Advisories |
Shared |
Monitor system security alerts and advisories and take action in response. |
To proactively defend against emerging threats and minimize the risk of security incidents or breaches. |
|
19 |
CMMC_L2_v1.9.0 |
SI.L2_3.14.6 |
CMMC_L2_v1.9.0_SI.L2_3.14.6 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 SI.L2 3.14.6 |
System and Information Integrity |
Monitor Communications for Attacks |
Shared |
Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. |
To protect systems and data from unauthorized access or compromise. |
|
19 |
CMMC_L2_v1.9.0 |
SI.L2_3.14.7 |
CMMC_L2_v1.9.0_SI.L2_3.14.7 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 SI.L2 3.14.7 |
System and Information Integrity |
Identify Unauthorized Use |
Shared |
Identify unauthorized use of organizational systems. |
To enable the organization to take appropriate action, such as revoking access privileges, investigating security incidents, and implementing additional security controls to prevent future unauthorized access. |
|
18 |
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). |
|
30 |
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 |
CEK_03 |
CSA_v4.0.12_CEK_03 |
CSA Cloud Controls Matrix v4.0.12 CEK 03 |
Cryptography, Encryption & Key Management |
Data Encryption |
Shared |
n/a |
Provide cryptographic protection to data at-rest and in-transit,
using cryptographic libraries certified to approved standards. |
|
58 |
CSA_v4.0.12 |
HRS_06 |
CSA_v4.0.12_HRS_06 |
CSA Cloud Controls Matrix v4.0.12 HRS 06 |
Human Resources |
Employment Termination |
Shared |
n/a |
Establish, document, and communicate to all personnel the procedures
outlining the roles and responsibilities concerning changes in employment. |
|
17 |
CSA_v4.0.12 |
IAM_05 |
CSA_v4.0.12_IAM_05 |
CSA Cloud Controls Matrix v4.0.12 IAM 05 |
Identity & Access Management |
Least Privilege |
Shared |
n/a |
Employ the least privilege principle when implementing information
system access. |
|
27 |
CSA_v4.0.12 |
IAM_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 |
IAM_10 |
CSA_v4.0.12_IAM_10 |
CSA Cloud Controls Matrix v4.0.12 IAM 10 |
Identity & Access Management |
Management of Privileged Access Roles |
Shared |
n/a |
Define and implement an access process to ensure privileged access
roles and rights are granted for a time limited period, and implement procedures
to prevent the culmination of segregated privileged access. |
|
56 |
CSA_v4.0.12 |
IAM_12 |
CSA_v4.0.12_IAM_12 |
CSA Cloud Controls Matrix v4.0.12 IAM 12 |
Identity & Access Management |
Safeguard Logs Integrity |
Shared |
n/a |
Define, implement and evaluate processes, procedures and technical
measures to ensure the logging infrastructure is read-only for all with write
access, including privileged access roles, and that the ability to disable it
is controlled through a procedure that ensures the segregation of duties and
break glass procedures. |
|
42 |
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 |
2 |
Cyber_Essentials_v3.1_2 |
Cyber Essentials v3.1 2 |
Cyber Essentials |
Secure Configuration |
Shared |
n/a |
Aim: ensure that computers and network devices are properly configured to reduce vulnerabilities and provide only the services required to fulfill their role. |
|
61 |
Cyber_Essentials_v3.1 |
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_11 |
EU_2555_(NIS2)_2022_11 |
EU 2022/2555 (NIS2) 2022 11 |
|
Requirements, technical capabilities and tasks of CSIRTs |
Shared |
n/a |
Outlines the requirements, technical capabilities, and tasks of CSIRTs. |
|
68 |
EU_2555_(NIS2)_2022 |
EU_2555_(NIS2)_2022_12 |
EU_2555_(NIS2)_2022_12 |
EU 2022/2555 (NIS2) 2022 12 |
|
Coordinated vulnerability disclosure and a European vulnerability database |
Shared |
n/a |
Establishes a coordinated vulnerability disclosure process and a European vulnerability database. |
|
66 |
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. |
|
193 |
EU_2555_(NIS2)_2022 |
EU_2555_(NIS2)_2022_29 |
EU_2555_(NIS2)_2022_29 |
EU 2022/2555 (NIS2) 2022 29 |
|
Cybersecurity information-sharing arrangements |
Shared |
n/a |
Allows entities to exchange relevant cybersecurity information on a voluntary basis. |
|
66 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5 |
.1 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5.1 |
FBI Criminal Justice Information Services (CJIS) v5.9.5 5.1 |
Policy and Implementation - Systems And Communications Protection |
Systems And Communications Protection |
Shared |
In addition, applications, services, or information systems must have the capability to ensure system integrity through the detection and protection against unauthorized changes to software and information. |
Examples of systems and communications safeguards range from boundary and transmission protection to securing an agency's virtualized environment. |
|
110 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5 |
.11 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5.11 |
FBI Criminal Justice Information Services (CJIS) v5.9.5 5.11 |
Policy and Implementation - Formal Audits |
Policy Area 11: Formal Audits |
Shared |
Internal compliance checklists should be regularly kept updated with respect to applicable statutes, regulations, policies and on the basis of findings in audit. |
Formal audits are conducted to ensure compliance with applicable statutes, regulations and policies. |
|
64 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5 |
.5 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5.5 |
FBI Criminal Justice Information Services (CJIS) v5.9.5 5.5 |
Policy and Implementation - Access Control |
Access Control |
Shared |
Refer to Section 5.13.6 for additional access control requirements related to mobile devices used to access CJI. |
Access control provides the planning and implementation of mechanisms to restrict reading, writing, processing, and transmission of CJIS information and the modification of information systems, applications, services and communication configurations allowing access to CJIS information. |
|
97 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5 |
.7 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5.7 |
404 not found |
|
|
|
n/a |
n/a |
|
95 |
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.) |
|
71 |
FFIEC_CAT_2017 |
3.1.2 |
FFIEC_CAT_2017_3.1.2 |
FFIEC CAT 2017 3.1.2 |
Cybersecurity Controls |
Access and Data Management |
Shared |
n/a |
Employee access is granted to systems and confidential data based on job responsibilities and the principles of least privilege.'FFIEC_Cybersecurity Control'!F8
- Employee access to systems and confidential data provides for separation of duties.
- Elevated privileges (e.g., administrator privileges) are limited and tightly controlled (e.g., assigned to individuals, not shared, and require stronger 'FFIEC_Cybersecurity Control'!F7password controls).
- User access reviews are performed periodically for all systems and applications based on the risk to the application or system.
- Changes to physical and logical user access, including those that result from voluntary and involuntary terminations, are submitted to and approved by appropriate personnel.
- Identification and authentication are required and managed for access to systems, applications, and hardware.
- Access controls include password complexity and limits to password attempts and reuse.
- All default passwords and unnecessary default accounts are changed before system implementation.
- Customer access to Internet-based products or services requires authentication controls (e.g., layered controls, multifactor) that are commensurate with the risk.
- Production and non-production environments are segregated to prevent unauthorized access or changes to information assets. (*N/A if no production environment exists at the institution or the institution’s third party.)
- Physical security controls are used to prevent unauthorized access to information systems and telecommunication systems.
- All passwords are encrypted in storage and in transit.
- Confidential data are encrypted when transmitted across public or untrusted networks (e.g., Internet).
- Mobile devices (e.g., laptops, tablets, and removable media) are encrypted if used to store confidential data. (*N/A if mobile devices are not used.)
- Remote access to critical systems by employees, contractors, and third parties uses encrypted connections and multifactor authentication.
- Administrative, physical, or technical controls are in place to prevent users without administrative responsibilities from installing unauthorized software.
- Customer service (e.g., the call center) utilizes formal procedures to authenticate customers commensurate with the risk of the transaction or request.
- Data is disposed of or destroyed according to documented requirements and within expected time frames. |
|
59 |
FFIEC_CAT_2017 |
3.2.3 |
FFIEC_CAT_2017_3.2.3 |
FFIEC CAT 2017 3.2.3 |
Cybersecurity Controls |
Event Detection |
Shared |
n/a |
- A normal network activity baseline is established.
- Mechanisms (e.g., antivirus alerts, log event alerts) are in place to alert management to potential attacks.
- Processes are in place to monitor for the presence of unauthorized users, devices, connections, and software.
- Responsibilities for monitoring and reporting suspicious systems activity have been assigned.
- The physical environment is monitored to detect potential unauthorized access. |
|
34 |
HITRUST_CSF_v11.3 |
01.l |
HITRUST_CSF_v11.3_01.l |
HITRUST CSF v11.3 01.l |
Network Access Control |
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 |
09.ab |
HITRUST_CSF_v11.3_09.ab |
HITRUST CSF v11.3 09.ab |
Monitoring |
Establish procedures for monitoring use of information processing systems and facilities to check for use and effectiveness of implemented controls. |
Shared |
1. It is to be specified how often audit logs are reviewed, how the reviews are documented, and the specific roles and responsibilities of the personnel conducting the reviews, including the professional certifications or other qualifications required.
2. All relevant legal requirements applicable to its monitoring of authorized access and unauthorized access attempts is to be complied with. |
Procedures for monitoring use of information processing systems and facilities shall be established to check for use and effectiveness of implemented controls. The results of the monitoring activities shall be reviewed regularly. |
|
113 |
HITRUST_CSF_v11.3 |
09.j |
HITRUST_CSF_v11.3_09.j |
HITRUST CSF v11.3 09.j |
Protection Against Malicious and Mobile Code |
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 |
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 |
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. |
|
46 |
ISO_IEC_27002_2022 |
8.16 |
ISO_IEC_27002_2022_8.16 |
ISO IEC 27002 2022 8.16 |
Response,
Detection,
Corrective Control |
Monitoring activities |
Shared |
Networks, systems and applications should be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents.
|
To detect anomalous behaviour and potential information security incidents. |
|
19 |
ISO_IEC_27002_2022 |
8.2 |
ISO_IEC_27002_2022_8.2 |
ISO IEC 27002 2022 8.2 |
Protection,
Preventive, Control |
Privileged access rights |
Shared |
The allocation and use of privileged access rights should be restricted and managed.
|
To ensure only authorized users, software components and services are provided with privileged access rights. |
|
29 |
ISO_IEC_27002_2022 |
8.8 |
ISO_IEC_27002_2022_8.8 |
ISO IEC 27002 2022 8.8 |
Identifying,
Protection,
Preventive Control |
Management of technical vulnerabilities |
Shared |
Information about technical vulnerabilities of information systems in use should be obtained, the organization’s exposure to such vulnerabilities should be evaluated and appropriate measures should be taken.
|
To prevent exploitation of technical vulnerabilities. |
|
14 |
ISO_IEC_27017_2015 |
12.4.3 |
ISO_IEC_27017_2015_12.4.3 |
ISO IEC 27017 2015 12.4.3 |
Operations Security |
Administrator and Operation Logs |
Shared |
For Cloud Service Customer:
If a privileged operation is delegated to the cloud service customer, the operation and performance of those operations should be logged. The cloud service customer should determine whether logging capabilities provided by the cloud service provider are appropriate or whether the cloud service customer should implement additional logging capabilities. |
To log operation and performance of those operations wherein rivileged operation is delegated to the cloud service customer. |
|
28 |
NIST_CSF_v2.0 |
DE.CM |
NIST_CSF_v2.0_DE.CM |
404 not found |
|
|
|
n/a |
n/a |
|
19 |
NIST_CSF_v2.0 |
PR.AA_05 |
NIST_CSF_v2.0_PR.AA_05 |
NIST CSF v2.0 PR.AA 05 |
PROTECT- Identity Management, Authentication, and Access |
Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties. |
Shared |
n/a |
To implement safeguards for managing organization’s cybersecurity risks. |
|
29 |
NIST_SP_800-171_R2_3 |
.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-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 |
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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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 |
10.3.4 |
PCI_DSS_v4.0.1_10.3.4 |
PCI DSS v4.0.1 10.3.4 |
Log and Monitor All Access to System Components and Cardholder Data |
Log Integrity Monitoring |
Shared |
n/a |
File integrity monitoring or change-detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating alerts. |
|
28 |
PCI_DSS_v4.0.1 |
11.3.1 |
PCI_DSS_v4.0.1_11.3.1 |
PCI DSS v4.0.1 11.3.1 |
Test Security of Systems and Networks Regularly |
Internal Vulnerability Scans |
Shared |
n/a |
Internal vulnerability scans are performed as follows:
• At least once every three months.
• Vulnerabilities that are either high-risk or critical (according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
• Rescans are performed that confirm all high-risk and all critical vulnerabilities (as noted above) have been resolved.
• Scan tool is kept up to date with latest vulnerability information.
• Scans are performed by qualified personnel and organizational independence of the tester exists. |
|
15 |
PCI_DSS_v4.0.1 |
11.3.1.1 |
PCI_DSS_v4.0.1_11.3.1.1 |
PCI DSS v4.0.1 11.3.1.1 |
Test Security of Systems and Networks Regularly |
Management of Other Vulnerabilities |
Shared |
n/a |
All other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are managed as follows:
• Addressed based on the risk defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
• Rescans are conducted as needed. |
|
14 |
PCI_DSS_v4.0.1 |
11.4.4 |
PCI_DSS_v4.0.1_11.4.4 |
PCI DSS v4.0.1 11.4.4 |
Test Security of Systems and Networks Regularly |
Addressing Penetration Testing Findings |
Shared |
n/a |
Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows:
• In accordance with the entity’s assessment of the risk posed by the security issue as defined in Requirement 6.3.1.
• Penetration testing is repeated to verify the corrections. |
|
14 |
PCI_DSS_v4.0.1 |
11.5.1 |
PCI_DSS_v4.0.1_11.5.1 |
PCI DSS v4.0.1 11.5.1 |
Test Security of Systems and Networks Regularly |
Intrusion Detection/Prevention |
Shared |
n/a |
Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or prevent intrusions into the network as follows:
• All traffic is monitored at the perimeter of the CDE.
• All traffic is monitored at critical points in the CDE.
• Personnel are alerted to suspected compromises.
• All intrusion-detection and prevention engines, baselines, and signatures are kept up to date |
|
23 |
PCI_DSS_v4.0.1 |
11.5.1.1 |
PCI_DSS_v4.0.1_11.5.1.1 |
PCI DSS v4.0.1 11.5.1.1 |
Test Security of Systems and Networks Regularly |
Covert Malware Detection |
Shared |
n/a |
Additional requirement for service providers only: Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels. |
|
21 |
PCI_DSS_v4.0.1 |
11.5.2 |
PCI_DSS_v4.0.1_11.5.2 |
PCI DSS v4.0.1 11.5.2 |
Test Security of Systems and Networks Regularly |
Change-Detection Mechanism Deployment |
Shared |
n/a |
A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows:
• To alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files.
• To perform critical file comparisons at least once weekly. |
|
31 |
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 |
PCI_DSS_v4.0.1 |
6.4.1 |
PCI_DSS_v4.0.1_6.4.1 |
PCI DSS v4.0.1 6.4.1 |
Develop and Maintain Secure Systems and Software |
For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows: Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows: At least once every 12 months and after significant changes. By an entity that specializes in application security. Including, at a minimum, all common software attacks in Requirement 6.2.4. All vulnerabilities are ranked in accordance with requirement 6.3.1. All vulnerabilities are corrected. The application is re-evaluated after the corrections. OR Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows: Installed in front of public-facing web applications to detect and prevent web-based attacks. Actively running and up to date as applicable. Generating audit logs. Configured to either block web-based attacks or generate an alert that is immediately investigated |
Shared |
n/a |
For public-facing web applications, ensure that either one of the required methods is in place as follows: If manual or automated vulnerability security assessment tools or methods are in use, examine documented processes, interview personnel, and examine records of application security assessments to verify that public-facing web applications are reviewed in accordance with all elements of this requirement specific to the tool/method. OR If an automated technical solution(s) is installed that continually detects and prevents web-based attacks, examine the system configuration settings and audit logs, and interview responsible personnel to verify that the automated technical solution(s) is installed in accordance with all elements of this requirement specific to the solution(s) |
|
15 |
PCI_DSS_v4.0.1 |
7.2.1 |
PCI_DSS_v4.0.1_7.2.1 |
PCI DSS v4.0.1 7.2.1 |
Restrict Access to System Components and Cardholder Data by Business Need to Know |
An access control model is defined and includes granting access as follows: Appropriate access depending on the entity’s business and access needs. Access to system components and data resources that is based on users’ job classification and functions. The least privileges required (for example, user, administrator) to perform a job function |
Shared |
n/a |
Examine documented policies and procedures and interview personnel to verify the access control model is defined in accordance with all elements specified in this requirement. Examine access control model settings and verify that access needs are appropriately defined in accordance with all elements specified in this requirement |
|
43 |
PCI_DSS_v4.0.1 |
7.2.2 |
PCI_DSS_v4.0.1_7.2.2 |
PCI DSS v4.0.1 7.2.2 |
Restrict Access to System Components and Cardholder Data by Business Need to Know |
Access is assigned to users, including privileged users, based on: Job classification and function. Least privileges necessary to perform job responsibilities |
Shared |
n/a |
Examine policies and procedures to verify they cover assigning access to users in accordance with all elements specified in this requirement. Examine user access settings, including for privileged users, and interview responsible management personnel to verify that privileges assigned are in accordance with all elements specified in this requirement. Interview personnel responsible for assigning access to verify that privileged user access is assigned in accordance with all elements specified in this requirement |
|
43 |
PCI_DSS_v4.0.1 |
7.2.5 |
PCI_DSS_v4.0.1_7.2.5 |
PCI DSS v4.0.1 7.2.5 |
Restrict Access to System Components and Cardholder Data by Business Need to Know |
All application and system accounts and related access privileges are assigned and managed as follows: Based on the least privileges necessary for the operability of the system or application. Access is limited to the systems, applications, or processes that specifically require their use |
Shared |
n/a |
Examine policies and procedures to verify they define processes to manage and assign application and system accounts and related access privileges in accordance with all elements specified in this requirement. Examine privileges associated with system and application accounts and interview responsible personnel to verify that application and system accounts and related access privileges are assigned and managed in accordance with all elements specified in this requirement |
|
44 |
PCI_DSS_v4.0.1 |
7.2.6 |
PCI_DSS_v4.0.1_7.2.6 |
PCI DSS v4.0.1 7.2.6 |
Restrict Access to System Components and Cardholder Data by Business Need to Know |
All user access to query repositories of stored cardholder data is restricted as follows: Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges. Only the responsible administrator(s) can directly access or query repositories of stored CHD |
Shared |
n/a |
Examine policies and procedures and interview personnel to verify processes are defined for granting user access to query repositories of stored cardholder data, in accordance with all elements specified in this requirement. Examine configuration settings for querying repositories of stored cardholder data to verify they are in accordance with all elements specified in this requirement |
|
41 |
PCI_DSS_v4.0.1 |
7.3.1 |
PCI_DSS_v4.0.1_7.3.1 |
PCI DSS v4.0.1 7.3.1 |
Restrict Access to System Components and Cardholder Data by Business Need to Know |
An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components |
Shared |
n/a |
Examine vendor documentation and system settings to verify that access is managed for each system component via an access control system(s) that restricts access based on a user’s need to know and covers all system components |
|
27 |
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 |
Sarbanes_Oxley_Act_(1)_2022_1 |
Sarbanes_Oxley_Act_(1)_2022_1 |
Sarbanes_Oxley_Act_(1)_2022_1 |
Sarbanes Oxley Act 2022 1 |
PUBLIC LAW |
Sarbanes Oxley Act 2022 (SOX) |
Shared |
n/a |
n/a |
|
92 |
SOC_2 |
CC6.8 |
SOC_2_CC6.8 |
SOC 2 Type 2 CC6.8 |
Logical and Physical Access Controls |
Prevent or detect against unauthorized or malicious software |
Shared |
The customer is responsible for implementing this recommendation. |
Restricts Application and Software Installation — The ability to install applications
and software is restricted to authorized individuals.
• Detects Unauthorized Changes to Software and Configuration Parameters — Processes are in place to detect changes to software and configuration parameters that
may be indicative of unauthorized or malicious software.
• Uses a Defined Change Control Process — A management-defined change control
process is used for the implementation of software.
• Uses Antivirus and Anti-Malware Software — Antivirus and anti-malware software
is implemented and maintained to provide for the interception or detection and remediation of malware.
• Scans Information Assets from Outside the Entity for Malware and Other Unauthorized Software — Procedures are in place to scan information assets that have been
transferred or returned to the entity’s custody for malware and other unauthorized
software and to remove any items detected prior to its implementation on the network. |
|
47 |
SOC_2 |
CC8.1 |
SOC_2_CC8.1 |
SOC 2 Type 2 CC8.1 |
Change Management |
Changes to infrastructure, data, and software |
Shared |
The customer is responsible for implementing this recommendation. |
Manages Changes Throughout the System Life Cycle — A process for managing
system changes throughout the life cycle of the system and its components (infrastructure, data, software, and procedures) is used to support system availability and
processing integrity.
• Authorizes Changes — A process is in place to authorize system changes prior to
development.
• Designs and Develops Changes — A process is in place to design and develop system changes.
• Documents Changes — A process is in place to document system changes to support ongoing maintenance of the system and to support system users in performing
their responsibilities.
• Tracks System Changes — A process is in place to track system changes prior to
implementation.
• Configures Software — A process is in place to select and implement the configuration parameters used to control the functionality of software.
• Tests System Changes — A process is in place to test system changes prior to implementation.
• Approves System Changes — A process is in place to approve system changes prior
to implementation.
• Deploys System Changes — A process is in place to implement system changes.
• Identifies and Evaluates System Changes — Objectives affected by system changes
are identified and the ability of the modified system to meet the objectives is evaluated throughout the system development life cycle.
• Identifies Changes in Infrastructure, Data, Software, and Procedures Required to
Remediate Incidents — Changes in infrastructure, data, software, and procedures
required to remediate incidents to continue to meet objectives are identified and the
change process is initiated upon identification.
• Creates Baseline Configuration of IT Technology — A baseline configuration of IT
and control systems is created and maintained.
• Provides for Changes Necessary in Emergency Situations — A process is in place
for authorizing, designing, testing, approving, and implementing changes necessary
in emergency situations (that is, changes that need to be implemented in an urgent
time frame).
Additional points of focus that apply only in an engagement using the trust services criteria for
confidentiality:
• Protects Confidential Information — The entity protects confidential information
during system design, development, testing, implementation, and change processes
to meet the entity’s objectives related to confidentiality.
Additional points of focus that apply only in an engagement using the trust services criteria for
privacy:
• Protects Personal Information — The entity protects personal information during
system design, development, testing, implementation, and change processes to meet
the entity’s objectives related to privacy. |
|
52 |
SWIFT_CSCF_2024 |
1.2 |
SWIFT_CSCF_2024_1.2 |
SWIFT Customer Security Controls Framework 2024 1.2 |
Privileged Account Control |
Operating System Privileged Account Control |
Shared |
Tightly protecting administrator-level accounts within the operating system reduces the opportunity for an attacker to use the privileges of the account as part of an attack (for example, executing commands or deleting evidence). |
To restrict and control the allocation and usage of administrator-level operating system accounts. |
|
53 |
SWIFT_CSCF_2024 |
1.3 |
SWIFT_CSCF_2024_1.3 |
SWIFT Customer Security Controls Framework 2024 1.3 |
Cloud Platform Protection |
Virtualisation or Cloud Platform Protection |
Shared |
1. Security controls that apply to non-virtualised (physical) systems are equally applicable to virtual systems.
2. The additional virtualisation layer needs extra attention from a security perspective. The uncontrolled proliferation of VMs could lead to unaccounted machines with the risk of unmanaged, unpatched systems open to unauthorised access to data.
3. If appropriate controls have been implemented to this underlying layer, then Swift does not limit the use of virtual technology for any component of the user’s Swift infrastructure or the associated supporting infrastructure (for example, virtual firewalls). |
To secure the virtualisation or cloud platform and virtual machines (VMs) that host Swift-related components to the same level as physical systems. |
|
7 |
SWIFT_CSCF_2024 |
2.9 |
SWIFT_CSCF_2024_2.9 |
SWIFT Customer Security Controls Framework 2024 2.9 |
Transaction Controls |
Transaction Business Controls |
Shared |
1. Implementing business controls that restrict Swift transactions to the fullest extent possible reduces the opportunity for the sending (outbound) and, optionally, receiving (inbound) of fraudulent transactions.
2. These restrictions are best determined through an analysis of normal business activity. Parameters can then be set to restrict business to acceptable thresholds based on “normal” activity. |
To ensure outbound transaction activity within the expected bounds of normal business. |
|
25 |
SWIFT_CSCF_2024 |
4.2 |
SWIFT_CSCF_2024_4.2 |
SWIFT Customer Security Controls Framework 2024 4.2 |
Access Control |
Multi-Factor Authentication |
Shared |
1. Multi-factor authentication requires the presentation of two or more of the following common authentication factors:
(A). Knowledge factor: something the operator knows (for example, a password)
(B). Possession factor: something the operator has (for example, connected USB tokens or smart cards, or disconnected tokens such as a (time based) one-time password- (T)OTP- generator or application storing a cryptographic private key that runs on another device like operator’s mobile phone considered as a software token, RSA token, 3-Skey Digital and its mobile version considered as a software token, or Digipass)
(C). Inherence factor: something the operator is (for example, biometrics such as fingerprints, retina scans, or voice recognition) Implementing multi-factor authentication provides an additional layer of protection against common authentication attacks (for example, shoulder surfing, password re-use, or weak passwords) and provides further protection from account compromises for malicious transaction processing. Attackers often use the privileges of a compromised
account to move laterally within an environment and to progress an attack. |
To prevent that a compromise of a single authentication factor allows access into Swift-related systems or applications by implementing multi-factor authentication. |
|
11 |
SWIFT_CSCF_2024 |
6.4 |
SWIFT_CSCF_2024_6.4 |
SWIFT Customer Security Controls Framework 2024 6.4 |
Access Control |
Logging and Monitoring |
Shared |
1. Developing a logging and monitoring plan is the basis for effectively detecting abnormal behaviour and potential attacks and support further investigations.
2. As the operational environment becomes more complex, so will the logging and monitoring capability needed to perform adequate detection. Simplifying the operational environment will enable simpler logging and monitoring. |
To record security events, detect and respond to anomalous actions and operations within the user’s Swift environment. |
|
42 |
SWIFT_CSCF_2024 |
6.5 |
SWIFT_CSCF_2024_6.5 |
404 not found |
|
|
|
n/a |
n/a |
|
22 |
UK_NCSC_CAF_v3.2 |
C |
UK_NCSC_CAF_v3.2_C |
404 not found |
|
|
|
n/a |
n/a |
|
18 |
UK_NCSC_CAF_v3.2 |
C1 |
UK_NCSC_CAF_v3.2_C1 |
404 not found |
|
|
|
n/a |
n/a |
|
19 |
UK_NCSC_CAF_v3.2 |
C1.c |
UK_NCSC_CAF_v3.2_C1.c |
NCSC Cyber Assurance Framework (CAF) v3.2 C1.c |
Security Monitoring |
Generating Alerts |
Shared |
1. Logging data is enriched with other network knowledge and data when investigating certain suspicious activity or alerts.
2. A wide range of signatures and indicators of compromise is used for investigations of suspicious activity and alerts.
3. Alerts can be easily resolved to network assets using knowledge of networks and systems. The resolution of these alerts is performed in almost real time.
4. Security alerts relating to all essential functions are prioritised and this information is used to support incident management.
5. Logs are reviewed almost continuously, in real time.
6. Alerts are tested to ensure that they are generated reliably and that it is possible to distinguish genuine security incidents from false alarms. |
Evidence of potential security incidents contained in your monitoring data is reliably identified and triggers alerts. |
|
22 |
UK_NCSC_CAF_v3.2 |
C1.d |
UK_NCSC_CAF_v3.2_C1.d |
NCSC Cyber Assurance Framework (CAF) v3.2 C1.d |
Security Monitoring |
Identifying Security Incidents |
Shared |
1. Select threat intelligence sources or services using risk-based and threat-informed decisions based on the business needs and sector (e.g. vendor reporting and patching, strong anti-virus providers, sector and community-based info share, special interest groups).
2. Apply all new signatures and IoCs within a reasonable (risk-based) time of receiving them.
3. Receive signature updates for all the protective technologies (e.g. AV, IDS).
4. Track the effectiveness of the intelligence feeds and actively share feedback on the usefulness of IoCs and any other indicators with the threat community (e.g.
sector partners, threat intelligence providers, government agencies). |
Contextualise alerts with knowledge of the threat and the systems, to identify those security incidents that require some form of response. |
|
21 |
UK_NCSC_CAF_v3.2 |
C2 |
UK_NCSC_CAF_v3.2_C2 |
404 not found |
|
|
|
n/a |
n/a |
|
19 |
UK_NCSC_CAF_v3.2 |
C2.b |
UK_NCSC_CAF_v3.2_C2.b |
NCSC Cyber Assurance Framework (CAF) v3.2 C2.b |
Proactive Security Event Discovery |
Proactive Attack Discovery |
Shared |
1. Routinely search for system abnormalities indicative of malicious activity on the networks and information systems supporting the operation of your essential function, generating alerts based on the results of such searches.
2. Have justified confidence in the effectiveness of the searches for system abnormalities indicative of malicious activity. |
Use an informed understanding of more sophisticated attack methods and of normal system behaviour to monitor proactively for malicious activity. |
|
19 |