compliance controls are associated with this Policy definition 'Audit virtual machines without disaster recovery configured' (0015ea4d-51ff-4ce3-8d8c-f3f8f0179a56)
| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
| AU_ISM |
1511 |
AU_ISM_1511 |
AU ISM 1511 |
Guidelines for System Management - Data backup and restoration |
Performing backups - 1511 |
|
n/a |
Backups of important data, software and configuration settings are performed at least daily. |
link |
1 |
| Canada_Federal_PBMM_3-1-2020 |
AC_2 |
Canada_Federal_PBMM_3-1-2020_AC_2 |
Canada Federal PBMM 3-1-2020 AC 2 |
Account Management |
Account Management |
Shared |
1. The organization identifies and selects which types of information system accounts support organizational missions/business functions.
2. The organization assigns account managers for information system accounts.
3. The organization establishes conditions for group and role membership.
4. The organization specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account.
5. The organization requires approvals by responsible managers for requests to create information system accounts.
6. The organization creates, enables, modifies, disables, and removes information system accounts in accordance with information system account management procedures.
7. The organization monitors the use of information system accounts.
8. The organization notifies account managers:
a. When accounts are no longer required;
b. When users are terminated or transferred; and
c. When individual information system usage or need-to-know changes.
9. The organization authorizes access to the information system based on:
a. A valid access authorization;
b. Intended system usage; and
c. Other attributes as required by the organization or associated missions/business functions.
10. The organization reviews accounts for compliance with account management requirements at least annually.
11. The organization establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group. |
To ensure the security, integrity, and efficiency of the information systems.
|
|
23 |
| Canada_Federal_PBMM_3-1-2020 |
AC_2(1) |
Canada_Federal_PBMM_3-1-2020_AC_2(1) |
Canada Federal PBMM 3-1-2020 AC 2(1) |
Account Management |
Account Management | Automated System Account Management |
Shared |
The organization employs automated mechanisms to support the management of information system accounts. |
To streamline and enhance information system account management processes. |
|
23 |
| Canada_Federal_PBMM_3-1-2020 |
CA_2 |
Canada_Federal_PBMM_3-1-2020_CA_2 |
Canada Federal PBMM 3-1-2020 CA 2 |
Security Assessments |
Security Assessments |
Shared |
1. The organization develops a security assessment plan that describes the scope of the assessment including:
a. Security controls and control enhancements under assessment;
b. Assessment procedures to be used to determine security control effectiveness; and
c. Assessment environment, assessment team, and assessment roles and responsibilities.
2. The organization assesses the security controls in the information system and its environment of operation at least annually to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security requirements.
3. The organization produces a security assessment report that documents the results of the assessment.
4. The organization provides the results of the security control assessment to organization-defined individuals or roles. |
To enhance the overall security posture of the organization. |
|
23 |
| 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. |
|
76 |
| 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. |
|
76 |
| 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. |
|
76 |
| 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. |
|
120 |
| Canada_Federal_PBMM_3-1-2020 |
CM_2 |
Canada_Federal_PBMM_3-1-2020_CM_2 |
Canada Federal PBMM 3-1-2020 CM 2 |
Baseline Configuration |
Baseline Configuration |
Shared |
The organization develops, documents, and maintains under configuration control, a current baseline configuration of the information system. |
To support effective management and security practices. |
|
23 |
| Canada_Federal_PBMM_3-1-2020 |
CM_2(1) |
Canada_Federal_PBMM_3-1-2020_CM_2(1) |
Canada Federal PBMM 3-1-2020 CM 2(1) |
Baseline Configuration |
Baseline Configuration | Reviews and Updates |
Shared |
The organization reviews and updates the baseline configuration of the information system:
1. at least annually; or
2. When required due to significant changes as defined in NIST SP 800-37 rev1; and
3. As an integral part of information system component installations and upgrades.
|
To ensure alignment with current security standards and operational requirements. |
|
23 |
| Canada_Federal_PBMM_3-1-2020 |
CM_2(2) |
Canada_Federal_PBMM_3-1-2020_CM_2(2) |
Canada Federal PBMM 3-1-2020 CM 2(2) |
Baseline Configuration |
Baseline Configuration | Automation Support for Accuracy / Currency |
Shared |
The organization employs automated mechanisms to maintain an up-to-date, complete, accurate, and readily available baseline configuration of the information system. |
To ensure the information system maintains an up-to-date, complete, accurate, and readily available baseline configuration |
|
22 |
| Canada_Federal_PBMM_3-1-2020 |
CP_10(2) |
Canada_Federal_PBMM_3-1-2020_CP_10(2) |
Canada Federal PBMM 3-1-2020 CP 10(2) |
Information System Recovery and Reconstitution |
Information System Recovery and Reconstitution | Transaction Recovery |
Shared |
The information system implements transaction recovery for systems that are transaction-based. |
To minimise the impact on business operations and preventing data loss or corruption. |
|
10 |
| Canada_Federal_PBMM_3-1-2020 |
CP_10(4) |
Canada_Federal_PBMM_3-1-2020_CP_10(4) |
Canada Federal PBMM 3-1-2020 CP 10(4) |
Information System Recovery and Reconstitution |
Information System Recovery and Reconstitution | Restore within Time Period |
Shared |
The organization provides the capability to restore information system components within organization-defined restoration time-periods from configuration-controlled and integrity-protected information representing a known, operational state for the components. |
To minimise downtime and ensuring business continuity. |
|
10 |
| Canada_Federal_PBMM_3-1-2020 |
CP_2(3) |
Canada_Federal_PBMM_3-1-2020_CP_2(3) |
Canada Federal PBMM 3-1-2020 CP 2(3) |
Contingency Plan |
Contingency Plan | Resume Essential Missions / Business Functions |
Shared |
The organization plans for the resumption of essential missions and business functions within 24 hours of contingency plan activation. |
To ensure that the organization plans for the resumption of essential missions and business functions within 24 hours of activating the contingency plan. |
|
10 |
| Canada_Federal_PBMM_3-1-2020 |
CP_2(4) |
Canada_Federal_PBMM_3-1-2020_CP_2(4) |
Canada Federal PBMM 3-1-2020 CP 2(4) |
Contingency Plan |
Contingency Plan | Resume All Missions / Business Functions |
Shared |
The organization plans for the resumption of all missions and business functions within organization-defined time period of contingency plan activation. |
To ensure that the organization plans for the resumption of all missions and business functions within an organization-defined time period of contingency plan activation. |
|
10 |
| Canada_Federal_PBMM_3-1-2020 |
CP_2(5) |
Canada_Federal_PBMM_3-1-2020_CP_2(5) |
Canada Federal PBMM 3-1-2020 CP 2(5) |
Contingency Plan |
Contingency Plan | Continue Essential Missions / Business Functions |
Shared |
The organization plans for the continuance of essential missions and business functions with little or no loss of operational continuity and sustains that continuity until full information system restoration at primary processing and/or storage sites. |
To minimise downtime, mitigate potential financial losses, maintain customer trust, and uphold critical services or functions.
|
|
10 |
| Canada_Federal_PBMM_3-1-2020 |
CP_2(6) |
Canada_Federal_PBMM_3-1-2020_CP_2(6) |
Canada Federal PBMM 3-1-2020 CP 2(6) |
Contingency Plan |
Contingency Plan | Alternate Processing / Storage Site |
Shared |
The organization plans for the transfer of essential missions and business functions to alternate processing and/or storage sites with little or no loss of operational continuity and sustains that continuity through information system restoration to primary processing and/or storage sites. |
To minimise downtime and ensure that critical services can continue uninterrupted until full restoration is achieved. |
|
10 |
| CCCS |
CP-7 |
CCCS_CP-7 |
CCCS CP-7 |
Contingency Planning |
Alternative Processing Site |
|
n/a |
(A) The organization establishes an alternate processing site including necessary agreements to permit the transfer and resumption of organization-defined information system operations for essential missions/business functions within organization-defined time period consistent with recovery time and recovery point objectives when the primary processing capabilities are unavailable.
(B) The organization ensures that equipment and supplies required to transfer and resume operations are available at the alternate processing site or contracts are in place to support delivery to the site within the organization-defined time period for transfer/resumption.
(C) The organization ensures that the alternate processing site provides information security safeguards equivalent to that of the primary site. |
link |
1 |
| 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. |
|
95 |
| CIS_Controls_v8.1 |
12.1 |
CIS_Controls_v8.1_12.1 |
CIS Controls v8.1 12.1 |
Network Infrastructure Management |
Ensure network infrastructure is up to date |
Shared |
1. Ensure network infrastructure is kept up-to-date.
2. Example implementations include running the latest stable release of software and/or using currently supported network-as-a-service (NaaS) offerings.
3. Review software versions monthly, or more frequently, to verify software support. |
To prevent any unauthorized or malicious activity on network systems. |
|
22 |
| CIS_Controls_v8.1 |
12.3 |
CIS_Controls_v8.1_12.3 |
CIS Controls v8.1 12.3 |
Network Infrastructure Management |
Securely manage network infrastructure |
Shared |
1. Securely manage network infrastructure.
2. Example implementations include version-controlled-infrastructure-ascode, and the use of secure network protocols, such as SSH and HTTPS. |
To ensure proper management of network infrastructure. |
|
38 |
| 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. |
|
97 |
| 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. |
|
95 |
| CIS_Controls_v8.1 |
16.12 |
CIS_Controls_v8.1_16.12 |
CIS Controls v8.1 16.12 |
Application Software Security |
Implement code-level security checks |
Shared |
Apply static and dynamic analysis tools within the application life cycle to verify that secure coding practices are being followed. |
To help identify and address potential security issues early in the development process, enhancing the overall security posture of the application.
|
|
22 |
| CIS_Controls_v8.1 |
16.13 |
CIS_Controls_v8.1_16.13 |
CIS Controls v8.1 16.13 |
Application Software Security |
Conduct application penetration testing |
Shared |
1. Conduct application penetration testing.
2. For critical applications, authenticated penetration testing is better suited to finding business logic vulnerabilities than code scanning and automated security testing.
3. Penetration testing relies on the skill of the tester to manually manipulate an application as an authenticated and unauthenticated user. |
To identify potential security weaknesses and assess the overall security posture of the application. |
|
22 |
| CIS_Controls_v8.1 |
16.2 |
CIS_Controls_v8.1_16.2 |
CIS Controls v8.1 16.2 |
Application Software Security |
Establish and maintain a process to accept and address software vulnerabilities |
Shared |
1. Establish and maintain a process to accept and address reports of software vulnerabilities, including providing a means for external entities to report.
2. The process is to include such items as: a vulnerability handling policy that identifies reporting process, responsible party for handling vulnerability reports, and a process for intake, assignment, remediation, and remediation testing.
3. As part of the process, use a vulnerability tracking system that includes severity ratings, and metrics for measuring timing for identification, analysis, and remediation of vulnerabilities.
4. Review and update documentation annually, or when significant enterprise changes occur that could impact this safeguard.
5. Third-party application developers need to consider this an externally-facing policy that helps to set expectations for outside stakeholders. |
To serve as an externally-facing document that establishes expectations for external stakeholders regarding vulnerability reporting and remediation procedures. |
|
22 |
| CIS_Controls_v8.1 |
16.5 |
CIS_Controls_v8.1_16.5 |
CIS Controls v8.1 16.5 |
Application Software Security |
Use up-to-date and trusted third-party software components |
Shared |
1. Use up-to-date and trusted third-party software components.
2. When possible, choose established and proven frameworks and libraries that provide adequate security.
3. Acquire these components from trusted sources or evaluate the software for vulnerabilities before use. |
To utilize up-to-date and trusted third-party software components in application development. |
|
17 |
| CIS_Controls_v8.1 |
16.6 |
CIS_Controls_v8.1_16.6 |
CIS Controls v8.1 16.6 |
Application Software Security |
Establish and maintain a severity rating system and process for application vulnerabilities |
Shared |
1. Establish and maintain a severity rating system and process for application vulnerabilities that facilitates prioritizing the order in which discovered vulnerabilities are fixed.
2. This process includes setting a minimum level of security acceptability for releasing code or applications.
3. Severity ratings bring a systematic way of triaging vulnerabilities that improves risk management and helps ensure the most severe bugs are fixed first.
4. Review and update the system and process annually. |
To establish and maintain a severity rating system and corresponding process for addressing application vulnerabilities, enabling prioritization of fixes based on severity levels, adapt to evolving threat landscapes and maintain effectiveness in mitigating risks. |
|
17 |
| CIS_Controls_v8.1 |
16.7 |
CIS_Controls_v8.1_16.7 |
CIS Controls v8.1 16.7 |
Application Software Security |
Use standard hardening configuration templates for application infrastructure |
Shared |
1. Use standard, industry-recommended hardening configuration templates for application infrastructure components.
2. This includes underlying servers, databases, and web servers, and applies to cloud containers, Platform as a Service (PaaS) components, and SaaS components.
3. Do not allow in-house developed software to weaken configuration hardening. |
To ensure that in-house developed software does not compromise the established configuration hardening standards. |
|
17 |
| CIS_Controls_v8.1 |
18.1 |
CIS_Controls_v8.1_18.1 |
CIS Controls v8.1 18.1 |
Penetration Testing |
Establish and maintain a penetration testing program |
Shared |
1. Establish and maintain a penetration testing program appropriate to the size, complexity, and maturity of the enterprise.
2. Penetration testing program characteristics include scope, such as network, web application, Application Programming Interface (API), hosted services, and physical premise controls; frequency; limitations, such as acceptable hours, and excluded attack types; point of contact information; remediation, such as how findings will be routed internally; and retrospective requirements. |
To establish and maintain a penetration testing program tailored to the size, complexity, and maturity of the enterprise. |
|
17 |
| CIS_Controls_v8.1 |
18.2 |
CIS_Controls_v8.1_18.2 |
CIS Controls v8.1 18.2 |
Penetration Testing |
Perform periodic external penetration tests |
Shared |
1. Perform periodic external penetration tests based on program requirements, no less than annually.
2. External penetration testing must include enterprise and environmental reconnaissance to detect exploitable information.
3. Penetration testing requires specialized skills and experience and must be conducted through a qualified party.
4. The testing may be clear box or opaque box.
|
To ensure thorough assessment and mitigation of potential vulnerabilities. |
|
16 |
| CIS_Controls_v8.1 |
18.3 |
CIS_Controls_v8.1_18.3 |
CIS Controls v8.1 18.3 |
Penetration Testing |
Remediate penetration test findings |
Shared |
Remediate penetration test findings based on the enterprise’s policy for remediation scope and prioritization. |
To mitigate security risks effectively. |
|
16 |
| 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. |
|
89 |
| CIS_Controls_v8.1 |
18.5 |
CIS_Controls_v8.1_18.5 |
404 not found |
|
|
|
n/a |
n/a |
|
16 |
| CMMC_L2_v1.9.0 |
SI.L1_3.14.1 |
CMMC_L2_v1.9.0_SI.L1_3.14.1 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 SI.L1 3.14.1 |
System and Information Integrity |
Flaw Remediation |
Shared |
Identify, report, and correct information and information system flaws in a timely manner. |
To safeguard assets and maintain operational continuity. |
|
23 |
| CMMC_L3 |
RE.2.137 |
CMMC_L3_RE.2.137 |
CMMC L3 RE.2.137 |
Recovery |
Regularly perform and test data back-ups. |
Customer |
The customer is responsible for implementing this requirement. |
Backups are used to recover data in the event of a hardware or software failure. Backups should be performed and tested regularly based on an organizational defined frequency. |
link |
6 |
| CMMC_L3 |
RE.3.139 |
CMMC_L3_RE.3.139 |
CMMC L3 RE.3.139 |
Recovery |
Regularly perform complete, comprehensive and resilient data backups as organizationally-defined. |
Customer |
The customer is responsible for implementing this requirement. |
The processes and tools used to properly back up critical information with a proven methodology for timely recovery of it. When attackers compromise machines, they often make significant changes to configurations and software. Sometimes attackers also make subtle alterations of data stored on compromised machines, potentially jeopardizing organizational effectiveness with polluted data. When the attackers are discovered, it can be extremely difficult for organizations without a trustworthy data recovery capability to remove all aspects of the attacker’s presence on the machine. This practice is based on the following CIS controls: 10.1 Ensure that all system data is automatically backed up on a regular basis. 10.2 Ensure that all of the organization’s key systems are backed up as a complete system, through processes such as imaging, to enable the quick recovery of an entire system. 10.5 Ensure that all backups have at least one offline (i.e., not accessible via a network connection) backup destination. |
link |
6 |
| CSA_v4.0.12 |
AIS_07 |
CSA_v4.0.12_AIS_07 |
CSA Cloud Controls Matrix v4.0.12 AIS 07 |
Application & Interface Security |
Application Vulnerability Remediation |
Shared |
n/a |
Define and implement a process to remediate application security
vulnerabilities, automating remediation when possible. |
|
22 |
| CSA_v4.0.12 |
CCC_07 |
CSA_v4.0.12_CCC_07 |
CSA Cloud Controls Matrix v4.0.12 CCC 07 |
Change Control and Configuration Management |
Detection of Baseline Deviation |
Shared |
n/a |
Implement detection measures with proactive notification in case
of changes deviating from the established baseline. |
|
22 |
| 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. |
|
46 |
| CSA_v4.0.12 |
TVM_08 |
CSA_v4.0.12_TVM_08 |
CSA Cloud Controls Matrix v4.0.12 TVM 08 |
Threat & Vulnerability Management |
Vulnerability Prioritization |
Shared |
n/a |
Use a risk-based model for effective prioritization of vulnerability
remediation using an industry recognized framework. |
|
22 |
| 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. |
|
64 |
| 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. |
|
62 |
| 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. |
|
189 |
| 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. |
|
62 |
| EU_2555_(NIS2)_2022 |
EU_2555_(NIS2)_2022_9 |
EU_2555_(NIS2)_2022_9 |
EU 2022/2555 (NIS2) 2022 9 |
|
National cyber crisis management frameworks |
Shared |
n/a |
Requires Member States to establish frameworks for managing large-scale cybersecurity incidents and crises. |
|
14 |
| EU_GDPR_2016_679_Art. |
24 |
EU_GDPR_2016_679_Art._24 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 24 |
Chapter 4 - Controller and processor |
Responsibility of the controller |
Shared |
n/a |
n/a |
|
306 |
| EU_GDPR_2016_679_Art. |
25 |
EU_GDPR_2016_679_Art._25 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 25 |
Chapter 4 - Controller and processor |
Data protection by design and by default |
Shared |
n/a |
n/a |
|
306 |
| EU_GDPR_2016_679_Art. |
28 |
EU_GDPR_2016_679_Art._28 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 28 |
Chapter 4 - Controller and processor |
Processor |
Shared |
n/a |
n/a |
|
306 |
| EU_GDPR_2016_679_Art. |
32 |
EU_GDPR_2016_679_Art._32 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 32 |
Chapter 4 - Controller and processor |
Security of processing |
Shared |
n/a |
n/a |
|
306 |
| 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. |
|
60 |
| 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 |
|
94 |
| FedRAMP_High_R4 |
CP-7 |
FedRAMP_High_R4_CP-7 |
FedRAMP High CP-7 |
Contingency Planning |
Alternate Processing Site |
Shared |
n/a |
The organization:
a. Establishes an alternate processing site including necessary agreements to permit the transfer and resumption of [Assignment: organization-defined information system operations] for essential missions/business functions within [Assignment: organization-defined time period consistent with recovery time and recovery point objectives] when the primary processing capabilities are unavailable;
b. Ensures that equipment and supplies required to transfer and resume operations are available at the alternate processing site or contracts are in place to support delivery to the site within the organization-defined time period for transfer/resumption; and
c. Ensures that the alternate processing site provides information security safeguards equivalent to that of the primary site.
Supplemental Guidance: Alternate processing sites are sites that are geographically distinct from primary processing sites. An alternate processing site provides processing capability in the event that the primary processing site is not available. Items covered by alternate processing site agreements include, for example, environmental conditions at alternate sites, access rules, physical and environmental protection requirements, and coordination for the transfer/assignment of personnel. Requirements are specifically allocated to alternate processing sites that reflect the requirements in contingency plans to maintain essential missions/business functions despite disruption, compromise, or failure in organizational information systems. Related controls: CP-2, CP-6, CP-8, CP-9, CP-10, MA-6.
References: NIST Special Publication 800-34. |
link |
2 |
| FedRAMP_Moderate_R4 |
CP-7 |
FedRAMP_Moderate_R4_CP-7 |
FedRAMP Moderate CP-7 |
Contingency Planning |
Alternate Processing Site |
Shared |
n/a |
The organization:
a. Establishes an alternate processing site including necessary agreements to permit the transfer and resumption of [Assignment: organization-defined information system operations] for essential missions/business functions within [Assignment: organization-defined time period consistent with recovery time and recovery point objectives] when the primary processing capabilities are unavailable;
b. Ensures that equipment and supplies required to transfer and resume operations are available at the alternate processing site or contracts are in place to support delivery to the site within the organization-defined time period for transfer/resumption; and
c. Ensures that the alternate processing site provides information security safeguards equivalent to that of the primary site.
Supplemental Guidance: Alternate processing sites are sites that are geographically distinct from primary processing sites. An alternate processing site provides processing capability in the event that the primary processing site is not available. Items covered by alternate processing site agreements include, for example, environmental conditions at alternate sites, access rules, physical and environmental protection requirements, and coordination for the transfer/assignment of personnel. Requirements are specifically allocated to alternate processing sites that reflect the requirements in contingency plans to maintain essential missions/business functions despite disruption, compromise, or failure in organizational information systems. Related controls: CP-2, CP-6, CP-8, CP-9, CP-10, MA-6.
References: NIST Special Publication 800-34. |
link |
2 |
| FFIEC_CAT_2017 |
3.3.1 |
FFIEC_CAT_2017_3.3.1 |
FFIEC CAT 2017 3.3.1 |
Cybersecurity Controls |
Patch Management |
Shared |
n/a |
- A patch management program is implemented and ensures that software and firmware patches are applied in a timely manner.
- Patches are tested before being applied to systems and/or software.
- Patch management reports are reviewed and reflect missing security patches. |
|
3 |
| hipaa |
1634.12b1Organizational.1-12.b |
hipaa-1634.12b1Organizational.1-12.b |
1634.12b1Organizational.1-12.b |
16 Business Continuity & Disaster Recovery |
1634.12b1Organizational.1-12.b 12.01 Information Security Aspects of Business Continuity Management |
Shared |
n/a |
The organization identifies the critical business processes requiring business continuity. |
|
5 |
| hipaa |
1638.12b2Organizational.345-12.b |
hipaa-1638.12b2Organizational.345-12.b |
1638.12b2Organizational.345-12.b |
16 Business Continuity & Disaster Recovery |
1638.12b2Organizational.345-12.b 12.01 Information Security Aspects of Business Continuity Management |
Shared |
n/a |
Business continuity risk assessments: (i) are carried out annually with full involvement from owners of business resources and processes; (ii) consider all business processes and is not limited to the information assets, but includes the results specific to information security; and, (iii) identifies, quantifies, and prioritizes risks against key business objectives and criteria relevant to the organization, including critical resources, impacts of disruptions, allowable outage times, and recovery priorities. |
|
5 |
| HITRUST_CSF_v11.3 |
10.c |
HITRUST_CSF_v11.3_10.c |
HITRUST CSF v11.3 10.c |
Correct Processing in Applications |
Incorporate validation checks into applications to detect any corruption of information through processing errors or deliberate acts. |
Shared |
Data integrity controls which manage changes, prevent sequencing errors, ensure recovery from failures, and protect against buffer overrun attacks are to be implemented. |
Validation checks shall be incorporated into applications to detect any corruption of information through processing errors or deliberate acts. |
|
35 |
| 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 |
| IRS_1075_9.3 |
.6.6 |
IRS_1075_9.3.6.6 |
IRS 1075 9.3.6.6 |
Contingency Planning |
Alternate Processing Site (CP-7) |
|
n/a |
The agency must:
a. Establish an alternate processing site, including necessary agreements to permit the transfer and resumption of information system operations, in accordance with the agency's contingency plan when the primary processing capabilities are unavailable
b. Ensure that equipment and supplies required to transfer and resume operations are available at the alternate processing site or contracts are in place to support delivery to the site within the agency-defined time period for transfer/resumption
c. Ensure that the alternate storage site provides information security safeguards that meet the minimum protection standards and the disclosure provisions of IRC 6103 |
link |
1 |
| ISO_IEC_27017_2015 |
12.3.1 |
ISO_IEC_27017_2015_12.3.1 |
ISO IEC 27017 2015 12.3.1 |
Operations Security |
Information Backup |
Shared |
For Cloud Service Customer:
Where the cloud service provider provides backup capability as part of the cloud service, the cloud service customer should request the specifications of the backup capability from the cloud service provider. The cloud service customer should also verify that they meet their backup requirements.
The cloud service customer is responsible for implementing backup capabilities when the cloud service provider does not provide them.
For Cloud Service Provider:
The cloud service provider should provide the specifications of its backup capabilities to the cloud service customer. The specifications should include the following information, as appropriate:
(i) scope and schedule of backups;
(ii) backup methods and data formats, including encryption, if relevant;
(iii) retention periods for backup data;
(iv) procedures for verifying integrity of backup data;
(v) procedures and timescales involved in restoring data from backup;
(vi) procedures to test the backup capabilities;
(vii) storage location of backups.
The cloud service provider should provide secure and segregated access to backups, such as virtual snapshots, if such service is offered to cloud service customers. |
To enable recovery from loss of data or systems. |
|
3 |
| New_Zealand_ISM |
06.4.5.C.01 |
New_Zealand_ISM_06.4.5.C.01 |
New_Zealand_ISM_06.4.5.C.01 |
06. Information security monitoring |
06.4.5.C.01 Availability requirements |
|
n/a |
Agencies MUST determine availability and recovery requirements for their systems and implement measures consistent with the agency's SRMP to support them. |
|
1 |
| NIST_CSF_v2.0 |
DE.CM_09 |
NIST_CSF_v2.0_DE.CM_09 |
NIST CSF v2.0 DE.CM 09 |
DETECT- Continuous Monitoring |
Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events. |
Shared |
n/a |
To identify and analyze the cybersecurity attacks and compromises. |
|
24 |
| NIST_CSF_v2.0 |
GV.OC_04 |
NIST_CSF_v2.0_GV.OC_04 |
NIST CSF v2.0 GV.OC 04 |
GOVERN-Organizational Context |
Critical objectives, capabilities, and services that external stakeholders depend on or expect from the organization are understood and communicated. |
Shared |
n/a |
To establish, communicate, and monitor the risk management strategy, expectations, and policy. |
|
1 |
| NIST_CSF_v2.0 |
RC.RP |
NIST_CSF_v2.0_RC.RP |
404 not found |
|
|
|
n/a |
n/a |
|
1 |
| NIST_CSF_v2.0 |
RC.RP_04 |
NIST_CSF_v2.0_RC.RP_04 |
NIST CSF v2.0 RC.RP 04 |
RECOVER- Incident Recovery Plan Execution |
Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms. |
Shared |
n/a |
To restore the assets and operations affected by a cybersecurity incident. |
|
1 |
| NIST_SP_800-171_R3_3 |
.14.1 |
NIST_SP_800-171_R3_3.14.1 |
NIST 800-171 R3 3.14.1 |
System and Information Integrity Control |
Flaw Remediation |
Shared |
Organizations identify systems that are affected by announced software and firmware flaws, including potential vulnerabilities that result from those flaws, and report this information to designated personnel with information security responsibilities. Security-relevant updates include patches, service packs, hot fixes, and anti-virus signatures. Organizations address the flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations can take advantage of available resources, such as the Common Weakness Enumeration (CWE) or Common Vulnerabilities and Exposures (CVE) databases, in remediating the flaws discovered in organizational systems. Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors, including the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types of remediation. |
a. Identify, report, and correct system flaws.
b. Install security-relevant software and firmware updates within [Assignment: organization-defined time period] of the release of the updates. |
|
23 |
| NIST_SP_800-171_R3_3 |
.15.2 |
NIST_SP_800-171_R3_3.15.2 |
NIST 800-171 R3 3.15.2 |
Planning Control |
System Security Plan |
Shared |
System security plans provide key characteristics of the system that is processing, storing, and transmitting CUI and how the system and information are protected. System security plans contain sufficient information to enable a design and implementation that is unambiguously compliant with the intent of the plans and the subsequent determinations of risk if the plan is implemented as intended. System security plans can be a collection of documents, including documents that already exist. Effective system security plans make use of references to policies, procedures, and additional documents (e.g., design specifications) where detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security information in other established management or operational areas related to enterprise architecture, the system development life cycle, systems engineering, and acquisition. |
a. Develop a system security plan that:
1. Defines the constituent system components;
2. Describes the system operating environment;
3. Describes specific threats to the system that are of concern to the organization
4. Provides an overview of the security requirements for the system;
5. Identifies connections to other systems;
6. Identifies individuals that fulfill system roles and responsibilities; and
7. Includes other relevant information necessary for the protection of CUI.
b. Review and update the system security plan periodically.
c. Protect the system security plan from unauthorized disclosure. |
|
3 |
| NIST_SP_800-171_R3_3 |
.17.1 |
NIST_SP_800-171_R3_3.17.1 |
NIST 800-171 R3 3.17.1 |
Supply Chain Risk Control |
Supply Chain Risk Management Plan |
Shared |
Dependence on the products, systems, and services from external providers and the nature of the relationships with those providers present an increasing level of risk to an organization. Threat actions that may increase security risks include unauthorized production; the insertion or use of counterfeits; tampering; theft; the insertion of malicious software, firmware, and hardware; and poor manufacturing and development practices in the supply chain. Supply chain risks can be endemic or systemic within a system, component, or service. Managing supply chain risks is a complex, multifaceted undertaking that requires a coordinated effort across an organization to build trust relationships and communicate with internal and external stakeholders.
Supply chain risk management (SCRM) activities include identifying and assessing risks, determining appropriate risk response actions, developing SCRM plans to document response actions, and monitoring performance against the plans. The system-level SCRM plan is implementation-specific and provides policy implementation, requirements, constraints, and implications. It can either be stand-alone or incorporated into system security plans. The SCRM plan addresses the management, implementation, and monitoring of SCRM controls and the development or sustainment of systems across the system development life cycle to support mission and business functions. Because supply chains can differ significantly across and within organizations, SCRM plans are tailored to individual program, organizational, and operational contexts. |
a. Develop a plan for managing supply chain risks associated with the research, development, design, manufacturing, acquisition, delivery, integration, operations, maintenance, and disposal of the system, system components, or system services.
b. Review and update the supply chain risk management plan periodically.
c. Protect the supply chain risk management plan from unauthorized disclosure. |
|
3 |
| NIST_SP_800-171_R3_3 |
.6.5 |
NIST_SP_800-171_R3_3.6.5 |
404 not found |
|
|
|
n/a |
n/a |
|
3 |
| NIST_SP_800-53_R4 |
CP-7 |
NIST_SP_800-53_R4_CP-7 |
NIST SP 800-53 Rev. 4 CP-7 |
Contingency Planning |
Alternate Processing Site |
Shared |
n/a |
The organization:
a. Establishes an alternate processing site including necessary agreements to permit the transfer and resumption of [Assignment: organization-defined information system operations] for essential missions/business functions within [Assignment: organization-defined time period consistent with recovery time and recovery point objectives] when the primary processing capabilities are unavailable;
b. Ensures that equipment and supplies required to transfer and resume operations are available at the alternate processing site or contracts are in place to support delivery to the site within the organization-defined time period for transfer/resumption; and
c. Ensures that the alternate processing site provides information security safeguards equivalent to that of the primary site.
Supplemental Guidance: Alternate processing sites are sites that are geographically distinct from primary processing sites. An alternate processing site provides processing capability in the event that the primary processing site is not available. Items covered by alternate processing site agreements include, for example, environmental conditions at alternate sites, access rules, physical and environmental protection requirements, and coordination for the transfer/assignment of personnel. Requirements are specifically allocated to alternate processing sites that reflect the requirements in contingency plans to maintain essential missions/business functions despite disruption, compromise, or failure in organizational information systems. Related controls: CP-2, CP-6, CP-8, CP-9, CP-10, MA-6.
References: NIST Special Publication 800-34. |
link |
2 |
| NIST_SP_800-53_R5.1.1 |
CP.2 |
NIST_SP_800-53_R5.1.1_CP.2 |
NIST SP 800-53 R5.1.1 CP.2 |
Contingency Planning Control |
Contingency Plan |
Shared |
a. Develop a contingency plan for the system that:
1. Identifies essential mission and business functions and associated contingency requirements;
2. Provides recovery objectives, restoration priorities, and metrics;
3. Addresses contingency roles, responsibilities, assigned individuals with contact information;
4. Addresses maintaining essential mission and business functions despite a system disruption, compromise, or failure;
5. Addresses eventual, full system restoration without deterioration of the controls originally planned and implemented;
6. Addresses the sharing of contingency information; and
7. Is reviewed and approved by [Assignment: organization-defined personnel or roles];
b. Distribute copies of the contingency plan to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements];
c. Coordinate contingency planning activities with incident handling activities;
d. Review the contingency plan for the system [Assignment: organization-defined frequency];
e. Update the contingency plan to address changes to the organization, system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing;
f. Communicate contingency plan changes to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements];
g. Incorporate lessons learned from contingency plan testing, training, or actual contingency activities into contingency testing and training; and
h. Protect the contingency plan from unauthorized disclosure and modification. |
Contingency planning for systems is part of an overall program for achieving continuity of operations for organizational mission and business functions. Contingency planning addresses system restoration and implementation of alternative mission or business processes when systems are compromised or breached. Contingency planning is considered throughout the system development life cycle and is a fundamental part of the system design. Systems can be designed for redundancy, to provide backup capabilities, and for resilience. Contingency plans reflect the degree of restoration required for organizational systems since not all systems need to fully recover to achieve the level of continuity of operations desired. System recovery objectives reflect applicable laws, executive orders, directives, regulations, policies, standards, guidelines, organizational risk tolerance, and system impact level.
Actions addressed in contingency plans include orderly system degradation, system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By coordinating contingency planning with incident handling activities, organizations ensure that the necessary planning activities are in place and activated in the event of an incident. Organizations consider whether continuity of operations during an incident conflicts with the capability to automatically disable the system, as specified in IR-4(5). Incident response planning is part of contingency planning for organizations and is addressed in the IR (Incident Response) family. |
|
1 |
| NIST_SP_800-53_R5.1.1 |
SI.2 |
NIST_SP_800-53_R5.1.1_SI.2 |
NIST SP 800-53 R5.1.1 SI.2 |
System and Information Integrity Control |
Flaw Remediation |
Shared |
a. Identify, report, and correct system flaws;
b. Test software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;
c. Install security-relevant software and firmware updates within [Assignment: organization-defined time period] of the release of the updates; and
d. Incorporate flaw remediation into the organizational configuration management process. |
The need to remediate system flaws applies to all types of software and firmware. Organizations identify systems affected by software flaws, including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security and privacy responsibilities. Security-relevant updates include patches, service packs, and malicious code signatures. Organizations also address flaws discovered during assessments, continuous monitoring, incident response activities, and system error handling. By incorporating flaw remediation into configuration management processes, required remediation actions can be tracked and verified.
Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of risk factors, including the security category of the system, the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw), the organizational risk tolerance, the mission supported by the system, or the threat environment. Some types of flaw remediation may require more testing than other types. Organizations determine the type of testing needed for the specific type of flaw remediation activity under consideration and the types of changes that are to be configuration-managed. In some situations, organizations may determine that the testing of software or firmware updates is not necessary or practical, such as when implementing simple malicious code signature updates. In testing decisions, organizations consider whether security-relevant software or firmware updates are obtained from authorized sources with appropriate digital signatures. |
|
23 |
| NIST_SP_800-53_R5 |
CP-7 |
NIST_SP_800-53_R5_CP-7 |
NIST SP 800-53 Rev. 5 CP-7 |
Contingency Planning |
Alternate Processing Site |
Shared |
n/a |
a. Establish an alternate processing site, including necessary agreements to permit the transfer and resumption of [Assignment: organization-defined system operations] for essential mission and business functions within [Assignment: organization-defined time period consistent with recovery time and recovery point objectives] when the primary processing capabilities are unavailable;
b. Make available at the alternate processing site, the equipment and supplies required to transfer and resume operations or put contracts in place to support delivery to the site within the organization-defined time period for transfer and resumption; and
c. Provide controls at the alternate processing site that are equivalent to those at the primary site. |
link |
2 |
| NZ_ISM_v3.5 |
ISM-7 |
NZ_ISM_v3.5_ISM-7 |
NZISM Security Benchmark ISM-7 |
Information security monitoring |
6.4.5 Availability requirements |
Customer |
n/a |
Availability and recovery requirements will vary based on each agency???s business needs and are likely to be widely variable across government. Agencies will determine their own availability and recovery requirements and implement measures consistent with the agency's SRMP to achieve them as part of their risk management and governance processes. |
link |
1 |
| NZISM_Security_Benchmark_v1.1 |
ISM-7 |
NZISM_Security_Benchmark_v1.1_ISM-7 |
NZISM Security Benchmark ISM-7 |
Information security monitoring |
6.4.5 Availability requirements |
Customer |
Agencies MUST determine availability and recovery requirements for their systems and implement measures consistent with the agency's SRMP to support them. |
Availability and recovery requirements will vary based on each agency’s business needs and are likely to be widely variable across government. Agencies will determine their own availability and recovery requirements and implement measures consistent with the agency's SRMP to achieve them as part of their risk management and governance processes. |
link |
1 |
| NZISM_v3.7 |
7.1.7.C.01. |
NZISM_v3.7_7.1.7.C.01. |
NZISM v3.7 7.1.7.C.01. |
Detecting Information Security Incidents |
7.1.7.C.01. - fortify information security measures. |
Shared |
n/a |
Agencies MUST develop, implement and maintain tools and procedures covering the detection of potential information security incidents, incorporating:
1. user awareness and training;
2. counter-measures against malicious code, known attack methods and types;
3. ntrusion detection strategies;
4. data egress monitoring & control;
5. access control anomalies;
6. audit analysis;
7. system integrity checking; and
8. vulnerability assessments. |
|
2 |
| NZISM_v3.7 |
7.1.7.C.02. |
NZISM_v3.7_7.1.7.C.02. |
NZISM v3.7 7.1.7.C.02. |
Detecting Information Security Incidents |
7.1.7.C.02. - detecting potential security incidents. |
Shared |
n/a |
Agencies SHOULD develop, implement and maintain tools and procedures covering the detection of potential information security incidents, incorporating:
1. user awareness and training;
2. counter-measures against malicious code, known attack methods and types;
3. intrusion detection strategies;
4. data egress monitoring & control;
5. access control anomalies;
6. audit analysis;
7. system integrity checking; and
8. vulnerability assessments. |
|
2 |
| NZISM_v3.7 |
7.1.7.C.03. |
NZISM_v3.7_7.1.7.C.03. |
NZISM v3.7 7.1.7.C.03. |
Detecting Information Security Incidents |
7.1.7.C.03. - optimize resource allocation and enhance overall security posture. |
Shared |
n/a |
Agencies SHOULD use the results of the security risk assessment to determine the appropriate balance of resources allocated to prevention versus resources allocated to detection of information security incidents. |
|
2 |
| NZISM_v3.7 |
7.3.10.C.01. |
NZISM_v3.7_7.3.10.C.01. |
NZISM v3.7 7.3.10.C.01. |
Managing Information Security Incidents |
7.3.10.C.01. - ensure compliance with legal and regulatory requirements and mitigate potential risks. |
Shared |
n/a |
Agencies considering allowing an attacker to continue some actions under controlled conditions for the purpose of seeking further information or evidence SHOULD seek legal advice. |
|
2 |
| NZISM_v3.7 |
7.3.11.C.01. |
NZISM_v3.7_7.3.11.C.01. |
NZISM v3.7 7.3.11.C.01. |
Managing Information Security Incidents |
7.3.11.C.01. - support comprehensive investigations and ensure accountability |
Shared |
n/a |
Agencies SHOULD:
1. transfer a copy of raw audit trails and other relevant data onto media for secure archiving, as well as securing manual log records for retention; and
2. ensure that all personnel involved in the investigation maintain a record of actions undertaken to support the investigation. |
|
8 |
| NZISM_v3.7 |
7.3.12.C.01. |
NZISM_v3.7_7.3.12.C.01. |
NZISM v3.7 7.3.12.C.01. |
Managing Information Security Incidents |
7.3.12.C.01. - ensure that agencies promptly request assistance from the NCSC upon detecting an information security incident. |
Shared |
n/a |
Agencies SHOULD ensure that any requests for NCSC assistance are made as soon as possible after the information security incident is detected and that no actions which could affect the integrity of the evidence are carried out prior to NCSC's involvement. |
|
2 |
| NZISM_v3.7 |
7.3.5.C.01. |
NZISM_v3.7_7.3.5.C.01. |
NZISM v3.7 7.3.5.C.01. |
Managing Information Security Incidents |
7.3.5.C.01. - establish clear accountability and effective incident response protocols. |
Shared |
n/a |
Agencies MUST detail information security incident responsibilities and procedures for each system in the relevant Information Security Documents. |
|
2 |
| NZISM_v3.7 |
7.3.6.C.01. |
NZISM_v3.7_7.3.6.C.01. |
NZISM v3.7 7.3.6.C.01. |
Managing Information Security Incidents |
7.3.6.C.01. - enhance incident management and oversight. |
Shared |
n/a |
Agencies SHOULD ensure that all information security incidents are recorded in a register. |
|
8 |
| NZISM_v3.7 |
7.3.6.C.02. |
NZISM_v3.7_7.3.6.C.02. |
NZISM v3.7 7.3.6.C.02. |
Managing Information Security Incidents |
7.3.6.C.02. - promote continuous improvement and informed decision-making. |
Shared |
n/a |
Agencies SHOULD use their incidents register as a reference for future security risk assessments. |
|
2 |
| NZISM_v3.7 |
7.3.7.C.01. |
NZISM_v3.7_7.3.7.C.01. |
NZISM v3.7 7.3.7.C.01. |
Managing Information Security Incidents |
7.3.7.C.01. - mitigate the risk of data breaches and ensure data protection. |
Shared |
n/a |
Agencies MUST implement procedures and processes to detect data spills. |
|
1 |
| NZISM_v3.7 |
7.3.7.C.02. |
NZISM_v3.7_7.3.7.C.02. |
NZISM v3.7 7.3.7.C.02. |
Managing Information Security Incidents |
7.3.7.C.02. - ensure a proactive and robust response to data spills. |
Shared |
n/a |
When a data spill occurs agencies MUST assume that data at the highest classification held on or processed by the system, has been compromised. |
|
1 |
| NZISM_v3.7 |
7.3.7.C.03. |
NZISM_v3.7_7.3.7.C.03. |
NZISM v3.7 7.3.7.C.03. |
Managing Information Security Incidents |
7.3.7.C.03. - establish clear and standardized procedures for incident response. |
Shared |
n/a |
Agency SOPs MUST include procedure for:
1. all personnel with access to systems;
2. notification to the ITSM of any data spillage; and
3. notification to the ITSM of access to any data which they are not authorised to access. |
|
1 |
| NZISM_v3.7 |
7.3.7.C.04. |
NZISM_v3.7_7.3.7.C.04. |
NZISM v3.7 7.3.7.C.04. |
Managing Information Security Incidents |
7.3.7.C.04. - ensure comprehensive incident response planning. |
Shared |
n/a |
Agencies MUST document procedures for dealing with data spills in their IRP. |
|
1 |
| NZISM_v3.7 |
7.3.7.C.05. |
NZISM_v3.7_7.3.7.C.05. |
NZISM v3.7 7.3.7.C.05. |
Managing Information Security Incidents |
7.3.7.C.05. - ensure consistent and effective response to data spills. |
Shared |
n/a |
Agencies MUST treat any data spill as an information security incident and follow the IRP to deal with it. |
|
1 |
| NZISM_v3.7 |
7.3.7.C.06. |
NZISM_v3.7_7.3.7.C.06. |
NZISM v3.7 7.3.7.C.06. |
Managing Information Security Incidents |
7.3.7.C.06. - uphold accountability and transparency. |
Shared |
n/a |
When a data spill occurs agencies MUST report the details of the data spill to the information owner. |
|
1 |
| NZISM_v3.7 |
7.3.8.C.01. |
NZISM_v3.7_7.3.8.C.01. |
NZISM v3.7 7.3.8.C.01. |
Managing Information Security Incidents |
7.3.8.C.01. - ensure compliance with security protocols and minimise potential breaches." |
Shared |
n/a |
When classified information is introduced onto a system not accredited to handle the information, the following actions MUST be followed:
1. Immediately seek the advice of an ITSM;
2. Segregate or isolate the affected system and/or data spill;
3. Personnel MUST NOT delete the higher classified information unless specifically authorised by an ITSM. |
|
1 |
| PCI_DSS_v4.0.1 |
12.10.1 |
PCI_DSS_v4.0.1_12.10.1 |
PCI DSS v4.0.1 12.10.1 |
Support Information Security with Organizational Policies and Programs |
Incident Response Plan |
Shared |
n/a |
An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident. The plan includes, but is not limited to:
• Roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of payment brands and acquirers, at a minimum.
• Incident response procedures with specific containment and mitigation activities for different types of incidents.
• Business recovery and continuity procedures.
• Data backup processes.
• Analysis of legal requirements for reporting compromises.
• Coverage and responses of all critical system components.
• Reference or inclusion of incident response procedures from the payment brands. |
|
2 |
| PCI_DSS_v4.0.1 |
6.3.3 |
PCI_DSS_v4.0.1_6.3.3 |
PCI DSS v4.0.1 6.3.3 |
Develop and Maintain Secure Systems and Software |
All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release. All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity’s assessment of the criticality of the risk to the environment as identified according to the risk ranking process at Requirement 6.3.1 |
Shared |
n/a |
Examine policies and procedures to verify processes are defined for addressing vulnerabilities by installing applicable security patches/updates in accordance with all elements specified in this requirement. Examine system components and related software and compare the list of installed security patches/updates to the most recent security patch/update information to verify vulnerabilities are addressed in accordance with all elements specified in this requirement |
|
23 |
| RBI_CSF_Banks_v2016 |
19.4 |
RBI_CSF_Banks_v2016_19.4 |
|
Incident Response & Management |
Recovery From Cyber - Incidents-19.4 |
|
n/a |
Bank???s BCP/DR capabilities shall adequately and effectively support the Bank???s
cyber resilience objectives and should be so designed to enable the bank to recover
rapidly from cyber-attacks/other incidents and safely resume critical operations
aligned with recovery time objectives while ensuring security of processes and data
is protected. |
|
2 |
| RBI_ITF_NBFC_v2017 |
6 |
RBI_ITF_NBFC_v2017_6 |
RBI IT Framework 6 |
Business Continuity Planning |
Business Continuity Planning (BCP) and Disaster Recovery-6 |
|
n/a |
BCP forms a significant part of an organisation's overall Business Continuity Management plan, which includes policies, standards and procedures to ensure continuity, resumption and recovery of critical business processes. BCP shall be designed to minimise the operational, financial, legal, reputational and other material consequences arising from a disaster. NBFC should adopt a Board approved BCP Policy. The functioning of BCP shall be monitored by the Board by way of periodic reports. The CIO shall be responsible for formulation, review and monitoring of BCP to ensure continued effectiveness. The BCP may have the following salient features |
link |
9 |
| RBI_ITF_NBFC_v2017 |
6.2 |
RBI_ITF_NBFC_v2017_6.2 |
RBI IT Framework 6.2 |
Business Continuity Planning |
Recovery strategy / Contingency Plan-6.2 |
|
n/a |
NBFCs shall try to fully understand the vulnerabilities associated with interrelationships between various systems, departments and business processes. The BCP should come up with the probabilities of various failure scenarios. Evaluation of various options should be done for recovery and the most cost-effective, practical strategy should be selected to minimize losses in case of a disaster. |
link |
8 |
| RBI_ITF_NBFC_v2017 |
6.4 |
RBI_ITF_NBFC_v2017_6.4 |
RBI IT Framework 6.4 |
Business Continuity Planning |
Recovery strategy / Contingency Plan-6.4 |
|
n/a |
NBFCs shall test the BCP either annually or when significant IT or business changes take place to determine if the entity could be recovered to an acceptable level of business within the timeframe stated in the contingency plan. The test should be based on ???worst case scenarios???. The results along with the gap analysis may be placed before the CIO and the Board. The GAP Analysis along with Board???s insight should form the basis for construction of the updated BCP. |
link |
4 |
| RMiT_v1.0 |
10.51 |
RMiT_v1.0_10.51 |
RMiT 10.51 |
Cloud Services |
Cloud Services - 10.51 |
Shared |
n/a |
A financial institution is required to consult the Bank prior to the use of public cloud for critical systems. The financial institution is expected to demonstrate that specific risks associated with the use of cloud services for critical systems have been adequately considered and addressed. The risk assessment shall address the risks outlined in paragraph 10.49 as well as the following areas:
(a) the adequacy of the overarching cloud adoption strategy of the financial institution including:
(i) board oversight over cloud strategy and cloud operational management;
(ii) senior management roles and responsibilities on cloud management;
(iii) conduct of day-to-day operational management functions;
(iv) management and oversight by the financial institution of cloud service providers;
(v) quality of risk management and internal control functions; and
(vi) strength of in-house competency and experience;
(b) the availability of independent, internationally recognised certifications of the cloud service providers, at a minimum, in the following areas:
(i) information security management framework, including cryptographic modules such as used for encryption and decryption of user data; and
(ii) cloud-specific security controls for protection of customer and counterparty or proprietary information including payment transaction data in use, in storage and in transit; and
(c) the degree to which the selected cloud configuration adequately addresses the following attributes:
(i) geographical redundancy;
(ii) high availability;
(iii) scalability;
(iv) portability;
(v) interoperability; and
(vi) strong recovery and resumption capability including appropriate alternate Internet path to protect against potential Internet faults. |
link |
6 |
| SOC_2023 |
CC2.3 |
SOC_2023_CC2.3 |
SOC 2023 CC2.3 |
Information and Communication |
Facilitate effective internal communication. |
Shared |
n/a |
Entity to communicate with external parties regarding matters affecting the functioning of internal control. |
|
214 |
| SOC_2023 |
CC5.3 |
SOC_2023_CC5.3 |
SOC 2023 CC5.3 |
Control Activities |
Maintain alignment with organizational objectives and regulatory requirements. |
Shared |
n/a |
Entity deploys control activities through policies that establish what is expected and in procedures that put policies into action by establishing Policies and Procedures to Support Deployment of Management’s Directives, Responsibility and Accountability for Executing Policies and Procedures, perform tasks in a timely manner, taking corrective actions, perform using competent personnel and reassess policies and procedures. |
|
225 |
| SOC_2023 |
CC7.4 |
SOC_2023_CC7.4 |
SOC 2023 CC7.4 |
Systems Operations |
Effectively manage security incidents, minimize their impact, and protect assets, operations, and reputation. |
Shared |
n/a |
The entity responds to identified security incidents by:
a. Executing a defined incident-response program to understand, contain, remediate, and communicate security incidents by assigning roles and responsibilities;
b. Establishing procedures to contain security incidents;
c. Mitigating ongoing security incidents, End Threats Posed by Security Incidents;
d. Restoring operations;
e. Developing and Implementing Communication Protocols for Security Incidents;
f. Obtains Understanding of Nature of Incident and Determines Containment Strategy;
g. Remediation Identified Vulnerabilities;
h. Communicating Remediation Activities; and,
i. Evaluating the Effectiveness of Incident Response and periodic incident evaluations. |
|
209 |
| SWIFT_CSCF_2024 |
2.2 |
SWIFT_CSCF_2024_2.2 |
SWIFT Customer Security Controls Framework 2024 2.2 |
Risk Management |
Security Updates |
Shared |
1. The closure of known security vulnerabilities is effective in reducing the various pathways that an attacker may use during an attack.
2. A security update process that is comprehensive, repeatable, and implemented in a timely manner is necessary to continuously close these known vulnerabilities when security updates are available. |
To minimise the occurrence of known technical vulnerabilities on operator PCs and within the user’s Swift infrastructure by ensuring vendor support, applying mandatory software updates, and applying timely security updates aligned to the assessed risk. |
|
23 |
| SWIFT_CSCF_v2021 |
2.5A |
SWIFT_CSCF_v2021_2.5A |
SWIFT CSCF v2021 2.5A |
Reduce Attack Surface and Vulnerabilities |
External Transmission Data Protection |
|
n/a |
Protect the confidentiality of SWIFT-related data transmitted or stored outside of the secure zone as part of operational processes. |
link |
11 |
| SWIFT_CSCF_v2021 |
6.4 |
SWIFT_CSCF_v2021_6.4 |
SWIFT CSCF v2021 6.4 |
Detect Anomalous Activity to Systems or Transaction Records |
Logging and Monitoring |
|
n/a |
Record security events and detect anomalous actions and operations within the local SWIFT environment. |
link |
29 |
| SWIFT_CSCF_v2022 |
2.5A |
SWIFT_CSCF_v2022_2.5A |
SWIFT CSCF v2022 2.5A |
2. Reduce Attack Surface and Vulnerabilities |
External Transmission Data Protection |
Customer |
n/a |
Protect the confidentiality of SWIFT-related data transmitted or stored outside of the secure zone as part of operational processes. |
link |
6 |
| SWIFT_CSCF_v2022 |
6.4 |
SWIFT_CSCF_v2022_6.4 |
SWIFT CSCF v2022 6.4 |
6. Detect Anomalous Activity to Systems or Transaction Records |
Record security events and detect anomalous actions and operations within the local SWIFT environment. |
Shared |
n/a |
Capabilities to detect anomalous activity are implemented, and a process or tool is in place to keep and review logs. |
link |
47 |
|
U.03.1 - Redundancy |
U.03.1 - Redundancy |
404 not found |
|
|
|
n/a |
n/a |
|
2 |
|
U.03.2 - Continuity requirements |
U.03.2 - Continuity requirements |
404 not found |
|
|
|
n/a |
n/a |
|
2 |
|
U.04.1 - Restore Function |
U.04.1 - Restore function |
404 not found |
|
|
|
n/a |
n/a |
|
3 |
|
U.04.2 - Restore Function |
U.04.2 - Restore Function |
404 not found |
|
|
|
n/a |
n/a |
|
3 |
|
U.04.3 - Tested |
U.04.3 - Tested |
404 not found |
|
|
|
n/a |
n/a |
|
3 |
|
U.17.1 - Encrypted |
U.17.1 - Encrypted |
404 not found |
|
|
|
n/a |
n/a |
|
5 |
| UK_NCSC_CAF_v3.2 |
D1 |
UK_NCSC_CAF_v3.2_D1 |
404 not found |
|
|
|
n/a |
n/a |
|
2 |
| UK_NCSC_CSP |
5.3 |
UK_NCSC_CSP_5.3 |
UK NCSC CSP 5.3 |
Operational security |
Protective Monitoring |
Shared |
n/a |
A service which does not effectively monitor for attack, misuse and malfunction will be unlikely to detect attacks (both successful and unsuccessful). As a result, it will be unable to quickly respond to potential compromises of your environments and data. |
link |
3 |