• Given the increasing frequency of supply chain attacks, the sophistication of those attacks, and the expansion of the attack surface beyond an organization’s direct control, incident preparedness and response activities must be considered in the overall supply chain risk mitigation strategy.
• Supply chain attacks have three prevailing risk categories – risks from SaaS applications, risks from third-party vendor access, and risks from the software supply chain. Scenarios can be created for each category to illustrate data and access flows along the supply chain and to understand an incident’s impact based on its point of origin.
• Organizations face limitations when evaluating aspects of supply chain risk, such as limited insight into vendor hiring practices, limited visibility beyond the immediate supply chain, and limited ability to audit code effectively. These limitations can impede effective supply chain risk management.
• A supply chain incident response methodology can be built on the foundation of well-documented incident response practices. While building out supply chain incident response capabilities, organizations should seek to broaden vendor communications, double down on asset management, and develop and employ thorough incident response testing and training programs.

Bioterrorism expert Leonard A. Cole once said, “You are not responsible for what friends do, but you will be judged by the company you keep.”

Other respected thinkers have offered similar guidance with varying terms, but all have a common theme: Personal and professional associations can have direct effects on reputation and longevity. Applying this wisdom to business security practices — specifically the selection of vendors and business partners that make up an organization’s supply chain — raises questions about balancing incident prevention and response efforts to defend against supply chain attacks.

To what extent is an organization responsible for the actions of its vendors and business partners, and what are the potential effects of those actions on the organization? Is vendor selection as a prevention strategy sufficient to protect the organization’s assets and reputation? Or must an organization prepare for the inevitable and develop supply chain incident response capabilities?

To answer these questions, it’s important to understand common supply chain risk scenarios, the challenges associated with supply chain risk management, and specific methods that can be employed to respond to an incident along the supply chain.

A supply chain compromise is “the manipulation of products, such as devices or software, or their delivery mechanisms before receipt by the end consumer,” according to MITRE. Put another way, a supply chain compromise is the result of an adversary inserting themselves into an organization’s “social circle” by compromising an entity or product along that organization’s critical business supply path.

The specific reasons for adversaries favoring attacks leveraging the supply chain vary, but resource savings and indirect access to high-value targets are certainly on the list. Why would an adversary spend weeks building out a cyber kill chain that includes custom malware and a complex social engineering campaign when they could compromise a softer target – a vendor or partner in the supply chain – and have direct, trusted access to the primary target in a much shorter time? They won’t. They will choose the path of least resistance.

For this reason, the concept of an organization’s attack surface has grown beyond its protected environment to include assets and entities that it does not own or control. Organizations must proactively limit supply chain risks through careful selection of the company they keep while preparing to respond to an incident that will invariably originate from the supply chain. Before discussing the specifics of supply chain incident response, it’s helpful to understand common supply chain risk scenarios and challenges associated with supply chain risk management.

Supply chain risk scenarios

Every security incident is unique, so attempts to group supply chain attacks by indicators of compromise (IOCs) or adversary tactics, techniques and procedures (TTPs) would be inefficient, if not inaccurate. It is possible, however, to summarize high-level supply chain risk scenarios based on the access and data-sharing relationship between an organization and its vendor or business partners. With this approach, supply chain risks can be categorized as originating from software-as-a-service (SaaS) applications, third-party vendor access and the software supply chain.

These scenarios are not mutually exclusive. An adversary’s kill chain could simultaneously include more than one or all three scenarios.

SaaS applications

SaaS applications refer to applications or services that are hosted by a third party in the cloud and range from basic cloud storage to productivity tools (e.g., Microsoft 365), social media and communications, data monitoring and management, business service applications and education.

With SaaS applications, the user access or data-sharing flow goes from the organization to the vendor. Users send or store their data in the SaaS provider’s cloud and access the SaaS application to interact with that data. The supply chain risk in this arrangement originates from the compromise of the vendor’s systems, which results in the exposure of sensitive data or the compromise of user credentials.

Third-party vendor access

Business associates, partners and third-party vendors are critical to the operation of countless organizations globally. It is nearly impossible for a single organization to effectively produce the products and services it needs to operate without outsourcing to a set of third-party specialists. In some cases, these third parties require access to the organization’s environment to render their services.

