If you’ve worked in IT or cybersecurity for a few years, you’ll undoubtedly remember the hoopla regarding SolarWinds. As a refresher, SolarWinds, one of the most widely used configuration management platforms in the industry, was hit with a supply chain attack, later to become known as STARBURST. Threat actors were able to get through various defenses in SolarWinds’ security and put in a sort of backdoor in the software, which was then rolled out to many of its clients. Many of those clients were then breached using that software. The full scope of the incident may never be known, as not all parties had the appropriate monitoring in place to detect the breach, nor would many of those clients necessarily want to disclose such a breach. But, suffice it to say it is perhaps the largest supply chain attack to date and potentially the harbinger of bad things to come in terms of development security trends.
So, it may not be surprising if I described the attack as a sort of line in the sand, where security pros talk about “before SolarWinds and after SolarWinds”. But, what might surprise you is why it would be described in that manner. While many of us in the industry may have thought the SolarWinds attack was part of history, it’s come back to the forefront of discussions for a different reason: not the ushering in of new supply chain attacks, but legal liability for companies and their leaders.
On October 30, 2023, the SEC filed a complaint against SolarWinds and its CISO, Tim Brown. The complaint alleges that the defendants “defrauded SolarWinds’ investors and customers through misstatements, omissions, and schemed that concealed both the Company’s poor cybersecurity practices and its heightened – and increasing – cybersecurity risks.” Those allegations seems pretty harsh. But, I’ve read the full complaint and have to say… prosecutors chose their case pretty well. The evidence is damning and I would be surprised if the defendants get off unscathed.
The full complaint is lengthy and I’ve just read through it. So, I haven’t had a chance to gather all of my thoughts on the matter yet. But, there are a few takeaways I think are worth noting, even at this early stage.
CISO Liability
Director and officer liability is not new in the US. But, it’s not often we see security pros brought into court. With this case, that may be changing. The complaint offers several examples where Tim Brown was quoted in interviews stating how important cybersecurity was to the industry generally and SolarWinds’ clients specifically. Additionally, the complaint brings up a “Security Statement” on the company’s website (on its “Trust Portal” no less), which was “owned” by the CISO. In these statements, Mr. Brown clearly outlines the need to follow industry standards and emphasizes SolarWinds’ adherence to the standards. However, internal documents show a very different story. The complaint alleges that internal program assessments showed a near complete lack of adherence to NIST 800-53 Moderate and statements of internal staff (including Mr. Brown) that acknowledge the company did not follow best practices in areas such as access management, secure software development, and vulnerability management. Moreover, the complaint even offers evidence of Mr. Brown admitting to his peer that he lied to a client about his knowledge of prior security incidents.
This blatant disconnect between what was said publicly and what was discussed internally may provide a very clear case of fraud. But, I urge you to evaluate your own workplace. In my experience personally and as a consultant, it is not uncommon to have two different versions of the security message. This case highlights that, while two versions of the truth may be acceptable, there comes a point where the divergence of those truths becomes too great, leading to liability for those in charge of the program and its messaging. I encourage you to evaluate your own public statements about your programs in light of your internal truth. Do they paint completely different pictures? Would those differences be deemed material to investors and customers? They might not be material on an average Wednesday… but what if you suffered a cybersecurity breach. Would they seem material then?
Policies vs Contracts
As a lawyer in cybersecurity, I often tell my clients that their policies are a lot like contracts and, in fact, can be used as such in many ways. In the case of SolarWinds, the SEC is using their policies against them. Specifically, SolarWinds had a policy to manage accounts in a manner of least privilege. But, it’s clear they didn’t do that. They had a password policy that said they wouldn’t share accounts, but they did. It said they’d require strong passwords, but they allowed very weak passwords (allowing a default password of “password”). In short, they had a policy that REQUIRED certain behavior, but they didn’t enforce it. Further, the SEC is stating that the policy was part of their broader security program, which was communicated to customers and investors via its “Security Statement”.
Does this mean that any time you don’t follow your policy you are committing a breach of contract? Probably not. But, here’s the thing… why risk it? I learned long ago that, whenever feasible, we should draft policies in a manner that encourages certain behaviors, but doesn’t require it in all instances. That’s because we can’t always guarantee that we will follow a policy at all times. I’d argue that SolarWinds and Tim Brown would be in a better position, at least in terms of its the lack of adherence to their policies, if they had drafted their policies with “we strive to…” instead of “we are required to…”
I recommend that you take a look at your policies and see if you have perhaps overcommitted you and your organization to certain practices. Think about what is feasible for your tools, your culture, and your team. Don’t be afraid to give yourself some leeway in your policies. Encourage the right behavior, but acknowledge your limits.
Reporting
New SEC rules require certain aspects of a security program and associated risks be disclosed. But, even before these new rules, organizations needed to disclose material risks. Also, since the ENRON debacle, organizations have been required to sufficiently inform the board of directors of any material risks. This is why CISOs typically provide at least annual risk reports to the board of directors. In the SolarWinds case, the SEC is claiming that the CISO did not do a good enough job in informing the board of the risks of which he was aware. Interestingly enough, they are not claiming the CIO (who also knew about the issues) is liable. Instead, it’s just the CISO (congrats on that fancy title, Tim Brown).
In my experience, CISOs often do a pretty good job of informing executive teams of the relevant risks. But, I’ve seen (too often than I’d like to admit) cases where CISOs have had their arms twisted into changing the messaging, softening the story when it comes to board reporting. Maybe at first, the CISO is fine with it because they have a plan to get the company up to speed. So, the CISOs don’t necessarily lie about the state of security, but they soften the blow and minimize the alarm bells. If they do this enough, they back themselves into a corner where they can’t later admit that their program is not where it needs to be without looking like they’ve lied all along.
This is a story where the CISO knew there was a problem and clearly communicated some dire warnings to the executive team (the SEC identifies many instances of this in their complaint). But, that message appears to have fallen on deaf ears at the executive level and then not been sent to the board. Coupled with other public statements praising its security program, the CISO just didn’t fight hard enough to sound the alarm.
Let this be a warning to other CISOs. Do your due diligence. Be clear in relaying risks and where the organization is on its security journey. Be collegial and collaborative, but also a squeaky wheel. If you don’t have a clear line of reporting to the board, you should probably get one… and use it.