On April 4, 2024, CISA published a proposed rule in the Federal Register titled Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) Reporting Requirements. Let's take a look at what this proposed rule requires and how it applies to financial institutions.
Purpose
CISA is part of the Department of Homeland Security (DHS). As such, it is their job to help the nation prevent, detect, and respond to cybersecurity threats that could impact "national security, economic security, or public health and safety."
Until now, there has not been a "comprehensive and coordinated approach to understanding cyber incidents across critical infrastructure sectors." After the SolarWinds and Kaseya incidents, Congress said, "This seems like a problem!" So, they passed the reins to CISA (6 USC 681) and CISA got to work.
Overview & Definitions
The proposed rule requires two types of notifications:
- Cyber Incidents. This part would require "covered entities to report to CISA covered cyber incidents within 72 hours after the covered entity reasonably believes that a covered cyber incident has occurred." (Lots of coverage going on there.)
- Ransom Payments. This part would require covered entities to report "ransom payments made in response to a ransomware attack within 24 hours after the ransom payment has been made."
Words matter and (as CISA so thoroughly explains in the proposed rule) their words were selected very intentionally. Let's dive into a few of the key terms used here.
Definition #1: Covered Entities
In Section 226.2, CISA defines a "covered entity" as an entity in a critical infrastructure sector that does either of the following.
- It exceeds the small business size standard, per the NAICS in the U.S. Small Business Administration's size regulations (see 13 CFR Part 121).
- It meets a sector-based criterion. This is a lengthy list with a lot of very specific things (e.g., "[hospitals] with more than 100 beds"). But financial institutions just need to know that Section 226.2(b)(7) basically says financial institutions are covered entities.
CISA believes this definition strikes a balance between overreporting and underreporting. It puts the reporting burden on the entities that are the most capable, the most likely to be attacked, and the most likely to have an impact on the nation's security, and they're okay with that.
Definition #2: Covered Cyber Incidents
In Section 226.1, CISA defines a "covered cyber incident" as a "substantial cyber incident experienced by a covered entity." This definition has two parts:
- It must be a cyber incident. This is defined as "an occurrence that actually jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information on an information system, or actually jeopardizes, without lawful authority, an information system." This definition already exists in law (6 USC 650), so +1 for legal precedent.
- It must be substantial. For the incident to be substantial, it must lead to any of the following.
|
Summary |
Definition |
|
A big compromise of system or data security. |
"A substantial loss of confidentiality, integrity, or availability of a covered entity's information system or network." Determining if it is a "substantial loss" depends on things like "the type, volume, impact, and duration of the loss." |
|
Serious operational downtime. |
"A serious impact on the safety and resiliency of a covered entity's operational systems and processes." |
|
A business disruption. |
"A disruption of a covered entity's ability to engage in business or industrial operations, or deliver goods or services." |
|
Unauthorized access due to third-party compromise. |
"Unauthorized access to a covered entity's information system or network, or any nonpublic information contained therein, that is facilitated through or caused by either a compromise of a cloud service provider, managed service provider, other third-party data hosting provider, or a supply chain compromise." |
Exclusions
CISA's proposed definition identifies three exclusions:
- Lawful activity. It doesn't count if the government caused it (e.g., as part of a warrant).
- Good faith activity. It doesn't count if you asked for it to happen (e.g., penetration test).
- Threat of disruption as extortion. It doesn't count if you're threatened, but nothing happens.
None of these things would cause CISA to say, "Yeah, that's probably a threat to national security," so there's no need to report them.
Comparison with Existing Definitions
This definition is different from existing cyber incident reporting requirements.
- Credit Unions: You're in luck. Anything that would be considered a "reportable cyber incident" by the NCUA would probably be considered a "covered cyber incident" by CISA. The NCUA's definition largely aligns with CISA's definition and is even broader because it includes "imminent" cyber incidents, not just actual ones. Learn more.
- Banks: The FDIC, FRB, and OCC's definition of "notification incident" is similar, but narrower than CISA's definition of "covered cyber incident." This is largely due to the federal banking agencies' emphasis on "material" incidents and their serious or systemic economic impacts. Learn more.
Examples
In the commentary on the proposed rule, CISA provided examples of incidents that would (and would not) "likely qualify as substantial cyber incidents." For example, if a cyber incident encrypts a core information system, that would be a substantial cyber incident. If, however, anti-virus software quarantines the malware before it has a chance to execute, it would not be considered a substantial cyber incident.
CIRCIA Agreements (a.k.a., Less Reporting Burden)
CISA's requirements do not replace existing requirements of other federal agencies. That said, CISA is working with the federal agencies to create information sharing arrangements called "CIRCIA Agreements." If they're able to come to an agreement with your federal regulator, they'll post it on a public website and you'll only need to report the incident once, instead of to both agencies.
When in Doubt, Report It.
CISA emphasizes this point in the commentary on the proposed rule.
"CISA expects a covered entity to exercise reasonable judgment in determining whether it has experienced a cyber incident that meets one of the substantiality thresholds. If a covered entity is unsure as to whether a cyber incident meets a particular threshold, CISA encourages the entity to either proactively report the incident or reach out to CISA to discuss whether the incident needs to be reported."
Definition #3: Ransom Payment
In Section 226.1, CISA defines a ransom payment as "the transmission of any money or other property or asset, including virtual currency, or any portion thereof, which has at any time been delivered as ransom in connection with a ransomware attack."
No mincing words there. What's interesting is that CISA expects notification within 24 hours of the ransom payment being made. When they say "made," they mean:
- Disbursed (e.g., sent, transmitted, submitted, etc.), not received.
- Made by you or by a third party on your behalf (e.g., if a negotiator or insurance company pays).
24 hours is not a very long time. So, if you find yourself in a place where you have to make a decision on a ransom payment, be sure to sync your watch with CISA's accordingly.
CIRCIA Reports
CISA expects there will be four types of reports made, which they jointly call "CIRCIA Reports." CISA is planning to create a web-based form where covered entities can submit these reports. (In case the internet breaks, they'll also be offering an emergency backup telephone option, but would prefer for people to use the world wide web to submit their reports.)
Starting in Section 226.7, each of the form's required fields are defined. CISA wants to require each field listed below. Before they do, they want to hear your comments on whether they're requesting too much or too little.
|
Category |
Details |
|
CIRCIA Report Type |
There are four possible options:
|
|
Covered Entity Identifiers |
You'll need to tell CISA your company's full legal name, state of incorporation, affiliated trade names, physical address, website, critical infrastructure sector(s), etc. |
|
Contact Information |
CISA wants the names, email addresses, phone numbers, and titles for:
|
|
Third-Party Authorization |
If a third party reports on your behalf, then CISA wants them to mark a checkbox saying "I can do this." (Not like in an inspirational way… It's more about them being authorized to share your info.) |
|
Incident Description |
This is where you'd put the incident narrative and timeline, including details about what was affected, relevant dates, impacts, etc. |
|
Compromised Information |
This would include what information (or information categories) were compromised. (While this applies to everyone, this is probably most important to CISA when it's coming from the "we protect government secrets" crowd.) |
|
Exploited Vulnerabilities |
This would include things like what products or technologies were vulnerable. |
|
Current Controls |
CISA wants to know the security defenses you have in place that detected or helped mitigate the incident. |
|
Tactics, Techniques, and Procedures (TTPs) |
Share what you know about how the incident was perpetrated. Part of the reason CISA was authorized to implement these requirements is to help identify novel or sophisticated TTPs. |
|
Indicators of Compromise |
Any IOCs observed in connection with the incident. IOCs could include things like suspicious or unauthorized network traffic, files, registry entries, emails, system logins, accounts created, etc. |
|
Malware Details |
A description and samples of malicious software connected to the incident. |
|
Threat Actor Identifiers |
Any identification or contact information for malicious actors perpetrating the incident. |
|
Ransom Payment Details |
The date, amount, and types of assets involved with the payment, along with the ransom demand, instructions, and outcomes. (Note: These fields would only show if the report type was for a "Ransom Payment.") |
|
Mitigation & Response Activities |
How you handled (or are handling) the incident, including where you're at with the response process, how everything is going, and anybody helping you respond (e.g., law enforcement, other third parties, etc.). |
|
Any Other Data |
"Any other data or information as required by the web-based CIRCIA Incident Reporting Form or any other manner and form of reporting authorized." (This is interesting phrasing, as it could potentially be used by CISA to avoid having to submit future notices of proposed rulemaking, as any information they request in the future would technically be allowed under the rule.) |
CISA acknowledges that covered entities may not have all this information at the time of reporting, which is why they offer an option for "Supplemental Report." When substantial new or different information comes to light, CISA wants to know about that.
Retention Requirements
In Section 226.13, CISA proposes data and records preservation requirements. If a covered entity submits a CIRCIA Report, records related to the report are expected to be preserved for two years.
While this is not a comprehensive list, the proposed rule would require you to retain things like:
- Communications with any threat actor
- Indicators of compromise
- Relevant log entries and forensic artifacts
- Network data and system information
- Information about exfiltrated data
- All ransom payment records
- Incident reports
While the method of retention is left up to the covered entity, the records must be readily available and maintained in a secure manner.
Other Topics
The rest of the proposed rule included some interesting topics. For example:
- Section 226.14 talks about enforcement. As the requirements are framed in the context of national security, CISA has some pretty hefty options related to enforcement.
- Section 226.18 talks about confidentiality and legal considerations. This section goes over what CISA can and cannot do with CIRCIA Reports and the information contained within them. It also discusses liability and information sharing.
There are a lot of moving parts in these sections. Depending on what gets kept in the final rule, we encourage you to work with legal counsel to understand and be ready for these requirements.
Important Dates
Comments are due on the proposed rule by June 3, 2024. As these requirements apply broadly, certain groups are already calling for an extension of the comment period.
Extension or not, CISA plans to have the final rule published in 18 months (i.e., by the end of 2025). They expect the final rule to have an enforcement date in early 2026.
If you have questions or feedback on the proposed rule, you are welcome to submit a comment. We also encourage you to coordinate with your local banking associations. Determine if they are planning to submit a comment letter on the proposed rule and see how you can help them spread the word.
How Tandem Can Help
If you need help keeping track of all the required incident communications, check out Tandem Incident Management. This product is designed based on the NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide. It helps businesses create an incident response plan and track incidents. With features like notifications, reports, and an auto-generated incident timeline, this product is designed to help you prevent, detect, and respond to incidents when they occur.
Learn more at Tandem.App/Incident-Management-Software.
