Lessons from the SEC’s Lawsuit against SolarWinds and Tim Brown

A few days ago, the SEC filed a lawsuit against SolarWinds and their CISO that shares some similarities with the blameless post-mortem of the case against Joe Sullivan I wrote around this time last year.

I took the time to give the complaint a thorough read. As usual, I am only interested in lessons for security organizations and not interested in cheering for a side. Let’s get started!

A quick note: SolarWinds responded to the SEC complaint. I wrote about it here.

First — There was a historic attack named SUNBURST. It’s important context while considering why SolarWinds was sued for the particular issues in the case. That attack was very bad, and SEC action is rare. The SEC signals that the details of their case are illegal even in the absence of a breach.

These are the five major claims from the SEC claim against SolarWinds.

1. They promoted SolarWinds with (false) public statements about its security practices.
2. Similarly, they made false statements about their cybersecurity practices in SEC filings.
3. They also didn’t disclose “red flags” that led up to the SUNBURST attack.
4. They didn’t fully disclose the impact of the SUNBURST attack once it happened.
5. SolarWinds had multiple internal control failures.

Here are some summary themes that are important to discuss.

• Public and regulatory statements create a shadow compliance framework.
• This lawsuit draws a line: Passive 🔍 and Active 🛠 Security teams.
• SEC expectations might be unrealistic for security teams.
• The VPN issue is an evergreen security story

Each of these are discussed below!

Public and regulatory statements create a shadow compliance framework.

Compliance challenges come from more than just the acronym soup of compliance frameworks. You’re also regulated by the statements you make publicly.

The FTC famously takes regulatory action based on public statements about privacy and security, and the SEC is flexing their muscles in this case, too.

SolarWinds published a public “Security Statement” likely to deal with multiple GRC burdens they carry as a vendor and publicly traded company.

It’s important to note that their Security Statement is identical to many others. It opens up the possibility that it wasn’t adopted intentionally. There’s nothing wrong with using boilerplate language for GRC, but not if it’s a checkbox afterthought. Copy-pasting GRC language does not create the underlying processes it describes.

This statement still exists at SolarWinds so that you can see it yourself.

The core issue is that the statement was at odds with internal security practices that the SEC identified as problematic. These findings were supported by emails, chat messages, and documentation discovered by the SEC in their lawsuit.

1. We follow the NIST CSF framework: SEC found poor adherence to the NIST CSF framework.
2. We follow an SDL methodology: Was not implemented with their flagship product compromised in SUNBURST.
3. We have password policies: The password policies they mention were not followed in some processes unknown to us, the reader.
4. We have access controls: Employees were over-permissioned and did not follow reasonable access controls. This is demonstrated by how the attack succeeded rather than the lawsuit’s discovery.

These public statements create an area of unwritten compliance. This adds to whatever laws, frameworks, and contracts you’ve entered into and handle through GRC normally. This case elevates the promises from marketing and sales and moves them into a compliance burden. If you create a Security Statement to market yourselves to customers, you have also publicly made a statement to securities analysts.

Track and use these statements when asking to resource your security organization.

This lawsuit draws a line: Passive 🔍 and Active 🛠 Security teams.

Many parts of the complaint suggest a pattern I have witnessed elsewhere over my career. Some security teams want to focus on being breakers rather than builders. They enjoy GRC, finding vulnerabilities, handling incidents, consulting, and providing advice. They let others own the risk decisions and become accountable for following up on mitigations. They love a bloody audit, a nasty vuln, a successful red team, and talking about how bad the security is at their company. They are passive!

In other words, they avoid accountability for the issues they find. They haven’t developed and integrated SWE talent to take charge and operate forward within engineering organizations with issues. Their influence comes through tickets assigned to other teams.

This is not to say passive teams are irresponsible, apathetic, or don’t care about security.

Simply put, many teams optimize for this strategy. Hiring for it is straightforward. Passive security organizations are easier to build.

Security teams can become very effective at finding issues because it’s easier than fixing them. The law of the lever is exploited and creates an imbalance that’s hard to recover from. You can bury yourself in findings.

I can’t say this imbalance existed for certain at SolarWinds, but the complaint smells of these issues. There are snippets from the complaint to support my point.

First, a network engineer says they are finding more issues than they can fix. Second, they say that “engineering” capacity is outstripped. Third, they describe a lack of awareness throughout the company. Lastly, there are hints that resources are not provided to do the work.

This indicates that priorities are out of wack. Not out of bad faith but mainly because staffing prioritizes finding new problems to fix. Finding more problems won’t fix the old ones, and it’s not the fault of the folks tasked to find more. This becomes insurmountable over the long term.

The following comments also smell like an issue with missed expectations between security and engineering teams. This may be frustration that discovered issues need to be triaged and resolved effectively by other teams, and the perception that it would all be better if they just understood.

Lastly, resourcing issues have already surfaced above the CISO. It’s hard to say what form this took just from the complaint.

The SEC says that passive security teams no longer wash their hands of accountability.

Passive organizations I have been exposed to often have a “CYA” tone to justify their organizational decisions. I understand this — it feels dangerous to be accountable for security issues you cannot fix. But this just got called out.

The SEC complained about the security team’s knowledge of bad security. Not just the CISO. All of their security employees are labeled as collectively reckless or negligent.

Security teams must embrace SWE hiring, career paths, and forward embedding in product and engineering organizations. This has to happen, even if it means federating your security team. Get active. A fully passive organization no longer cuts it. This claim makes that clear since the SEC also points the finger at the folks who discovered the issues internally at SolarWinds. They expect action, which is where team strategy needs to head anyway.

SEC expectations might be unrealistic for security teams.