Whenever inbound access to an environment is created, risk is introduced. The user access or data-sharing flow in this example is from the third-party vendor to the organization – vendor employees access the organization’s internal environment to manage or monitor systems and data. Supply chain risk in this arrangement originates when a security incident experienced by the vendor flows down to the organization via the vendor’s trusted access, or when the vendor misuses or abuses the organization’s systems or data.

Software supply chain

An organization’s software supply chain is made up of the software and applications required for the organization to maintain its operations. Remember that the software supply chain doesn’t only include the organization’s immediate software vendors, but also all the software providers that make the components, libraries and tools used by those vendors. For this reason, identifying the threats posed by the participants in an organization’s software supply chain is usually more challenging than identifying those presented by the SaaS application and third-party vendor access scenarios.

In this example, the user access or data sharing flow is from the third-party vendor to the organization, where software developed by the third-party vendor becomes an integrated part of the organization’s environment. Supply chain risk in this arrangement originates when a compromised vendor application is installed by the organization, potentially passing the characteristics of the breach along to the organization.

Supply chain risk management challenges

Vendor and supply chain risk management has gained renewed interest recently, likely in response to the steady cadence of high-profile supply chain breaches that have occurred over the past three to five years. An internet search for articles discussing supply chain attacks published before 2017 returns 9.5 million results, with many of the most relevant matches directly or indirectly chronicling Target’s infamous 2013 data breach. A similar search for articles published after 2016 returns 39.7 million results that include more diverse attack examples, preparation methodologies, and references to regulatory standards. This increase in frequency and volume of content may speak to the concern organizations have about supply chain vulnerabilities, and the complexity associated with addressing those vulnerabilities. Consider that:

• Organizational data, including intellectual property and other sensitive data, is more distributed (i.e., processed, transmitted and stored by third parties) than ever before.
• Not only must an organization protect itself from its own supply chain, but it must also avoid becoming an unwilling participant in an incident along another organization’s supply chain.
• Regulators have been watching the news, and supply chain risk management requirements are appearing in an increasing number of regulatory standards.

A trove of well-written vendor and supply chain risk management program guidance can be accessed with a single internet search. Rather than rehashing the foundations of vendor risk management, it’s worth looking at some of complexities that feed into the supply chain risk management challenge. These aspects are based on recent security research and industry news and tie into the risk scenarios described in the previous section.

Who are your vendors hiring?

Personnel security has long been a vendor risk concern. Data owners want to be sure their data and systems aren’t being handled by individuals who have a history of mismanaging data, criminally or otherwise. Questions like, “Are employees required to complete a background check as a condition of hire?” commonly appear in vendor risk questionnaires. But to what extent is the risk of a malicious insider mitigated even when a vendor answers “Yes” to that question?

Take the case of Connor Tumbleson, a software engineer from Tampa, Florida who recently discovered that his professional identity was being used by an unknown individual (“the adversary” for all intents and purposes) to secure positions as a remote software engineer. You can read the full account of the incident and his personal investigation on his blog, but to paraphrase, his summary of the scheme:

• The adversary sets up fraudulent profiles on contract work sites, basing the profiles on legitimate professional identities.
• The adversary applies to jobs using the fraudulent profiles.
• If the adversary can secure an interview with an organization, they begin canvassing for individuals with a similar skillset who are willing to impersonate the legitimate individual during a video interview with the hiring company.
• If the video interview is conducted successfully and the hiring company extends an offer, the adversary may land the job.

In this scenario, a potential business associate answering “Yes” to a question about employee background checks is meaningless since at least some of those background checks will return results for the person the organization thinks it’s hiring, not the person who is being hired.

As research shows, insider threats continue to be a key component of adversary attack chains, security teams need to dig deeper into hiring practices along their supply chain to gain a thorough understanding of who is working for the vendor and how they were hired.

Who are your vendors’ vendors?

