Skip to content ↓ | Skip to navigation ↓

Requirements for reporting cybersecurity incidents to some regulatory or government authority are not new, but there has always been a large amount of inconsistency, globally, in exactly what the requirements are. More recently, there’s been a growing trend across government and regulatory bodies in the United States towards shorter timeframes for reporting of cybersecurity incidents. Here’s a brief rundown of the recent activity.

At the end of last year, the US Congress passed the National Defense Authorization Act (NDAA). The final version of the NDAA included a cybersecurity incident notification rule that applies only to critical infrastructure entities. It leaves the final threshold for notification to be determined by the Director of the Cybersecurity Incident Review Office, but states that “in no case may the Director require reporting by a covered entity earlier than 72 hours after confirmation that a covered cybersecurity incident has occurred.” This part of the legislation went through several revisions, however. The House version included a 72 hour notification that applied more broadly, and also a 24 hour notification requirement for ransomware payments. In mid-March, both the House and Senate passed a separate bill, the “Cyber Incident Reporting for Critical Infrastructure Act,” included in the “Consolidated Appropriations Act,” that clearly specifies a 72 hour reporting requirement for critical infrastructure entities.     

Also at the end of last year, the FDIC waded into the incident notification pool with a 36 hour requirement. The final rule was issued by The Federal Deposit Insurance Corporation (FDIC), the Board of Governors of the Federal Reserve System (Board), and the Office of the Comptroller of the Currency (OCC). Affected organizations must be compliant by May 1, 2022. The National Law Review points out that “[t]his timeline is shorter than any U.S. state data breach notification law and surpasses even the tightest time frame on U.S. books.”

Finally, to round out this trend, the Securities and Exchange Commission (SEC) issued in March a proposed rule that requires 48 hour notification for a subset of covered entities. This rule would specifically apply to registered investment advisers (RIAs), registered investment companies (RICs) and business development companies (BDCs). That list leaves out other publicly traded companies that the SEC regulates.  As this is a proposed rule, it’s open for comments for 60 days after publication.

While there is certainly other cybersecurity content in these rules, the focus around notification is over-balanced towards timeliness and away from completeness. Whether it’s 72, 48, or 36 hours, no organization is going to have a full picture of a cybersecurity incident in that amount of time. Investigating an incident takes time, and it’s not an easy process. An attacker may have been present in the environment for weeks or months, and unraveling their activity over that period of time requires skill, diligence, and patience.

A focus on timeliness of reporting, without a corresponding focus on completeness, feeds a news cycle that favors headlines over analysis. Reporting on the latest incident is far more interesting than reporting on the completed analysis of last year’s incident, especially if that analysis isn’t actually available.

Timely reporting of incidents does have value. It allows outside organizations, whether regulatory bodies or governments, to respond to incidents. It allows for the aggregation of data, and potentially for understanding larger patterns at play, which, in turn, allows for more rapid response to a multi-pronged incident that spans organizations or industries.

Completeness of reporting has equal, if not greater, value. By understanding the details of an incident, ideally the full timeline, both the affected organization and others can implement controls and mitigations to prevent any attacks that use similar tools or patterns. Industry organizations can use the data to deliver insights. We can see the value of this type of information today in annual reports like the Verizon Data Breach Investigations report, and in tools like the MITRE ATT&CK framework

But the detailed data collected on incidents are often incomplete, or provided voluntarily. Standards for what a complete incident report contains and methodologies for producing one are held largely in private, for profit organizations. Raising the baseline on incident investigations benefits everyone, and there are some signs that industry and government will head in this direction.

The launch of the Cyber Safety Review Board as part of CISA promises to adopt a new approach to investigating nationally significant incidents, and to bring a new level of transparency to the process. The CSRO is often compared to the National Transportation Safety Board. Over its history, the NTSB has issued more than 14,000 safety recommendations, with a whopping 73% of them being adopted by the entities to which they were directed.  If the CSRO follows the same path, we may see impactful cybersecurity recommendations coming directly out of this more public, more transparent process for investigations.

On a smaller scale, the SEC demonstrates an approach that addresses completeness and transparency as well. While the focus of the proposed SEC rule may be on fast reporting, it also includes an interesting requirement to provide updates within 48 hours “if any previously reported information about a significant cybersecurity incident becomes materially inaccurate or if the adviser discovers new material information related to an incident.” Since the SEC is focused on informing investors of risk, it’s likely that this type of information will be more publicly available because of this rule, assuming it’s adopted as-is.

With the continuously changing threat environment, increasingly rigorous reporting requirements are likely to proliferate. It’s important that the trend in timeliness of reporting be balanced with emphasis on the quality and completeness of the data as well.

[class^="wpforms-"]
[class^="wpforms-"]