Adding to the growing number of cybersecurity incident reporting obligations, the Cybersecurity and Infrastructure Security Agency (“CISA”) has introduced a reporting requirement that will impact all critical infrastructure sectors, featuring highly detailed reporting duties that necessarily will require covered entities to maintain asset inventories, along with subpoena power and criminal enforcement authority. Back in March 2022, President Biden signed the Cyber Incident Reporting for Critical Infrastructure Act (“CIRCIA”) into law, establishing reporting requirements for critical infrastructure entities that experience covered cybersecurity incidents and requiring CISA to implement the law via rulemaking. Two years later, the moment has finally arrived. On March 27, 2024, CISA issued its long-awaited and 400-plus-page Notice of Proposed Rulemaking (“Proposed Rule”).

The Proposed Rule, which CISA estimates will affect over 300,000 entities, reflects a notable shift for CISA, which historically relied on voluntary partnerships with industry to achieve its mission. CISA now intends to enforce compliance with incident and ransom payment reporting obligations with significant information sharing expectations, including through subpoena authority and potential criminal prosecution. The Proposed Rule is reflective of the federal government’s broader view that voluntary cybersecurity frameworks are not sufficient to protect American critical infrastructure.

In this Debevoise Data Blog post, we discuss the background of the Proposed Rule, outline its most notable provisions and offer key takeaways for companies that may fall within its reach.

Background

CIRCIA was enacted to provide the federal government with greater visibility over cybersecurity threats affecting the nation’s critical infrastructure and to facilitate deployment of resources to efficiently respond to such attacks. CIRCIA requires critical infrastructure entities to report substantial cybersecurity incidents and ransomware payments to CISA within 72 and 24 hours, respectively. CIRCIA required CISA to promulgate a proposed regulation (the subject of this blog post) within 24 months, and a Final Rule within 18 months of the publication of the Proposed Rule.

This Proposed Rule adds to the morass of U.S. cyber regulations, as CISA itself notes while explaining how it fits against the current backdrop of cyber incident reporting. Indeed, there is duplication between the Proposed Rule and many existing regulations, despite the Proposed Rule’s discussion of pursuing harmonization. For example, the Proposed Rule does not preempt existing agency reporting rules, meaning that pre-existing rules for critical infrastructure owners and operators with shorter timelines for reporting to CISA—such as the Transportation Security Administration (“TSA”) rules for pipeline, rail, and aviation operators, and the 36-hour notification obligation for banking organizations—will remain in effect. However, CIRCIA does allow CISA and other agencies to enter into interagency agreements that could promote harmonization and reduce duplicative reporting requirements. How common and effective these interagency agreements will be remains to be seen.

However, the breadth of the Proposed Rule aims to accomplish CISA’s noble goal of gathering actionable threat intelligence for the government to leverage. As CISA explains, the Proposed Rule will allow the federal government to support reliable trend analysis, vulnerability identification, and the provision of early warnings.

Industry Feedback

The Proposed Rule builds upon feedback the Department of Homeland Security solicited following CIRCIA’s passage in March 2022, which included a public comment period and listening tour with each of the 16 critical infrastructure sectors. Industry consistently requested:

  • Clearly articulated goals for the Proposed Rule;
  • Definitional clarity; and
  • A web-based portal as a means for submission of reports to CISA.

Overview of the Proposed Rule

Against this backdrop of the Proposed Rule’s history and the critical infrastructure industry’s requests, it’s now time to dive into the text.

Definitions

What Incidents Are Covered? The Proposed Rule defines “cyber incident” to mean “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.” While not identical, and not limited to any particular owner of the information or information system, this definition is similar to the SEC’s definition of a “cybersecurity incident” under the new SEC cybersecurity rules for issuers.

The Proposed Rule requires covered entities to report those cyber incidents that qualify as “covered,” and a “covered cyber incident” is defined as “a substantial cyber incident experienced by a covered entity.” In turn, a “substantial cyber incident” is “a cyber incident that leads to any of the following: (a) a substantial loss of confidentiality, integrity, or availability of a covered entity’s information system or network; (b) a serious impact on the safety and resiliency of a covered entity’s operational systems and processes; (c) a disruption of a covered entity’s ability to engage in business or industrial operations, or deliver goods or services; or (d) 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.”

