SolarWinds Supply-Chain Attack Besets Boards with Implications

In 2020, we saw a rapid increase in cyberattacks while the COVID-19 pandemic ravaged the globe. A report by Crowdstrike in September, for example, noted that it had seen more attacks in the first half of 2020 than in all of 2019. Cyber criminals seized the crisis as an opportunity to further monetize attacks by proliferating ransomware and leveraging more commonplace fraud techniques at record levels. Amid this turmoil, a widespread and persistent attack that would further disrupt our confidence in the software supply chain and shatter our trust in enterprise software quietly lingered.

The attack on SolarWinds, disclosed in the company’s December regulatory filings, and subsequent victims including FireEye, Microsoft Corp., and numerous US federal agencies, tears at the fabric of standard risk management and security practices. This is a stark reminder that no amount of risk ranking, vendor profiling, or controls will thwart a persistent, capable adversary, or compensate for systemic vulnerabilities in an organization’s approach to managing a software supply chain and its supporting technologies.

Although the attack used a few new and refined mechanisms to compromise SolarWinds and other organizations (such as low-level compromises of the software development process and the subversion of cloud identity management technology), it was the attackers’ skilled penetration and prolonged period of remaining undetected that was the most astonishing. In fact, had they not attacked FireEye (with a world-class incident response practice in its Mandiant Solutions branch), they may have gone undetected for even longer. The attackers’ approach to target a small set of specific victims using SolarWinds’ supply-chain entry point even though they had potential access to more organizations is also remarkable.

Ultimately, the SolarWinds attack requires a shift in the way companies assess cyber risk in their supply chains as well as the way they view other associated risks. This refactoring will require time for new approaches to develop and mature, but three takeaways from the attack are clear today.

First, an organization cannot simply rely on a combination of questionnaires and outside information about the vulnerabilities and practices of critical suppliers to assess the likelihood of a breach of their systems, which may then harm other organizations. While this approach may have historically served the need to rapidly risk-rank suppliers and limit extending trust to low-performing organizations, it does not adequately address those suppliers that score well in these processes and that are then placed into positions of trust with high-risk access to data and networks.

Second, security and technology leaders will need to focus more on the essential (“key”) suppliers, which are unique to each organization. The level of trusted access that suppliers have enjoyed, even for those critical to business processes, will need to shift, and “essential supplier” blessings (which sidestep risk and security processes) will become a thing of the past. This increased scrutiny of key supplier risks requires that businesses reduce their number of software suppliers. There should be no more “preference buying” across business and technology teams who have largely similar needs but use different and duplicative software simply because of siloed operations and personal preferences. Chief information officers (CIOs) should consolidate software suppliers, and chief information security officers (CISOs) can reduce risk by exercising intense scrutiny over whether remaining suppliers should continue to have critical, trusted access.

Finally, businesses must consider leveraging cloud infrastructure to replicate capabilities that may have historically been delivered through installed, difficult-to-customize, and potentially insecure software. Use of cloud allows organizations to leverage the high level of assurance that cloud providers have built into their infrastructure, further consolidate technology vendors, and use new security design approaches such as zero trust—a relatively new concept in secure computing that focuses on regularly validating the identity and integrity of users and equipment before establishing trusted relationships. If executed correctly, the result is a more resilient enterprise built on cloud-provided infrastructure that has been constructed with a security-by-design approach instead of the inherited flaws of legacy technology environments.

Directors have additional factors to consider when engaging management on the implications of the SolarWinds attack and on software supply-chain risk. Some questions to frame the discussion include the following:

• Does the organization have a process to risk-rank vendors based on their level of access to critical data and ability to disrupt the business?
• Has the organization adequately identified whether it could be targeted with the goal of compromising other companies, and has it integrated this scenario into its cyber-risk management planning?
• Do we need all of our suppliers? Who within the organization is accountable for the proliferation of software suppliers? (As the number of suppliers grows, supply-chain complexity and exceptions to security controls—not to mention risk— also increase.)
• If the use of a software supplier requires the company to grant a security policy exception, who makes decisions around exceptions and how are they tracked? (A well-publicized page from a SolarWinds configuration manual suggested that customers exclude the product from basic malware protections for proper functioning. This requirement is not unique to SolarWinds and has been commonplace among software providers since firewalls and antivirus software were created. There are countless examples of CIOs calling CISOs to say, “We have this product going live tomorrow and the firewall is breaking it. We need an exception to our security policy, or we will miss our deadlines.” If these conversations are happening at your organization, the board and management should consider that institutional processes likely require some review.)
• Who in the organization is responsible for tracking new developments about the SolarWinds attack? Are they regularly analyzing the company for related compromises and vulnerabilities as new information is made available? (We do not yet know the full extent of the SolarWinds attack—including a complete list of its victims, the techniques used, or all the suppliers compromised. A new compromised supplier was publicly identified as recently as two weeks ago, almost a month after the original attack came to light. It’s likely we will be learning about the depth of this attack for some time yet.)

There is, however, some better news. While the implications are still not fully known, it is believed that the SolarWinds attack was designed as an intelligence-gathering operation. As noted, the attackers appear to have had the ability to compromise thousands of organizations, but instead chose their victims carefully, and have not weaponized the attack in a destructive way thus far. While it is easy to contemplate a more sinister outcome, boards should instead focus on building resilience into their companies’ software supply chains and understanding their potential exposures.

Derek Vadala (@derekvadala) is cofounder and CEO at VisibleRisk, a joint venture between Moody’s Corp., a global integrated risk assessment firm, and Team8, a cybersecurity-focused company creation platform. Vadala leads a team that is focused on creating a standard benchmark for communicating cyber risk to boards and senior business executives in order to improve the global dialogue about this important issue.