In this case, the disclosure conversation with the SEC goes a few different ways. The discussion about SolarWinds and their SEC disclosures is one thing, while the ramifications of everyone else’s disclosures are another.

First, the bar has been lowered on what the SEC expects in an 8-K. For instance, they expected SolarWinds to have disclosed that they were doing poorly against the NIST framework. Additionally, the SolarWinds VPN configuration that was risky and exploited to kick off this whole ordeal was expected to have been disclosed.

Second, the SEC has signaled that they’re not cool with generic and hypothetical risk scenarios to cover your disclosures of security risks. If you know about a specific large risk, it’s supposed to be disclosed. The issue is that a CISO should regularly know about quite a few risks that will exist while others are prioritized. Will all of those need to be disclosed, or are they confidential so they’re not exploited?

Lastly, SolarWinds made incident response disclosures in 8-K to the SEC that were outright wrong and not based on the full facts. This was an avoidable problem, and I’m unsure what SolarWinds expected. It’s worth scrutinizing how these statements are made and what your role and liability are in making them. You want them to be correct and accurate, but you don’t want to be personally liable if your legal organization wants to downplay information in those disclosures to the SEC. There is conflict here.

In all cases, the question is materiality in what you must disclose. The actual answers, unfortunately, are left to each company and its legal organization. My big issue, however, is that CISOs (should) design their organizations to uncover bad things discovered with a regular, daily velocity. However, there’s a widespread acceptance that software has risks, incidents, and things that need fixing regularly.

Now, I understand that the SolarWinds case is elevated because they had an enormous breach… but this statement in the claim is pretty aggressive from the SEC, which indicates that those omissions violated the law:

Assuming this is truly their standpoint, then CISOs and their legal counsel need to solve for at-scale disclosures of more mundane internal security risks to abide by the law. I’m not sure that filing an 8-k when poor results from a NIST audit is realistic, so I think this remains an open problem to figure out and could use more SEC guidance. Otherwise, the CISO role and Security have become very confusing, and all CISOs should probably have independent counsel in their employment contracts.

Why? The CISO enters a complicated situation if they want to disclose something to the SEC without having the authority to do so or if internal counsel disagrees. Otherwise, is their only recourse to whistleblow? Maybe that’s the case. But that is a symptom that expectations here are not clear.

A quick footnote for this section. In particular, the bad behavior of employees involved in the case is a different story. I’m not analyzing that much. It may be the case that we’re only talking about this because of how they behaved. Maybe they were singled out by the SEC for this alone.

This doesn’t matter because the complaint still guides what the SEC expects from security teams acting in good faith. If the defendants don’t settle, we’ll get to hear their story.

The SolarWinds VPN issue is an evergreen security story.

A major narrative in the SEC claim is a story I’ll summarize here. Every security career can empathize with it.

SolarWinds had a risky VPN configuration (The SEC calls it a vulnerability):

• Password-based credentials were used to access the VPN. I’m unsure if MFA was involved, but if it was, it was bypassed.
• The VPN didn’t perform any client/device verification.
• Lots of critical infrastructure was exposed over the VPN.

This configuration is extremely common. Small companies evolve and incrementally add security software like VPN. Then, they rely on it and expose a lot of infrastructure around it.

Soon, they approach a wide river they must cross to lock this down. The common next steps require multifactor, a unique device-issued certificate, or device verification with varying MDM, EDR, and operating system configurations.

They don’t get to this, likely because further constraints on VPN usage get pushback by developers. SolarWinds employees partially discuss mitigations, but they never happened.

The SUNBURST threat actor then exploited this VPN configuration.

What’s interesting about this story is a character named “Network Engineer D”. I’ll call them NED. This engineer escalated the risk of this configuration on numerous occasions.

The risks, if they are not obvious:

• A threat actor can use the VPN remotely to access critical infrastructure with just a simple credential.
• The threat actor can do so without the telemetry gleaned from EDR tooling.

After the breach, management mentioned that a fix for this configuration “never got any traction”. This outcome is also common. The “Fix” for this VPN configuration is not a patch or redeploy; it’s a systemic mitigation involving identity, device management, and enrollment process.

Companies get stuck in these areas of convenience where they can’t make the jump into more sophisticated defenses that require a large lift. The technology stack to support device verification and enrollments is an expensive, multi-stakeholder project and isn’t the sole decision of a security team. Security teams always want this; it’s a matter of herding cats. And whether the cats agree to it.

Not only do employees push back on any friction involved with their work, but they also push back at having a managed machine. Most security teams take this transition for granted. This transition is always a war story.

That doesn’t excuse the outcome, but my experience is that the security role in multi-stakeholder mitigation like this fluctuates from place to place. Going from a very simple VPN setup with highly accessible ACLs is not as simple as a “patch”. It requires technical resourcing with security objectives in multiple teams where your stakeholders live.

NED is a nice highlight in this whole case. Their escalation directly focused on the earliest part of the causal chain for this whole event, and they got their shoutout from the SEC. But escalation alone does not herd cats. Still, I’d like to buy NED dinner in case no one correctly acknowledges their role in pushing this issue to be fixed.

Conclusion

The SEC is signaling that they will be performing discovery of internal security processes at investor-held companies that have major breaches.

They will:

• Use legal discovery to match internal processes with public statements
• Verify that those processes are healthy

Those seem reasonable. However, they’ve complicated the role of Security and the CISO in risk disclosure. Disclosure of ongoing risk findings is now an open problem that I believe most, if not all, companies are in debatable compliance with based on the language in the complaint.

I don’t think more disclosure is a bad idea. Rather, I’m not sure that expectations around what should be disclosed will be clear, except in hindsight.

Ryan McGeehan writes about security on scrty.io