Follow-Up: SolarWinds Response to SEC Lawsuit

SolarWinds has responded on their blog regarding the SEC’s lawsuit against them following their breach. Here is some analysis:

I wrote about lessons drawn from the SEC’s complaint a few days ago, and this essay discusses SolarWind’s response.

1. The blog post makes no mention of SDL, which is an entire section of the complaint, particularly the whole section named: SolarWinds and Brown Falsely Claimed That the Company Followed a Secure Development Lifecycle When Creating Software for Customers

2.The post takes the time to mention that the SEC doesn’t know anything new about the attack. I don’t understand why this is mentioned, but their point is that the attack was sophisticated and that the SEC is blaming the victim. I can’t connect this with any reason the SEC would have new information to bring to the table regarding the threat actor.

3. They fight the characterization that their VPN configuration was a vulnerability. I also tried to avoid this in my previous write-up (and have edited it further for clarity). The word vulnerability is a bit loaded and usually excludes systems behaving as predicted. It’s more appropriate to describe their configuration as having risks. Example:

• If I leave doors unlocked intentionally, it’s a risk.
• If my locked door can be picked, it’s a vulnerability.

For instance, if a configuration unknowingly introduces an exploitable scenario, it’s a vulnerability. If configured intentionally, it’s more likely an accepted risk (whether they formally accepted it or not).

In this case, SolarWinds knew how their VPN operated. There was a risk that VPN credentials could be stolen and a threat actor could have exploited them to access their systems remotely, but the complaint doesn’t describe a traditional vulnerability.

My opinions on the “vulnerability” and “risk” language around this are debatable and pedantic. Still, SolarWinds took the time to take a side on this, trying to downplay the use of “vulnerability” likely to avoid being characterized as not having fixed a known vulnerability.

4. They attack the SEC’s claim that some internal vulnerabilities and “red flag” events should have been disclosed. For instance, their VPN risk, adherence to NIST, lack of SDL, etc.

Here, they cite receipts from the SEC itself. Page 11 and Page 134. These are pretty convincing regarding the “Red Flag” risks and events. Still, the complaint is pretty specific about not mentioning victimization in their 8-K, so I think that remains debated.

Lastly, The remainder of the blog post is a plea for understanding. I generally agree with it, though I advocate for (somehow) improving disclosure overall. In this case, personal liability for a CISO is a bit much.

However, The SEC complaint signals that companies must take the CISO role seriously. The role has long been a made-up title buried deep under the C-Suite without a standard definition, which signals the need for change.