Supply chain risk management typically has a single-degree-of-separation scope. It is primarily concerned with vendors and suppliers that are directly connected to the organization. Visibility beyond that first degree of separation begins to get hazy and an organization may not have any knowledge of its supply chain at all beyond the second degree of separation. This leaves security teams with the elusive task of managing a set of risks about which little is known.

Many of the past decade’s most well-known software supply chain incidents involved a single degree of separation between the adversary’s initial access vector and the ultimate victim of the attack. Target was compromised through one of its HVAC contractors. Audi/Volkswagen suffered a data breach when one of its vendors left customer information in an unsecured internet repository. More recently, the Lapsus$ adversary group is believed to have gained access to Uber’s systems by compromising the account of one of the ride-sharing company’s contractors.

Still, other incidents could’ve ended up with a wider fallout pattern. Applications developed by organizations like Mimecast, SolarWinds, and Kaseya are deployed by numerous enterprise customers around the world. The SolarWinds breach alone was estimated to affect 18,000 customers. How many of those customers were part of another organization’s supply chain? How many of those organizations knew – definitively – that a link in their supply chain had been impacted by the SolarWinds breach, and to what extent? Incidents originating with well-known service providers can have a pervasive impact and can also be far more difficult to detect given the potential degree of separation.

So, is the degree of separation a major obstacle in the journey to effective supply chain risk management? Absolutely. Is there an easy solution or workaround? Not unless an organization has significant influence over its supply chain and the resources to manage oversight of all related entities (think the U.S. federal government).

What code is running in your environment?

Security researchers have noted a shift in the perpetration of software supply chain attacks from mostly state-sponsored groups to a broader spectrum of cybercrime operators. The outcome of this shift should be clear: more attacks, more (i.e., a wider variety of) targets and more victims. Adversary TTPs related to software supply chain attacks have also expanded to include developer account theft, authentication certificate theft, and surreptitious modification of core software components that are pushed through normal update processes. With the incidence of software supply chain attacks increasing sharply, this once-eschewed practice has become a critical part of supply chain risk management.

Even mature security teams will cringe at the thought of conducting code audits for software used by their organization. Few cybersecurity generalists have the skillset necessary to conduct thorough code audits for line-of-business applications, and those who do are typically focused on auditing an organization’s product, not its assets. Some challenges that internal code audits face cannot easily be overcome by internal resources, leading to sprawling risk acceptance or reliance on external entities for code auditing, such as:

• What programming language(s) are the organization’s applications written in? Does anyone in the organization have sufficient experience with those languages to identify security concerns?
• Are the applications open-source or closed-source (proprietary)? If closed-source, will it even be possible to audit the code?
• How many applications need to be audited? Is a software inventory available and are dependencies understood?
• Does a process exist to address discovered vulnerabilities? Can the manufacturer be reached for assistance or will the application need to be replaced?

Prepare for the worst, hope for the best

With a high-level understanding of supply chain incident scenarios and a close look at some supply chain risk management challenges, it should be clear that prevention alone isn’t enough to mitigate supply chain risks. This shouldn’t come as much of a surprise since foundational blue team strategies have shifted from prevention to detection to response and recovery over the past decade. Prevention is important, but supply chain preparedness must also include a response component.

Think of an organization’s relationship to its supply chain as a bridge. The bridge is built from technical components like a site-to-site VPN connection or a SaaS application. The organizations on either side of the bridge must work together to maintain the bridge, establish security checkpoints, monitor activity on the bridge, and uphold the expectations discussed and delineated while the bridge was being planned. If a security event occurs on either side of the bridge, both parties could bear responsibility, and – even then – the event could even extend beyond those boundaries. This is where preparation for supply chain incident response comes into play.

Supply chain incident response practices should be based on the organization’s existing incident response capability and documentation – leverage what is already known and practiced before creating something new. With that said, some general incident response practices should be given greater focus during a response to an incident along the supply chain.

Broaden Vendor Communications

During a traditional, internal incident, the incident response team will seek to quickly understand characteristics of the incident, such as the scope, affected systems and users, anticipated business impact or severity classification, and whether sensitive data has been compromised by the adversary. This information, which can be used to guide incident response efforts, cannot be directly obtained when the incident originates in a vendor’s environment unless a relationship is established to facilitate the sharing of that information.

