What SolarWinds Means for DevSecOps – Dark Reading

4 minutes, 18 seconds Read

By Tom Tovar, CEO, Appdome

The Securities and Exchange Commission’s (SEC) SolarWinds indictments are having major implications for every aspect of cybersecurity, including mobile app security. Less discussed are what the indictment and the SEC’s new four-day rule mean for DevSecOps.

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 (CISO), Tim Brown, charging “fraud and internal control failures” for “known cybersecurity risks and vulnerabilities.” In the complaint, the SEC charged that SolarWinds and its CISO made “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.

What This Means for Mobile DevSecOps

The SEC said “SolarWinds’ poor controls [and] false and misleading statements… would have violated the federal securities laws even if SolarWinds had not experienced a major, targeted cybersecurity attack” (my emphasis added).

The fact that SolarWinds touted its DevSecOps practices is a critical part of the SEC’s complaint. SolarWinds publicly said it followed “standard security practices including vulnerability testing, regression testing, penetration testing and product security assessments.” The SEC did not challenge this statement or claim that Solar Winds and its CISO failed to perform traditional DevSecOps testing. It didn’t say that the SolarWinds DevSecOps process was bad at all.

The DevSecOps process at SolarWinds worked the same way it works everywhere: It highlights cyber deficiencies that need to be addressed. But, because of that process, the company and its CISO knew about the cyber deficiencies. The deficiencies were recorded and documented over various emails, reports, text messages, etc., many of which were referenced in the complaint. Once they knew, according to the SEC, the real problem emerged when they ignored (or, per the SEC, hid) those deficiencies and did nothing to solve, remediate or disclose them.

The SEC Four-Day Rule’s Impact on DevSecOps

In June 2023, the SEC issued a new four-day cybersecurity incident disclosure rule. This rule requires disclosure of cybersecurity incidents that have a “material impact” or are “reasonably likely” to have a material impact to the brand or business. The SEC doesn’t say what the word “incident” means.

It’s clear that the word “incident” means an actual cyberattack. The more interesting question is could ONE negative vulnerability assessment or penetration test be an “incident”? How about several findings from multiple penetration tests given to the same company over time? If you believe the SEC’s statements, SolarWinds’ “poor controls” and “misstatements and omissions” would have violated security laws even without an attack, so a poor record of compliance or avoidance can be an incident under the four-day rule.

Think about this: If you have only four days to evaluate, remediate, and/or disclose a cybersecurity incident could you, do it? Most can’t.

Relying on DevSecOps Risk Acceptance Waivers

If you’re a cyber professional, you may ask: Do internal risk acceptance waivers help?

It’s a regular practice for engineering and product teams to seek waivers of security, anti-fraud, and compliance objectives. These waivers are typically well documented and include mitigating actions or considerations designed to show that business is acting in good faith.

At the same time, risk acceptance waivers form a paper trail that could come back to bite you if they contain the wrong conclusions, or if issues remain unaddressed for too long. The SEC used the waivers against SolarWinds as evidence of what they described as “culture that did not take cybersecurity issues with sufficient seriousness.” The complaint pointed out that a “September 2020 Risk Acceptance Form flagged for Brown and others highlighted ‘the risk of legacy issues in the Orion Platform’ and warned the ‘volume of security issues being identified over the last month have outstripped the capacity of Engineering teams to resolve.’” (Their emphasis, not mine.)

If you look at the number and content of the cyber waivers or risk acceptance forms in your business and see a problem, solve it fast.

Summing It Up

“Shift left” and modern DevSecOps tools clearly provide tons of benefits. However, shift-left and DevSecOps tools, with their increasing emphasis on findings, assessments and testing, didn’t account for the new four-day rule, resource constraints in the engineering team, or the need for instant remediation. They likewise don’t account for the increased scrutiny that investors, customers, and users place on good cybersecurity. The traditional DevSecOps paper trails may not paint the best picture when viewed in hindsight. Worse, these processes may highlight large gaps between public cyber pledges and the cyber reality at your company.

About the Author

Tom Tovar is the co-creator of Appdome, the only fully automated unified mobile app defense platform. Today, he’s a coder, hacker and business leader. He started his career as a Stanford-educated, tech-focused, corporate and securities lawyer. He brings practical advice to serving as a board member and in C-level leadership roles at several cyber and technology companies. 

This post was originally published on the 3rd party site mentioned in the title of this this site

Similar Posts