Insane Incident Incursion Recursion: Mastering Incident Response Reporting Regulations

The unthinkable has happened. Despite your organization’s cybersecurity defenses and years of focused improvements for Industrial Control System (ICS) security— it’s actually happened. A cyber incident with impacts to your ICS environment. Luckily, you’ve planned for this. Perhaps you’ve taken ICS515 or ICS456, focusing specifically on incident response for your industry. Your team knows the intricacies around forensics in industrial environments, the importance of evidence collection for root cause analysis, and the steps involved to recover reliable operations.

While response and recovery require late nights and unique challenges, you and your team are well-practiced and ready.

As you grab your jump-bag and head to the site, you check an urgent notification from General Counsel. They want to know what they should include in their report to the Department of Homeland Security’s (DHS) National Cybersecurity and Communication Integration Center (NCCIC) due in an hour. You stop dead in your tracks. You’ve yet to analyze any logs, why is legal asking for a report to DHS?

It looks like your team may not be so ready after all.

Unfortunately, this has become an increasingly frustrating phenomena for industrial organizations. Incident response, once a purely technical discipline, now requires increased participation from legal, compliance, and corporate communications professionals. Today’s regulatory landscape is more complicated than ever for asset owners and operators—and it’s impossible to avoid overlapping requirements for incident response.

So how do we prepare for the inevitable?

Regulations and You: Understand What Applies

As I mentioned at the 2023 SANS ICS Security Summit, incident response reporting is one of the monumental shifts seen globally in ICS-related regulations. It’s practically a universal requirement—if you own or operate some piece of critical infrastructure, regulation is coming (if it has not already).

While the electric sector in North America has been working with CIP-008 requirements for years now, the North American Electric Reliability Corporation (NERC) recently expanded them to include new timelines and federal agencies. Meanwhile, across Europe asset owners and operators must figure out how to comply with the soon-to-be in effect National Information Security (NIS2) Directive. And with special requirements for publicly traded companies, it’s no wonder practitioners are scratching their heads about when they need to comply with which requirements.

To make matters worse, each regulatory framework comes with its own penalties. These range from a percentage of the organization’s annual revenue to criminal charges (another aspect I explored at the ICS Security Summit). The recent proposed rulemaking from the Cybersecurity and Infrastructure Security Agency (CISA) suggests subpoenas, civil action, and/or contempt of court to enforce subpoenas, acquisition of penalties, and suspension or disbarment may be on the table for noncompliance with the proposed Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) reporting requirements—all of which is sure to raise eyebrows across legal departments nationwide.

It's no wonder, then, why organizations are integrating the technical response to incidents with their legal obligations. The table below provides a limited summary of various regulatory actions and penalties:

Reporting: Who, What, When, Where, Why, and How?

As seen in the table above, timelines vary—but so do the actual required details of the incident. In some cases, there may not be significant details to report on depending on how your organization interprets the regulatory requirements.

Interpretation, after all, is one of the key elements to any legal requirement. “Compliance,” as they say, “is in the eye of the beholder.” In this case, that can directly mean an auditor. In others it could be your internal legal counsel.

Take, for example, the recent Security Exchange Commission (SEC) cybersecurity incident response reporting requirements. In it, the SEC describes a material incident as a matter “to which there is a substantial likelihood that a reasonable investor would attach importance” in an investment decision. Legal analysts can spend days debating “reasonable investor,” “importance,” and even “substantial likelihood” in almost any standing. It’s therefore no wonder there is little universal consensus on what should be reported to the SEC.

And that does not even include the complexities of identifying “material” for ICSs, where technical practitioners discuss incidents in terms of impacts to reliability and safety—not financial impacts.

Examples like this are not just reserved for financially linked regulations like the SEC’s. Take the NERC’s Critical Infrastructure Protection (CIP) requirements:

CIP-008-6

• R4.1 Initial notifications and updates shall include the following attributes, at a minimum, to the extent known:
  • 4.1.1 The functional impact;
  • 4.1.2 The attack vector used; and
  • 4.1.3 The level of intrusion that was achieved or attempted.

• R4.2 After the Responsible Entity’s determination [of an incident or an attempt to compromise], provide initial notification within the following timelines:
  • One hour after the determination of a Reportable Cyber Security Incident.
  • By the end of the next calendar day after determination that a Cyber Security Incident was an attempt to compromise a system.

Crystal clear, right? Except, again, both lawyers and auditors can argue in circles over what an “attempt to compromise is” (how would you know?) or “the attack vector used” (what data is required to determine that?).