An incident information-sharing mentality should be fostered at the outset of the vendor-business relationship. Begin by hosting conversations with vendor stakeholders about their existing security practices and establishing expectations for data handling and protection. Important discussion points include:

• What are the incident notification requirements? Establish the incident types and severities that the vendor will be required to report and decide the reporting timeframe.
• Will the vendor give the organization access to its security tools and logging during an incident? Most vendors will politely decline this request, but some may capitulate in certain circumstances (e.g., the vendor is also affiliated with the organization in some way). If direct access to tooling and logging won’t be provided, work to understand how indicators of compromise and other relevant incident data will be shared.
• Is the vendor willing to complete an incident questionnaire at pivotal times during the response process? Creating and providing a questionnaire with a small set of critical questions may help to facilitate easier and more useful communications during the chaos of an incident. Determine the best point(s) to exchange incident-related information in the incident response process.
• Who will be the point(s) of contact between the two entities during an incident? Knowing whom to contact and how to initiate that contact in advance will alleviate some of the stress that comes with every incident.

Similar conversations should be held with existing vendors on an established frequency (e.g., at contract renewal). These check-ins give both entities an opportunity to evaluate the status of the incident information-sharing arrangement and adjust as necessary. Maintaining open lines of communication with organizations along the supply chain promotes the discovery of better intra-organizational incident response practices that benefit the parties on both sides of “the bridge.”

Double Down on Asset Management

Rodgers and Hammerstein wrote a list of their favorite things that included a variety of interesting items, and asset management wasn’t one of them. Like code auditing, asset management is one of those necessary practices that security teams dread, and – despite what asset management software developers may say – there is no one best way for an organization to track and manage its assets. But it must be done, and it must be done effectively, especially in the age of supply chain attacks.

Asset management can help mitigate risks introduced by all three of the supply chain risk scenarios covered earlier in this article, but a few add-ons are suggested to make asset management an effective part of incident response activities.

• Inventory SaaS applications leveraged by the organization and document their business use case and relevant access authorizations. Go a step further and document the SaaS provider’s security contacts so they can be reached quickly for immediate action during incident response.
• Understand the effects of an intentional shutdown of various applications, systems and network segments as part of incident containment. Similarly, understand the business impact of shutting off a specific vendor’s access. Document the recovery process and any relevant dependencies so those assets can be brought online again in a safe and effective manner. Some related information may be available in Disaster Recovery and Business Continuity plans, but detail about forced asset shutdown is not usually addressed by those resources.
• Review the organization’s supply chain structure and map out data and access flows to and from vendors. Understanding which vendors have which data in advance will put the organization a step ahead when a vendor issues an incident notification, streamlining incident severity classification and notification requirements. Inappropriate data and access flows can also be modified or eliminated during this mapping process.

Test and Train

Testing and training are essential validation practices. A security team can talk all day long about its policies, procedures, plans, controls, tools, and systems. But when a blip finally appears on the organization’s incident radar, all that talk will be meaningless unless those protective functions have been tested and trained.

• Host a supply chain compromise-themed tabletop exercise and invite critical vendors to attend. Tabletop exercises are an industry-standard method to test an organization’s overarching security capability and are particularly useful for incident response preparation. Inviting personnel from critical vendors will create an opportunity to coordinate response teams, establish communication channels, and share notification expectations among all attendees.
• Contract an external security provider to conduct a purple team exercise in the context of a compromised vendor. Provide red team personnel with account permissions and remote access like that of a critical vendor to simulate the outcome of a vendor account compromise. Ensure that blue team personnel can detect the red team’s actions, and that related forensic data can be extracted from tooling for review by incident responders.
• Purchase and deploy a vulnerability scanning application to support asset and vulnerability management processes. Build out a vulnerability remediation cycle that addresses both hardware and software vulnerabilities. Vulnerability scan reports can also be used as reference material during incident response.

Gaps in either administrative (i.e., plans, policies, procedures, personnel) or technical (i.e., security controls, tooling) controls identified during testing and training should be addressed through the appropriate channels after the test concludes.