Several points are worth noting. First, “substantial” differs from terminology used in other reporting requirements, including reportable incidents that “materially disrupt” (OCC/FDIC/FRB) or have “an actual or potentially adverse effect” (Dept. of Defense), or, looking outside the United States, that are “major” (EU DORA) or merely “compromising” (EU NIS 2), just to name a few. These differences across definitions will create additional complexity for entities trying to comply with and assess multiple notification obligations simultaneously.

“Substantial” does, however, align with terminology used in a subsection of the model definition of a “reportable cyber incident” that the Department of Homeland Security (“DHS”) and the Cyber Incident Reporting Council (“CIRC”) recommended last year, as does much of the language used in subsections (a)-(c).

Nevertheless, CISA opted not to use the model definition verbatim. While the model definition covers both (i) incidents “leading to” certain outcomes and (ii) incidents that, while under investigation, “could reasonably lead to” those outcomes, CISA’s definitions require actual impact that “leads to” a defined outcome, which does mitigate against defensive notification scenarios where entities overreport because the standard is broad and unclear.

Finally, consistent with its attention to third party and supply chain attacks, CISA expanded the model definition to more explicitly focus on supply chain and third-party risks under (d), setting a lower threshold than for other scenarios in that any unauthorized access arising from the enumerated sources would seemingly trigger notification, even where the impact on the covered entity is not actually “substantial” or “serious” and does not cause “a disruption”.

Who Is Covered? The Proposed Rule applies CIRCIA’s reporting requirements to entities in a critical infrastructure sector, defined according to sector descriptions developed under the Presidential Policy Directive 21 (“PPD-21”), that either:

  • Exceed the small business size standard specified by the applicable North American Industry Classification System Code in the SBA Size Standards, which are codified in 13 CFR part 121; or
  • Meet one or more sector-based criteria, regardless of what sector the entity considers itself to be in, including, among others, entities involved in the following: (i) providing wire or radio communications services; (ii) performing emergency services or functions; or (iii) owning or operating financial services sector infrastructure, including banking organizations. These criteria enumerate sector-specific regulations and are based on entities’ ownership or operation of certain facilities or critical infrastructure-related functions. Stay tuned for a follow-up blog post on just this topic.

Relying on CIRCIA’s definition of a covered entity, CISA’s approach broadens the pool of covered entities beyond those that would be designated themselves as owners or operators of critical infrastructure to also include all entities that operate in the sector above a certain size and those that meet sector criteria regardless of size—and potentially pose a systemic sector risk as a result—in the interest of obtaining a greater range of reporting data with which to catalog and respond to industry cyber threats. While broad, in practice the scope of covered entities may achieve industry’s ask for definitional clarity, although a careful review by industries of the sector-based criteria during the comment period and potential burden to smaller entities is needed.

Reporting

Reporting Requirements. The Proposed Rule establishes reporting requirements for (1) covered cyber incidents and (2) ransom payments, and it suggests a level of detail in reporting never before seen in a cyber rulemaking. It requires a remarkably high level of technical detail about the impact of a covered cyber incident,[1] including:

  • A description of the covered incident, containing, among other things: (i) an identification and description of the affected information systems, networks or devices, including their physical locations; (ii) a description of the unauthorized access with substantial loss of confidentiality, integrity or availability of the affected information system or network or disruption of business or industrial operations (including the network location the activity was observed in); (iii) a timeline of the incident, including the dates of detection, mitigation and a timeline of compromised system communications with other systems; and (iv) details regarding the nature of the impact to the covered entity’s operations;
  • The vulnerabilities exploited, including the specific products or technologies and versions in which such vulnerabilities were found; the entity’s security defenses, along with any security controls in place (mentioning, among others, NIST’s Cybersecurity Framework) and which controls failed; information regarding the type of incident, including the TTPS, indicators of compromise, and a description and copy of the malicious software believed to have been used;
  • Information related to the identity of the perpetrator of the incident, which includes any identifying, contact or other attribution-related information the entity may possess; and
  • Mitigation and response activities undertaken by the entity in response to the incident.

For those questioning how to identify the immense level of detail—often simply unknown initially—and allocate resources to gather those answers in the early hours of a high-intensity incident response: the Proposed Rule permits answers such as “unknown at this time” in initial reporting to account for the inherent uncertainty when reporting cyber incidents while facts are still unfolding in real time.

Data Preservation. Covered entities making such reports to CISA are required to preserve data and records relevant to the incident or ransom payment, including communications with threat actors, indicators of compromise, relevant log entries, the attack vector, and more. Such data must be preserved for at least two years following the submission of the entity’s latest report to CISA. Depending on the scale of the incident, the corresponding data preservation can be costly, particularly for entities just barely exceeding the small business threshold described above.

