Source: Vladimir Zuev via Alamy Stock Photo

COMMENTARY

In an earlier article, I covered what the Securities and Exchange Commission's (SEC) SolarWinds' indictments and four-day rule mean for DevSecOps. Today, let's ask a different question: Where do cyber disclosures go from here?

Before I joined the cybersecurity industry, I was a securities lawyer. I spent a lot of time navigating the SEC rules and worked with the SEC on a regular basis. This article isn't legal advice. It's practical advice from someone with real, albeit distant, familiarity with the SEC.

The SEC Indictment in a Nutshell

On Oct. 30, 2023, the SEC filed a complaint against SolarWinds and its chief information security officer, charging "fraud and internal control failures" and "misstatements, omissions, and schemes that concealed both the Company's poor cybersecurity practices and its heightened —  and increasing — cybersecurity risks," including the impact of an actual attack on its systems and customers. 

Putting the "Should" Question Aside 

I want to put aside whether the SEC should have taken action. There are a lot of voices on this topic already. Some argue that SolarWinds’ public cybersecurity statements were aspirational, not factual. Others take the position that the CISO shouldn’t be targeted because his department could not deliver the required defenses. He relied on others to do so. Finally, the amicus briefs filed in support of SolarWinds and its CISO argued that the case will have a chilling effect on hiring and retention of CISO roles, internal communication, efforts at improving cybersecurity, and more. 

The Cyber-Disclosure Problem 

The SEC began its complaint by pointing out that the company filed its IPO registration statement in October 2018. That document had a boilerplate and hypothetical cybersecurity risk-factor disclosure. The same month, the SEC's complaint reads, "Brown wrote in an internal presentation that SolarWinds' 'current state of security leaves us in a very vulnerable state for our critical assets.'"

This discrepancy is a big one, and the SEC said it only got worse. Even though SolarWinds employees and executives knew about the increasing risks, vulnerabilities, and attacks against SolarWinds' products over time, "SolarWinds' cybersecurity risk disclosures did not disclose them in any way." To illustrate its point, the SEC listed all the public SEC filings following the IPO that included the same, unchanged, hypothetical, boilerplate cybersecurity risk disclosure. 

To paraphrase the SEC's complaint: "Even if some of the individual risks and incidents discussed in this Complaint did not rise to the level of requiring disclosure on their own … collectively they created such an increased risk …" that SolarWinds' disclosures became "materially misleading." Worse still, according to the SEC, SolarWinds repeated the generic boilerplate disclosures even as an accumulating number of red flags piled up. 

One of the first things you learn as a securities lawyer is that disclosures, risk factors, and changes to risk factors in a company's SEC filings are vastly important. They're used by investors and securities analysts in evaluating and recommending stock purchases and sales. I was surprised to read in one of the amicus briefs that "CISOs are not typically responsible for drafting or approving" public disclosures. Maybe they should be. 

Proposing a Remediation Safe Harbor 

I want to propose something different: a remediation safe harbor for cybersecurity risks and incidents. The SEC wasn't blind to the question of remediation. In this regard, it said:

"SolarWinds also failed to remediate the issues described above ahead of its IPO in October 2018, and for many of them, for months or years afterwards. Thus, threat actors were able to later exploit the still unremediated VPN vulnerability to access SolarWinds' internal systems in January 2019, avoid detection for nearly two years, and ultimately insert malicious code resulting in the SUNBURST cyberattack."

In my proposal, if any company remediates the deficiencies or attack within the four-day time frame, it should be able to (a) avoid a fraud claim (i.e., nothing to talk about) or (b) use the standard 10Q and 10K process, including the Management Discussion and Analysis section, to disclose the incident. This may not have helped SolarWinds. When it disclosed the situation, its 8K said that the company's software "contained malicious code that had been inserted by threat actors" without any reference to remediation. Still, for countless other public companies facing the never-ending battle between attacker and defender, a remediation safe harbor would allow them the full four-day time frame to evaluate and respond to the incident. Then, if remediated, take the time to disclose the incident properly. The other benefit of this "remediate first" approach is that there will be more emphasis on cyber response and less impact to a company’s public stock. 8Ks could still be used for unresolved cybersecurity incidents. 

Conclusion

No matter where you come out on the question of whether the SEC should have acted or not, the question of how, when, and where we disclose cybersecurity incidents is going to be a big one for all cyber professionals. For my part, I think the CISO should control or, at the very least, approve the company's disclosures when cybersecurity incidents arise. More than that, the CISO should look for platforms that provide a single pane of glass to "see it and solve it" fast, with the least dependencies as possible. If we can encourage the SEC to embrace a remediate-first mindset, we just might open the door to better cybersecurity disclosure for everyone.