The SEC’s SolarWinds investigation in Context: Lessons from 100 Enterprise Security Assessments Governance & Compliance

Last month, the SEC filed a litigated complaint against SolarWinds and Tinothy Brown, its CISO with allegations that Solarwinds and Brown made materially misleading statements and omissions about the company’s cybersecurity practices and risks in public disclosures in the wake of their devasting breach that became international news in late December of 2020. The charges are serious, alleging not only possible fraud, recklessness, or negligence in addressing serious lapses in security, but also knowingly misleading investors through a series of public and private statements, including boiler-plate security statements on the company’s website, a version of which remains there to this day. SolarWinds has fired back at the SEC complaint and the company seems intent on mounting a forceful defense of their innocence.  

The SEC complaint is also notable for detailing various aspects of SolarWinds security controls and governance practices at the time of, and years preceding, the breach. Sygnia, as a specialized cyber security consulting firm, deals in two main service lines: Incident Response and Security Assessments. Our clients are generally global large enterprises or semi-private providers of critical infrastructure or national services.  Some of the markets we operate in include legal, finance, primary industry, media & communications, and more. As such, we have a rare view into a broad swath of security practices and culture of organizations all over the world, and we thought it valuable to provide Sygnia’s insight into how SolarWinds’ practices compare to the broader behavior of our clients and what we see in the market. 

Meaningful Adherence to Security Frameworks 

To begin, the SEC complaint alleges that SolarWinds did not have processes in place to adequately adhere to the NIST Cybersecurity Framework, as the company had alleged in public statements and legal disclosures. Specifically in the SolarWinds context, the SEC cites two separate frameworks: The NIST Cybersecurity Framework (CSF), as well as NIST Special Publication 800-53 Rev 4. It is a little unclear from the complaint whether SolarWinds was auditing according to both frameworks, but it is likely they were, as both are often cited as required for working with government agencies. 

Our concern with adhering to NIST frameworks as a standard yardstick for ensuring security is that they work best when they are part of an ongoing dialogue, either with internal stakeholders, or external clients – certainly not as an end in and of themselves. The reason for this is that NIST language is purposefully vague when describing controls, in order to ensure as wide applicability as possible. Take for example, one control selected from the NIST CSF “Prevent” pillar: 

PR.AA-02: Identities are proofed and bound to credentials based on the context of interactions 

This control requires organizations to ensure that all identities are real and require authorization prior to interacting with services. This is simply too broad to be of any actual proscriptive use in securing an organization’s identity management. Just about any organization can say they have a program in place to ensure identities are proofed and bound to credentials – but that’s just the beginning of the story. Sygnia, when assessing an organization’s Identity & Access Management, may require days just to assess this area alone. Our standard IAM assessment interview may run upwards of two to three hours, depending on the organization. Additional topics in such a conversation would necessarily involve questions such as: 

• Is MFA employed throughout the estate? For which assets and use cases? How complete is the roll-out? Is it enforced? 
• What is the management schema for admin accounts – are they unique per admin? Per asset? 
• Are admin accounts used in regular user contexts? Are regular user accounts used in administrative contexts? 
• Are credentials managed? Is there a PAM solution in place? 
• What is the password policy? Are programmatic passwords rotated regularly? 

In addition to the information gathering, there may be additional hours of hands-on assessment of various platforms and identity providers, and resulting in dozens of technical recommendations that could take months, if not years, to implement. 

Each one of those organizations could still likely report that NIST CSF control PR.AA-02, as listed above, is a fully or partially managed control, while obviously still having a ton of daylight into just exactly what it entails, and without giving a meaningful indication as to how secure the organization is. Additionally, it makes it easy for organizations to cite NIST, if not that they are auditing according to it, that they are referencing or otherwise leveraging the frameworks in their cyber security programs – precisely because it sounds good, but means little.  

Proof of Compliance

Which brings us to our next point: Our enterprise customers generally have some level of risk management program for their vendors, in varying degrees of complexity depending on the organization and the extent to which it relies on external vendors. For most, that third party risk management will require some sort of yearly assertion that might involve any or more of the following: 

• Proof of ISO Certification 
• Proof of audit according to a certain framework (such as NIST SP 800-53) 
• Proof of having performed an external assessment or penetration test 
• Results pertaining to any of the above 
• The right for the customer to insist an audit be performed 

