+Event Log & Security-Relevant Telemetry Retention
|
Event Log & Security-Relevant Telemetry Retention
Description
Mechanisms exist to retain event logs and security-relevant telemetry for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and contractual retention requirements.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Managed Security Services Provider (MSSP)
∙ Log retention policy (minimum 90 days online, 1 year archived)
∙ Cloud log storage (e.g., AWS S3, Azure Storage)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Managed Security Services Provider (MSSP)
∙ Log retention policy (minimum 90 days online, 1 year archived)
∙ Cloud SIEM with configurable retention
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Security Incident Event Manager (SIEM) with defined retention schedules
∙ Managed Security Services Provider (MSSP)
∙ Log archiving to cold storage (e.g., AWS S3 Glacier, Azure Archive)
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ SIEM with tiered log retention (hot/warm/cold storage)
∙ Log retention policy aligned to regulatory requirements (e.g., HIPAA 6 yrs, PCI DSS 1 yr)
∙ Managed Security Services Provider (MSSP)
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise log retention program aligned to all applicable regulations
∙ SIEM with tiered retention (hot/warm/cold storage)
∙ Immutable log archives (e.g., AWS S3 Object Lock, Azure Blob WORM)
∙ Legal hold capability for investigation support
SCR-CMM
Level 0 Not Performed
Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.
Level 1 Performed Informally
Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred.
▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors.
Level 2 Planned Tracked
Continuous Monitoring (MON) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with MON domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
Level 3 Well Defined
Continuous Monitoring (MON) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs.
▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM)).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with MON domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ Secure Baseline Configurations (SBC) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis.
▪ An implemented and operational capability exists to retain event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and contractual retention requirements.
Level 4 Quantitatively Controlled
Utilize SCR-CMM Level 3 criteria definitions:
▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control.
▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.
Level 5 Continuously Improving
Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:
▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control.
▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies.
▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
1. Overview
1.1 References
1.2 Identified Requirements
1.3 Related Regulations
2. Identified Requirements
Requirements
| Source |
Requirement |
3. Related Regulations
Regulations
| Source |
Regulation |
|
EULAW
|
Article 19 Automatically generated logs
-
|
|
EULAW
|
Article 19 Automatically generated logs
-
|
|
EULAW
|
Article 8 Policies and procedures for ICT operations
-
|
|
EULAW
|
Article 12 Logging
-
|
|
EULAW
|
Article 21 Access control
Article 21
As part of their control of access management rights, financial entities shall develop, document, and implement a policy that contains all of the following:
(a)
the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access;
(b)
the segregation of duties designed to prevent unjustified access to critical data or to prevent the allocation of combinations of access rights that may be used to circumvent controls;
(c)
a provision on user accountability, by limiting to the extent possible the use of generic and shared user accounts and ensuring that users are identifiable for the actions performed in the ICT systems at all times;
(d)
a provision on restrictions of access to ICT assets, setting out controls and tools to prevent unauthorised access;
(e)
account management procedures to grant, change or revoke access rights for user and generic accounts, including generic administrator accounts, including provision on all of the following:
(i)
assignment of roles and responsibilities for granting, reviewing, and revoking access rights;
(ii)
assignment of privileged, emergency, and administrator access on a need-to-use or an ad-hoc basis for all ICT systems;
(iii)
withdrawal of access rights without undue delay upon termination of the employment or when the access is no longer necessary;
(iv)
update of access rights where changes are necessary and at least once a year for all ICT systems, other than ICT systems supporting critical or important functions and at least every 6 months for ICT systems supporting critical or important functions;
(f)
authentication methods, including all of the following:
(i)
the use of authentication methods commensurate to the classification established in accordance with Article 8(1) of Regulation (EU) 2022/2554 and to the overall risk profile of ICT assets and considering leading practices;
(ii)
the use of strong authentication methods in accordance with leading practices and techniques for remote access to the financial entity’s network, for privileged access, for access to ICT assets supporting critical or important functions or ICT assets that are publicly accessible;
(g)
physical access controls measures including:
(i)
the identification and logging of natural persons that are authorised to access premises, data centres, and sensitive designated areas identified by the financial entity where ICT and information assets reside;
(ii)
the granting of physical access rights to critical ICT assets to authorised persons only, in accordance with the need-to-know and least privilege principles, and on an ad-hoc basis;
(iii)
the monitoring of physical access to premises, data centres, and sensitive designated areas identified by the financial entity where ICT and information assets or both reside;
(iv)
the review of physical access rights to ensure that unnecessary access rights are promptly revoked.
For the purposes of point (e)(i), financial entities shall establish the retention period taking into account the business and information security objectives, the reasons for recording the event in the logs, and the results of the ICT risk assessment.
For the purposes of point (e)(ii), financial entities shall, where possible, use dedicated accounts for the performance of administrative tasks on ICT systems. Where feasible and appropriate, financial entities shall deploy automated solutions for the privilege access management.
For the purposes of point (g)(i), the identification and logging shall be commensurate with the importance of the premises, data centres, sensitive designated areas, and the criticality of the operations or ICT systems located therein.
For the purposes of point (g)(iii), the monitoring shall be commensurate to the classification established in accordance with Article 8(1) of Regulation (EU) 2022/2554 and the criticality of the area accessed.
|
|
EULAW
|
Article 22 ICT-related incident management policy
Article 22
ICT-related incident management policy
As part of the mechanisms to detect anomalous activities, including ICT network performance issues and ICT-related incidents, financial entities shall develop, document, and implement an ICT-related incident policy through which they shall:
(a)
document the ICT-related incident management process referred to in Article 17 of Regulation (EU) 2022/2554;
(b)
establish a list of relevant contacts with internal functions and external stakeholders that are directly involved in ICT operations security, including on:
(i)
the detection and monitoring of cyber threats;
(ii)
the detection of anomalous activities;
(iii)
vulnerability management;
(c)
establish, implement, and operate technical, organisational, and operational mechanisms to support the ICT-related incident management process, including mechanisms to enable a prompt detection of anomalous activities and behaviours in accordance with Article 23 of this Regulation;
▼C1
(d)
retain all evidence relating to ICT-related incidents for a period that shall be no longer than necessary for the purposes for which the data are collected, commensurate with the criticality of the affected business functions, supporting processes, and ICT and information assets, in accordance with Article 8(2) of Commission Delegated Regulation (EU) 2024/1772 (
2
) and with any applicable retention requirement pursuant to Union law;
▼B
(e)
establish and implement mechanisms to analyse significant or recurring ICT-related incidents and patterns in the number and the occurrence of ICT-related incidents.
For the purposes of point (d), financial entities shall retain the evidence referred to in that point in a secure manner.
|
Linked Issues
- Secure Controls Framework -
"The SCF is the Common Controls Framework™ (CCF), the world's most comprehensive cybersecurity and data privacy metaframework - it is also free to use. The entire concept is building secure, compliant and resilient capabilities in the most efficient and cost-effective manner possible.
The SCF is more than just a unified control catalog, since its included content creates a playbook for Governance, Risk & Compliance (GRC) capabilities. Used globally by organizations of every size, the SCF is a robust and scalable solution for security, compliance and resilience controls. As a comprehensive security framework, the SCF maps 1,400+ controls across 200+ laws, regulations, and industry frameworks so you can implement once and comply everywhere.
Like it or not, cybersecurity is a protracted war on an asymmetric battlefield, where the threats are everywhere and as defenders we have to make the effort to work together to help improve cybersecurity and data privacy practices, since we all suffer when massive data breaches occur or when cyber attacks have physical impacts. Hackers share information on attack methods with other hackers, so why shouldn’t the good guys share information on how to best protect an organization? We decided to take action and make a difference, since we feel it is too important to wait for someone else to fix the problems that exist.
The SCF is made up of volunteers, mainly specialists within the cybersecurity profession, who focus on GRC and the cybersecurity side of data privacy. These are auditors, engineers, architects, incident responders, consultants and other specialists who live and breathe these topics on a daily basis. The end product is "expert-derived content" that makes up the SCF." https://securecontrolsframework.com/
Terms & Conditions
The SCF End User License Agreement (EULA) governs the use of the Secure Controls Framework® (SCF) under the Creative Commons Attribution-No Derivatives 4.0 International Public License.
|