Timing of Reporting. As expected, CIRCIA’s timelines, reflected in the Proposed Rule, are tight. Covered entities must report covered cyber incidents, including all of the details listed above if available, “not later than 72 hours after the covered entity reasonably believes that the covered cyber incident has occurred.”[2] Ransom payments made by covered entities, in turn, must be reported to CISA “not later than 24 hours after the ransom payment has been made.” The Proposed Rule calls out several exceptions, including that entities may submit a single report for a covered cyber incident and ransom payment when the payment related to the incident was made within the 72-hour window for reporting that covered cyber incident. Supplemental reports must be submitted “promptly” if substantial new or different information becomes available or the covered entity makes a ransom payment after reporting a covered cyber incident.[3] This requirement continues unless and until an entity notifies CISA that the underlying covered cyber incident has concluded and been fully mitigated.[4]

Commensurate with the extensive detail that the Proposed Rule requires entities to provide, it also offers a variety of protections and restrictions on the use of that reported information. For example, (i) the information would be exempt from disclosure under the Freedom of Information Act (“FOIA”), (ii) the government could not use the information in regulatory actions (subject to certain exceptions, e.g., if the government entity expressly allows the covered entity to meet its regulatory reporting obligations through submission of reports to CISA), and (iii) any person or entity submitting compliant reports to CISA would be provided liability protection against causes of action brought by any person or entity solely based on submission of a report or response to a request for information (“RFI”) under the Proposed Rule. Notably, covered entities do not waive any applicable privilege by submitting reports to CISA, and the reports are not admissible in court or subject to discovery. These protections are intended to support CISA’s ability to obtain more time-sensitive cyber threat intelligence and leverage its information-sharing mechanisms to help the industry better respond to cyberattacks.

Enforcement Mechanisms

In the event CISA believes that a covered entity has failed to submit a timely report, the Proposed Rule offers several enforcement mechanisms, including: (i) issuance of an RFI; (ii) issuance of a subpoena, if a response to an RFI is not received within 72 hours, noncompliance with which may be referred to the Attorney General, who may then seek to bring a civil action; and (iii) other enforcement mechanisms such as potential acquisition penalties, suspension and debarment. In deciding whether to pursue any of these avenues, the Proposed Rule cautions CISA to first consider the complexity of determining whether a covered cyber incident occurred, as well as the covered entity’s prior interactions with CISA or its understanding of the policies and procedures for reporting covered incidents and ransom payments.

The Proposed Rule also provides for the Department of Justice (“DOJ”) to seek criminal penalties for knowingly and willfully making materially false or fraudulent statements or representations in connection with, or within, reports made to CISA. In practice, CISA would refer potential violations to the DOJ, and the DOJ would then make the determination whether or not to prosecute. The protections and restrictions on use applicable to compliant reports submitted to CISA would not apply to such actions. This imposition is reflective of and expands upon the federal government’s recent trend—perhaps best exemplified by the SEC’s 2023 enforcement action against SolarWinds and its Chief Information Security Officer, Tim Brown—of pursuing companies suspected of making fraudulent statements in their cyber incident disclosures, especially in the context of critical infrastructure.

