Is Your Organization Prepared for a Supply Chain Disruption?

What Is a Supply Chain and Supply Chain Management?

To compliment my last article on Patch Management, we’re going to contemplate some of the nuances around supply chains and Supply Chain Management. Investopedia defines supply chain as “a network between a company and its suppliers to produce and distribute a specific product to the final buyer.” Furthermore, Supply Chain Management is defined as “the management of the flow of goods and services.”

There are a few different perspectives you can view supply chain from, either as a consumer of products and services, as a distributor of those products and services, or as a manufacturer of those products and services.

Supply Chain Risk – What Happens When the Chain Breaks?

In traditional warfare, a common strategy was to capture territory along supply routes of your opponent in an effort to starve them of the supplies they need to fend off your attacks. In cyber security, the objective of a supply chain attack to organizations might not be as clear as it is in traditional warfare, but the threat of attack and risk from that threat are still there.

A cyber security supply chain attack can be an incident where one of your suppliers is disrupted and unable to provide you with necessary supplies, or it can be an attack where a threat actor has compromised one of your suppliers in order to further compromise your network. It can also translate to a disrupted supply of consumer merchandise.

In September of 2017, one of the most well-liked consumer tools for computer maintenance suffered a supply chain attack. CCleaner, owned by Avast, was discovered by Cisco Talos to have distributed a malicious payload via legitimate update servers. Fortunately, this particular attack did not appear to cause too much chaos downstream due to early detection and the software vendor providing updates to the product and removing the malicious code. The impact could have been far greater (as CCleaner touts over two billion downloads) if security researchers in Cisco had not been alerted to the intrusion by beta testing their exploit-detection technology. As it stands, there were more than two million downloads of the malicious update, but only a limited number of them appeared to activate or execute any kind of Command and Control (C2) function.

Another notable attack by the advanced persistent threat actor (APT) known as Barium — the CCleaner attack was attributed to them as well — was a similar method this time targeting ASUS Update servers with malware for distribution through legitimate downstream services to consumers. In this instance, more than 13,000 devices were infected with malware.

These attacks have continued from various threat actors and appear to be picking up more steam with major supply chain attacks making headlines even earlier this week. In December of 2020, FireEye discovered that their networks had been compromised due to a supply chain attack using SolarWinds update servers as the attack vector to distribute malware. This attack was found to have successfully compromised network components of multiple US Government agencies including the Department of Commerce, the Department of Defense, the Department of Energy, the Department of Homeland Security, and the Department of Justice.

More recently, there have been major attacks on consumer supply chains. These attacks include the JBS meat processing attack and the Colonial Pipeline attack. These attacks were both ransomware attacks, but the ransomware caused a supply chain disruption. These two attacks might not seem to follow the same trend as the others I’ve described, but they are still attacks on supply chain. The difference is that in the software update attacks, the malicious payload hit consumers directly. In the attacks on the meat processing plants and petroleum pipeline, the malicious payload hit those companies, but disrupted their operations causing shortages to their consumers. This is more akin to the traditional notion of a supply chain attack in warfare.

However, as recently as last week, another major software update service supply chain attack occurred via Kaseya VSA. This attack, like the CCleaner, ASUS, and SolarWinds attacks, was a breach of Kaseya’s internal network that was then leveraged to distribute ransomware downstream via their update servers to Kaseya’s customers. The big change here is the number of customers who received the malicious payload, and what types of customers they were. Kaseya’s customer base includes Managed Service Providers who in turn support numerous other customers. Around sixty direct customers of Kaseya were directly compromised, leading to an indirect impact to approximately 1,500 separate downstream businesses.

There Are So Many Chains – Is There a Repeatable Method to Risk Management?

The good news is there are a number of controls that can help an organization reduce the risk of a supply chain attack. To start with, one concept to consider is diversification. Contracting with multiple vendors can be a good Risk Management strategy — so if supply from your prime vendor is disrupted, you can readily call on alternative vendors with whom you’ve already established a contractual relationship. To return to the basic fundamentals of security with the Confidentiality, Integrity, and Availability (CIA) triad, this really speaks to the Availability concept, ensuring that your organization’s critical supplies remain available to you throughout disruptive events permitting continuity of operations. To clarify though, vendor diversification only provides a resiliency to disruptive attacks, not to attacks intended to infect downstream customers.

As a natural progression from vendor diversification, you should also orchestrate a routine lifecycle refresh plan for hardware assets. In a former role as a service desk manager, I was responsible for managing the lifecycle of all workstations (desktop, laptops, printers, peripherals, etc.). My plan was very simple, but it was effective for managing cost and minimizing wasteful spending. The approach I took to managing our hardware lifecycle is illustrated below.

Figure 1: Hardware Refresh Lifecycle

The phased approach to a hardware lifecycle refresh requires that you start from a strong point of Asset Management. In my case, I used a 3-phase approach due to a standard 3-year warranty on most of our hardware assets. Each phase lasted for a full fiscal year, allowing us to order and replace approximately 1/3 of our hardware assets per year. As one phase approached conclusion (near the end of FY), preparations would be made to order the next phase’s equipment. This phased approach also allows for a natural 3-year continuous lifecycle, focusing on replacing the equipment at end-of-warranty first, also referred to as “first in, first out” or FIFO.