All of the above would have to be contractually agreed upon, but the least stringent requirements are not uncommon, and organizations with larger programs have job functions and software systems for managing these requirements and ensuring that high-risk vendors demonstrate compliance at least once a year.  

If SolarWinds was contractually required by a number of their customers to employ the NIST SP 800-53 framework, and the results of those same audits were as bad as the SEC complaint details, why, in all its years of operating, to 499 of the Fortune 500 and 17,000+ other clients, did no other customer raise the alarm on SolarWinds’ level of security implementation? Or more succinctly: if compliance is done, but no one cares about the result, what is its usefulness? This is why, as mentioned above, NIST adherence works best when part of a dialogue, and customers should not simply ask whether or not a NIST assessment was done, but insist on seeing the results of such assessments, provide feedback on same, and hold their vendors’ feet to the fire.  

Our most effective clients rarely leverage NIST for compliance results at all, in general ISO 27001 tends to be more common, and more common still is proof of third-party assessment and/or PT results. 

Silos and the Limits of CISO Effectiveness 

Another frequent problem Sygnia encounters is how cybersecurity teams are integrated into the wider organization, the amount of corporate buy-in they have, and whether they can ensure security is incorporated into all aspects of the organization. This often becomes apparent, and is also cited in the SEC complaint with regards to SolarWinds, when ensuring that a good Secure Software Development Lifecycle (referred to as “SDL” in the complaint) is maintained . Even organizations that do not have a primary software product intended for external consumption will often have development or architecture teams, be it for building out new cloud infrastructure or custom integrations to enterprise productivity software.  

SDL is a maturing concept in cybersecurity, and most of our clients have some processes in place to ensure that the basics are being done, including: 

• Controls over what access and resources developers have available to them 
• Controls on who can push code into pipelines and production 
• Controls over where secrets are kept and how they are used 
• Peer review and static code analysis 
• Review process for who can build and deploy assets to cloud environments 

And while it is not uncommon that security teams be involved in this process, there are often gaps over their ability to provide appropriate oversight and assurance. Common complaints from security teams include developers being able to spin up infrastructure without visibility from security, having limited involvement in how code is pushed into production or in granting privileges, or being shut out of cloud development processes and only able to perform an assessment after infrastructure has gone into production.  

These problems can extend into other areas of the organization as well – large organizations may have dedicated teams for IAM, core services, databases, architecture, and without the proper organizational structures, security teams can find themselves working against the other IT teams, facing turf battles, and fighting to be included in processes. It becomes harder still when the organizational structure is such that security resides in a silo from the rest of IT and development, unable to extend or enforce their jurisdiction over security matters. 

In these instances, the problem is the governing processes that have been put in place to ensure security is baked into everything an organization does. And the responsibility for ensuring that happens is likely not with the CISO at all but resides higher up in the organizational chain – senior leadership and the board are responsible for ensuring the processes are in place that allows the CISO to be effective at doing his job. 

Proscriptive Guidelines 

In our experience, the most mature organizations do not spend any more time demonstrating adherence to NIST than is minimally necessary, while ensuring that the status of the security organization is both 1) frequently reported to the board, and 2) continually involved in conversations across the organization. Especially in large enterprises, cyber security needs to be seen as cross-organizational and baked into processes not only in IT and development, but also HR, and supported by sufficiently senior leadership as to ensure their involvement and effectiveness. 

Additionally, many organizations prioritize smaller projects designed to harden specific areas of the IT estate – be it cloud or virtualized infrastructure, on-prem servers, workstations, privileged access, helpdesk training, and so on. These sustained pushes in focused areas of the organization are what add up to a cyber-mature organization. 

Additionally, mature organizations may frequently leverage more concrete guidelines, such as the benchmarks described by the Center for Internet Security (CIS), which provides concrete hardening guidelines for critical IT assets, as well as hardened .ISO disk images for a long list of services that can be deployed in a virtualized, cloud, or physical environment. 

Beyond those hardening guidelines, the most serious organizations will also have annual or biennial security assessments with organizations like Sygnia, where they can receive concrete feedback on how well their IT security posture is actually implemented, how resilient it is to threats, how it has progressed since the last assessment, and what are the concrete project initiatives that should be taken in order to continually drive maturity further.  

But how well those initiatives can be implemented are a function of the CISO’s ability to drive change and oversee security functions across the organization – and in order for that to occur, the CISO must be empowered with proper authority from the board. Otherwise, risks can be raised and compliance audits can be passed without ever attaining any meaningful improvement to the organization’s enterprise cyber security.