What Should Companies Do?

  1. Determine Whether You Are a “Covered Entity.” Assess the Proposed Rule’s applicability to your organization by, first, reviewing the sector-specific plans for the 16 critical infrastructure sectors established under PPD-21. If your entity is “in” one of those sectors, you are a covered entity unless (i) the small business definition applies and (ii) none of the Proposed Rule’s sector-specific criteria apply.
  2. Consider Supply Chain Obligations. Cloud service providers, managed service providers, third-party data hosting providers and other entities providing services within a supply chain, to the extent they are not covered entities, should still take note of the incident reporting obligation related to incidents that arise from their platforms and services and prepare to be called upon during an incident for information and assistance in meeting the covered entity’s own reporting obligations.
  3. Conduct a Gap Assessment. While the Proposed Rule is likely to change in some respects before finalization, covered entities can still begin to consider conducting a gap assessment of the Proposed Rule’s requirements around notifications, internal policies, and practices (e.g., recordkeeping) to identify areas that may require adjustments during the final rule’s implementation period.
  4. Consider Your Law Enforcement Reporting Position. In general, companies should already be reporting their significant cyber incidents to law enforcement, but FBI statistics reveal that many cyber incident victims are not doing so. This low reporting rate is concerning, especially given how helpful law enforcement often can be—and indeed, is—in responding to cyber incidents. Given that the Proposed Rule will require covered entities to report to CISA, and those companies will likely consider reporting to the FBI in parallel, now is the time for companies to consider their reporting position and adjust incident response plans accordingly.
  5. Develop a Notification Framework. Beyond updating an incident response plan, consider developing a framework for assessing, documenting and reporting initial and supplemental submissions under the final rule. Companies can prepare templates ahead of time that map both the substance and process required to complete timely and compliant notification reports, including how to gather the technical information required by the Proposed Rule.
  6. Keep an Asset Inventory. The Proposed Rule’s strict requirements for identifying the physical location of affected networks, devices, and information systems, among other key details, mean that covered companies should be prepared to identify the physical location of their affected devices in the event of a cyber incident. This will require the creation and regular maintenance of an asset inventory, which can be challenging for companies to produce and update at a regular cadence, and compliance may require additional resource allocations‑particularly for assets in cloud storage that will need to be maintained in their original format under the Proposed Rule’s preservation requirements.
  7. Leverage Pre-Existing Frameworks. As we’ve observed, many of the Proposed Rule’s obligations can be costly and burdensome, particularly for smaller critical infrastructure entities. Smaller entities with less robust processes than industry giants should look to frameworks that reflect industry best practices, such as the NIST Cybersecurity Framework. These can provide an excellent starting point and help smaller entities map their policies against the industry-wide gold standard.
  8. Submit a Comment. Even if your business is unlikely to fall within the Proposed Rule’s purview, take the opportunity to comment during the 60-day notice and comment period, which is open until Monday, June 3, 2024.

To subscribe to the Data Blog, please click here.

 

[1] For ransom payments, the Proposed Rule requires less detail, but requests similar categories of information. This Blog Post focuses on the reporting requirements for covered cybersecurity incidents.

[2] Note that CISA has deliberately left the phrase “reasonably believes” undefined to account for the subjective and fact-specific circumstances of individual cyber incidents.

[3] “Promptly” is to be interpreted as “without delay or as soon as possible,” and in the case of ransom payments made following a reported covered cyber incident, within 24 hours of such payment.

[4] Interestingly, this final report is labeled as optional.

Author

Avi Gesser is Co-Chair of the Debevoise Data Strategy & Security Group. His practice focuses on advising major companies on a wide range of cybersecurity, privacy and artificial intelligence matters. He can be reached at agesser@debevoise.com.

Author

Luke Dembosky is a Debevoise litigation partner based in the firm’s Washington, D.C. office. He is Co-Chair of the firm’s Data Strategy & Security practice and a member of the White Collar & Regulatory Defense Group. His practice focuses on cybersecurity incident preparation and response, internal investigations, civil litigation and regulatory defense, as well as national security issues. He can be reached at ldembosky@debevoise.com.

Author

Jim Pastore is a Debevoise litigation partner and a member of the firm’s Data Strategy & Security practice and Intellectual Property Litigation Group. He can be reached at jjpastore@debevoise.com.

Author

Erez is a litigation partner and a member of the Debevoise Data Strategy & Security Group. His practice focuses on advising major businesses on a wide range of complex, high-impact cyber-incident response matters and on data-related regulatory requirements. Erez can be reached at eliebermann@debevoise.com

Author

Caroline Swett is a partner in Debevoise’s Financial Institutions and Banking Groups. She advises domestic and foreign banks and other financial institutions on a wide range of regulatory, enforcement and transactional matters. She can be reached at cnswett@debevoise.com.

Author

H Jacqueline Brehmer is a Debevoise litigation associate and a member of the Data Strategy & Security Practice Group. She can be reached at hjbrehmer@debevoise.com.

Author

Gabriel Kohan is a litigation associate at Debevoise and can be reached at gakohan@debevoise.com.

Author

Michael R. Roberts is a senior associate in Debevoise & Plimpton’s global Data Strategy and Security Group and a member of the firm’s Litigation Department. His practice focuses on privacy, cybersecurity, data protection and emerging technology matters. He can be reached at mrroberts@debevoise.com.

Author

Stephanie D. Thomas is an associate in the Litigation Department and a member of the firm’s Data Strategy & Security Group and the White Collar & Regulatory Defense Group. She can be reached at sdthomas@debevoise.com.

Author

Annabella Waszkiewicz is a law clerk in the Litigation Department.