Even in the cases where your organization has clearly defined when to provide notifications and documented their regulatory requirements (with legal and technical analysis), confusion can persist on the “who, what, when, where, why, and how?” of incident response reporting. While we understand the technical aspects of declaring and responding to an incident fall on the incident commander, who “declares” it publicly? And once it’s declared, how does the information get to the right agency?

Believe it or not, this is also a complicated topic.

For example, in the SEC requirements, entities are required to report via Inline eXtensible Business Reporting Language (XBRL) tagging to include cybersecurity disclosures in traditional SEC financial reports. If the financial officers, compliance department, and security executives have not worked on alignment for using XBRL or aligning tools and processes for security disclosures for financial reports, there could be unnecessary friction during the actual incident response and recovery.

Similarly, electric utilities in North America need to alert both NERC and DHS. Who reports what (and how) is something that needs to be codified in the incident response plan before an incident occurs.

Alignment of Technical and Legal Best Practices

Luckily, your organization can avoid a lot of this confusion—and avoid making a bad day even worse during an actual incident—by following a few simple steps:

1. Build an ICS-Specific IR Plan

As highlighted in the SANS Five ICS Cybersecurity Critical Controls, it is critical that industrial organizations have a specific, scenario-based incident response plan for control systems and operational technology (OT). Practitioners should ensure that the program follows each stage of the incident response lifecycle, as shown below:

Scenarios should examine loss/denial of safety, view, and control of the industrial process specific to each site as the steps to respond and recovery will vary based on the specifics of the facilities. This will, in later steps, help with conversations around “material” or “criticality,” where relevant.

2. Review Current Capabilities vs. Regulatory Requirements

With a comprehensive ICS-specific plan in place, it’s important to have an honest review of what current capabilities your organization has—then compare them to the regulatory requirements. This is traditionally called a regulatory gap analysis and demonstrates “where we are” vs. “where we need to be.”

The key to this step is to be brutally honest and to lead a multidisciplinary team in the review or even hire consultants to perform the evaluation. This can help unlock budget for improving incident response capabilities by highlighting what is lacking compared to the mandatory regulation. Remember, some of the penalties for noncompliance can now involve criminal action, which hopefully underscores how important this effort is.

With a gap analysis in-hand, practitioners can then set on improving the people, processes, and technologies used in incident response.

3. Test, Test, Test!

One of the most difficult aspects of incident response is keeping the responders fresh, especially when IR is not their day job. This is especially true for the lawyers and corporate communication specialists that will now be part of your integrated ICS-specific incident response team.

To combat this, SANS recommends regular testing (via tabletop or operational exercises) specific to the regulatory requirements. This could mean a technical incident response exercise for your security team with simultaneous leadership or legal “drills” for the nontechnical regulatory team. We teach a similar concept in ICS456 as seen below:

The value in performing these tests, then reviewing everything as a team afterwards, is two-fold: 1) gaps are identified and improved; and 2) you get to practice like it’s game day—making it real means your team will be sharp during an actual incident.

Still Need Help?

SANS offers a myriad of courses to help unpack ICS-specific incident response and regulatory requirements. Improving your team’s capabilities is a primary way to help your organization improve its cybersecurity program. Courses that can help with this topic include:

• ICS515: ICS Visibility, Detection, and Response helps you gain visibility and asset identification in your ICS/ OT networks, monitor for and detect cyber threats, deconstruct ICS cyber-attacks to extract lessons learned, perform incident response, and take an intelligence-driven approach to executing a world-leading ICS cybersecurity program to ensure safe and reliable operations.
• ICS418: ICS Security Essentials for Managers enables leaders responsible for securing critical infrastructure and OT environments. The course addresses the need for dedicated ICS security programs, the teams that run them, and the skills required to map industrial cyber risk to business objectives to prioritize safety. ICS418l helps you manage the people, processes, and technologies necessary to create and sustain lasting ICS cyber risk programs while promoting a culture of safety, reliability, and security.
• ICS456: Essentials for NERC Critical Infrastructure Protection empowers students with knowledge of the what and the how of version 5, 6, and 7 standards. The course addresses the role of the Federal Energy Regulatory Commission (FERC), NERC, and Regional Entities, provides multiple approaches for identifying and categorizing Bulk Electric System (BES) cyber systems, and helps asset owners determine the requirements applicable to specific implementations.

I’ll speak more about regulatory requirements at this year’s SANS ICS Security Summit, where I will explore some of the critical issues asset owners and operators need to address between the next 6 months… and 10 years! Stay tuned for more!