Managing Upstream Supply Chain Risks with SOCs

Another facet of Supply Chain Risk Management can be found in the form of Service Organization Controls (SOC) reports. [No, not the other SOC acronym for Security Operations Center, but when I first learned about SOC reports that’s what I thought too!] A SOC report is a way that an organization can verify and validate that specific best practices are being adhered to before we consider outsourcing a business function to that organization.

There are three main versions of SOC reports, which are further broken out into different types for each version. A SOC 1 report focuses on controls with an immediate downstream effect on an entity’s financial statements. SOC 1 reports can be a Type 1 or a Type 2 report. Type 1 shows how well internal controls are designed to prevent mistakes regarding financial transaction data, with testing performed at one point in time; not testing operational effectiveness. Type 2 tests operational effectiveness of internal controls designed to mitigate risk of financial inaccuracy.

A SOC 2 report is probably more relevant to specifically managing the risk of supply chains, because a SOC 2 report provides information on controls related to security, the CIA triad, and specifically mandates security control testing. SOC 2 reports have two subtypes as well, Type 1 testing design of controls at one point, while a Type 2 tests operating effectiveness of security controls conducted over a period of time and sampling methodology used for accuracy.

A SOC 3 report is the same as a SOC 2 report, but with redaction of confidential information. This particular report can be used as a foundation of trust between two organizations, but I would highly recommend that you include contract language that allows you visibility into your supplier’s SOC 2 Type 2 reports.

NDAs are likely appropriate in this context, to provide reasonable consideration to your supplier’s own privacy rights. If your partner absolutely cannot provide visibility into a SOC 2 Type 2 report for regulatory or legal reasons, then as a minimum they need to provide a SOC 3 report, while you may want to consider strengthening your contract language to provide legal controls for your agreement to mitigate risks incurred via your partnership.

Up and Coming Supply Chain Controls: SBoM/DBoM

If you’ve worked in business, especially in or around manufacturing, for any length of time, you’ve likely seen a Bill of Materials. In traditional manufacturing, a Bill of Materials is a list of raw materials, components, and instructions required to construct, manufacture, or repair a product.

One of the up and coming ideas for consideration in the realm of supply chain security is a Software Bill of Materials (SBoM) along with a Digital Bill of Materials (DBoM). The National Telecommunications and Information Administration (NTIA) have published SBOM at a Glance which clarifies what a SBoM should include, but they’ve also answered the why. An SBoM should enable stakeholders to identify whether they are affected by a particular supply chain issue, and identify where in the supply chain they may be affected.

A SBoM should include inventory of software components, dependencies, and should be comprehensive wherever possible, and when it cannot be comprehensive should provide a justification explaining why. A SBoM might be also contain baseline information such as author, supplier, version, hash, unique identifiers, and even a definition of the relationship of the component being documented.

A DBoM is not exactly the same thing as a SBoM. The DBoM consortium was formed to create infrastructure to share SBoMs in shared repositories. This allows for supply chain dependencies to be more visible to consumers, as a DBoM may include multiple SBoMs and may even include SBoMs within SBoMs depending on component dependencies, etc. However, the key differentiator between a DBoM and SBoM is that a DBoM gives partners in supply chain relationships a way to attest to the security of the contents of their software to one another, and a way to share that attestation throughout the supply chain downstream to the consumer.

SBoM/DBoM – Why Reinvent the Wheel?

You might wonder, how is a DBoM any different from SOC reports and contract language? In fact, from a policy standpoint, it might seem a little redundant. However, there’s a technical layer that you can apply to this particular control mechanism: blockchain.

For a quick explainer on blockchain, and another relevant application of blockchain, please read our blog article on it! In short, blockchain uses a distributed ledger and cryptographic hashing to validate the integrity of an asset.

Any repository technology could be used to create a DBoM channel, but applying blockchain allows for the accountability of the attesting parties to remain extremely high.

Attestations such as SBoMs can be stored within a DBoM channel with DBoM nodes of each partner controlling access. Due to modularity of DBoM frameworks, and one iteration of DBoM code hosted on github, anyone can set up attestation channels for any partner in the supply chain they care about. This potentially allows for streamlining information back to a supplier from downstream sources. This could improve bug-reporting processes and resolve communication breakages due to third party involvement between consumers and suppliers.

Start Prioritizing Supply Chain Management

To summarize this article, we discussed what a supply chain is with regard to our digital world, and contemplated the numerous risks, and historical events highlighting those risks to our supply chain. When we address the risks to our supply chains effectively, we’re providing a benefit not only to our own organization, but to our own clients as well.

Managing supply chain risks successfully can prevent financial losses due to business disruption and potential regulatory fines as a result of an unmitigated data breach. With an effective supply chain strategy incorporating the lifecycle of hardware assets, we can accelerate digital transformation and improve operational efficiencies from losses due to hardware failures.