Supply Chain Attacks: Why Risk Management and Business Continuity Planning are Essential

Codecov is just the newest in a series of attacks against the software supply chain. Supply chain attacks are an efficient means for advanced persistent attackers to breach hundreds or thousands of systems by modifying popular software code. In this article, we will discuss how the CISA Cyber Supply Chain Risk Management model provides a roadmap for organizations to protect themselves from software supply chain attacks. 

Software Supply Chain (SSC) Attacks Defined

The Software Supply Chain (SSC) consists of the pathways for delivering new software or firmware and their updates. Today’s delivery of software and firmware is usually done via the internet, requiring frequent or continuous communication between the installed components and the relevant update vendors. Any software vendor or open-source software download site is a target.  Additional targets include the communications channels between vendors and software customers.

Learn More: 6 Best Practices to Enhance Visibility Over the Supply Chain

SSC Attack Approaches

Figure 1, fromOpens a new window the U. S. Cybersecurity and Infrastructure Security Agency (CISA), shows common SSC attack vectors. 

Figure 1: Software Supply Chain Attack Vectors

The CISA describes three common techniques to achieve success along these vectors, including:

• Hijacking updates: Updates to existing software/firmware can contain malicious code. Organizations often enable automatic updates without any change management procedures to manage risk.

• Undermining codesigning: Codecov, describedOpens a new window by Charlie Osborne, is an example of how this might happen. Attackers leveraged weaknesses in Codecov’s Docker image creation process, allowing modifying the script used to upload software for testing.  HashiCorp was the first victim of the attack to report the exploit.  The Codecov attackers were able to compromise HashiCorp’s code signing key.
• Compromising open–source code:  In the 2020 State of the Software Supply Chain reportOpens a new window , Sonatype writes that open-source coding and sharing is based on the ethos of shared trust. Thousands of volunteers might contribute to or modify specific third-party code (TTC). In addition, each piece of open-source code might incorporate several to thousands of dependencies on other open-source modules. This is not easy to manage. 

• Unique Vulnerabilities: Software resides everywhere on a network: on servers, user devices, and IoT.  Because of this, any SSC attack can affect multiple systems and various classifications of data. One of the biggest challenges is the privileged access given many applications.  In some cases, privileged access is required. In others, administrators are asked if they want to allow privileged access, even if not needed. Admins often will enable this access without thinking. This enables elevated privileges via SSC attacks.

Applications often establish continued communication with their vendors for updates. However, attackers can also use these communication channels for command and control after using the SSC for infiltration.

SSC Risk Management

The National Institute of Standards and Technology (NIST), via the CISA, published risk management guidelinesOpens a new window for SSC. The following recommendations for organizational risk management  are based on these guidelines.

Step 1: Identify Key Mission or Business Processes: As with any risk management activity, the first step is to document all business-critical processes.  The documentation must also include the applications and firmware that support those processes.

Step 2: Maintain an Inventory of Software Licenses: It may seem that this is an obvious part of the previous step. However, organizations often have applications not part of critical business processes that can expose critical data and systems if compromised. Organizations must know about all applications, where they reside, and the potential attack surface.

Another aspect of licensing is understanding each vendor’s update processes and how often updates occur.  How quickly can a vendor respond if something happens in the SSC?

Step 3: Manage Vulnerabilities: Organizations must plan to respond if an SSC vulnerability or threat is discovered in an application required for one or more critical business processes. This should be part of change management. Change management includes planning for reversing any changes, including updates. 

This step requires that change management processes include any vendor updates.  Automatic updates are convenient, but organizations should consider the risk of auto-updates to applications on highly sensitive data segments. 

Learn More: How To Manage Insider Risk With Continuous Background Checks

SSC Business Continuity Planning

Managing the business continuity challenges associated with SSC attacks consists of three cyclical phases: prevention, mitigation, and resilience.

Prevention

Again, preventing SSC threats from entering an organization requires strong engagement with software and firmware vendors.  Vendors should comply with a customer’s software development security policies, including update and open-source component management.  Vendors must also show how they manage their SSC for any TPCs they use in their products.

The need for vendors to comply with customer policies increases in tandem with the risk associated with software. As I wrote earlier, software management risk increases with the criticality of associated business processes and the location of the software.

Vendors should also provide a component inventory to customers.  Organizations must understand what components are used to realize emerging vulnerabilities across those components.  This software “bill of materials” also applies to software developed by organizations in-house.

Mitigation

Regardless of how well prevention processes are implemented, organizations must assume an SSC threat will break through.  When this happens, organizations must be prepared by:

• Implementing a documented software vulnerability program
  – Use vendor instructions for configuring and hardening software and firmware
  – Register software with vendors to enable contact if an SSC attack is identified
  – Use threat intelligence and vulnerability notification resources for regular review of possible software component risk elevation

• Knowing and managing the URLs or IP addresses used for automatic updates; this allows configuration of firewalls and other network devices only to allow expected traffic
• Segmenting the network to limit the effects of an SSC attack
• Monitoring endpoints for anomalous behavior and deviations from recorded software inventory

Learn More: 10 Ways to Create a Responsibly-Sourced Supply Chain

Resilience

Resilience is the ability to continue safely providing goods and services if an SSC threat compromises critical business processes.  This starts with ensuring failover processes.

Organizations build back-out plans, or failover, into change management. Change management failover is designed to return to the original state if something goes wrong with an installation/update. Organizations should maintain known workable software and firmware images for implementation if a compromise occurs. Again, organizations must review the potential impact if automatic vendor updates affect crucial business processes or highly sensitive network segments. Organizations must have a quick way to restore business processes before passing maximum tolerable downtime. In some cases, it might be possible simply to replace infected software or firmware.  Organizations should identify these possibilities and document alternative suppliers.

Closing Thoughts

SSC attack opportunities continue to grow as vendors and organizations develop software using TPCs.  Understanding what is installed on the network and the potential risks to critical business processes must be included in any change management process. 

Customers must hold vendors accountable.  Accountability extends from vendor SSC management through how the vendor responds if an SSC attack impacts customers.  If a vendor chooses lack of transparency into how it manages TPCs and overall SDLC security, customers may have to find another vendor.

Finally, business continuity planning requires understanding the possible risk associated with automatic updates that bypass change management processes.  Organizations must be able quickly to recover from the installation of an infected update.  Recovery includes the ability to restore software or firmware to a previous, uninfected state.  

Do you think the CISA’s framework for supply chain risk management is sufficient to protect organizations from such attacks? Comment below or let us know on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!