Chapter 36 Β· Supply Chain Vulnerabilities

Trusted to a Fault

Jordan, a security incident response analyst, always assumed the biggest threat was someone trying to break in. Then she traced a breach to someone who was already let through the front door β€” wearing a vendor badge.

The Breach Nobody Expected

Jordan gets called in at 2 AM. The SIEM has fired on unusual lateral movement β€” a service account with access to the finance file server is downloading large volumes of data to an unfamiliar endpoint. She traces the account: it belongs to a payroll integration vendor. The credentials are legitimate. The VPN connection originates from the vendor's IP range. Nothing has technically been "broken in" β€” the door was opened from the inside using a valid key.

Two hours of forensic analysis later, she has the picture. The payroll vendor's systems were compromised six weeks earlier through a phishing email. The attackers spent those weeks moving through the vendor's network, harvesting VPN credentials, and mapping which clients had the most valuable data. Jordan's organization, a regional bank, was the prize. The attackers used the vendor's legitimate credentials to access the bank's systems during normal business hours. No alarms fired for six weeks because nothing looked wrong β€” just a vendor account doing vendor things at vendor hours.

πŸ’‘ Supply Chain Attacks A supply chain attack targets the relationships between an organization and its external partners β€” service providers, hardware manufacturers, software vendors, or suppliers. Rather than attacking the hardened perimeter of the final target directly, attackers compromise a weaker link in the chain and use that trusted relationship to gain access. The attack is effective because organizations must extend some level of trust to partners with legitimate access to their systems. One successful exploit anywhere in the chain can propagate to every organization connected to it.

The Vendors That Know Your Network

As Jordan investigates, her manager pulls up the full list of vendors with any kind of network access to the bank: payroll processing, HVAC monitoring, ATM maintenance, managed print services, external auditors, cloud infrastructure, and a dozen software vendors whose products connect back for updates or license verification. "Every one of these," her manager says, "has some kind of connection to us. Some have VPN tunnels. Some have service accounts. Some have read access to directories. And we audited their security practices exactly once β€” when we signed the contract three years ago."

Jordan thinks about the Target breach from her security training. In November 2013, attackers didn't break into Target directly. They targeted Fazio Mechanical Services, an HVAC contractor that monitored refrigeration systems at Target stores. A phishing email infected Fazio's systems and stole VPN credentials used by HVAC technicians to access Target's network remotely. Because Target's internal network was insufficiently segmented, the attackers reached point-of-sale systems in approximately 1,800 stores. Forty million credit card numbers were stolen. The HVAC company never would have appeared on a traditional threat model β€” but it had the keys to the kingdom.

πŸ’‘ Service Provider Risk Organizations control their own security posture but cannot directly control the security practices of their service providers. Yet service providers β€” HVAC contractors, payroll processors, IT support firms, cleaning services, cloud providers, managed system administrators β€” often have legitimate, direct access to internal systems. An attacker who compromises a service provider with access to ten clients gains ten potential targets for the price of one. Security audits should be written into vendor contracts and conducted on an ongoing basis, not only at onboarding.

The Router That Wasn't What It Claimed

Two months after the payroll incident, Jordan is called in on a separate problem. A network engineer has discovered that twelve switches purchased from a reseller 18 months ago are performing below specification and two have failed unexpectedly. Opening one up and comparing the internals against manufacturer documentation, the components don't match. The firmware doesn't match. The hardware is counterfeit.

The case echoes something Jordan researched after the incident: in July 2022, the U.S. Department of Homeland Security arrested a reseller CEO who had sold more than $1 billion in counterfeit networking equipment. The individual operated through more than 30 shell companies to conceal the scheme, which had been running since 2013. The fake devices were manufactured overseas and labeled as products from a major networking vendor β€” sold as authentic until they started failing or, in some cases, catching fire. All network traffic flows through switches and routers. A counterfeit or backdoored network device is a perfect vantage point β€” a silent observer for everything that passes through it.

πŸ’‘ Hardware Supply Chain Risk Counterfeit or tampered hardware enters the supply chain through fraudulent resellers. Counterfeit devices may use inferior components, harbor unknown vulnerabilities, or contain hidden backdoors. Network equipment β€” switches, routers, firewalls β€” is a particularly high-value target because all traffic flows through it. Mitigations: purchase directly from authorized distributors; verify hardware authenticity against manufacturer documentation and checksums; maintain a small, vetted supplier base; build physical inspection and authenticity verification into the procurement process.

The Update That Wasn't an Update

Jordan keeps returning to the case that redefined supply chain security thinking: SolarWinds. SolarWinds made Orion, an IT monitoring platform used by approximately 18,000 organizations including major corporations and U.S. government agencies. In March and June of 2020, attackers compromised SolarWinds' own build pipeline β€” the automated system that compiled and packaged Orion for distribution. They inserted malicious code into the legitimate software update. The modified code passed SolarWinds' own internal testing because it was engineered to lie dormant and evade detection during testing conditions.

The update was signed with SolarWinds' legitimate code-signing certificate and distributed through the normal update channel. Customers installed it as instructed. Security tools verified the signature and approved the installation. No one was suspicious β€” it looked exactly like every other SolarWinds update. The malicious code wasn't discovered until December 2020, nine months after the first infected update shipped. By then, attacker access had spread across 18,000 installations: Microsoft, Cisco, Intel, Deloitte, the Pentagon, the Department of Homeland Security, the State Department, the Department of Energy, the National Nuclear Security Administration, and the U.S. Treasury.

"The code was signed," Jordan explains to a colleague. "Completely valid signature. Code signing proves who signed it β€” not that what was signed is safe. SolarWinds signed it themselves, using their legitimate certificate, after the attackers had already changed what they were signing. The signature was authentic. The code was malicious. Those are two separate questions."

πŸ’‘ SolarWinds SUNBURST SUNBURST is the malicious code injected into SolarWinds Orion updates in 2020 β€” the defining software supply chain attack. Key points: (1) Attackers compromised the build pipeline before the code-signing step β€” the legitimate certificate was applied to already-malicious code. (2) The compromised update was functionally indistinguishable from a legitimate update. (3) The attack was undetected for nine months. (4) Impact scaled across all 18,000 customers who installed the update, including critical U.S. government agencies. Lesson: code signing verifies provenance (who signed it) β€” it does not verify safety (that what was signed is benign).

Making Trust Earned, Not Assumed

Jordan presents her findings to the bank's leadership. Supply chain risks span three attack surfaces: service providers with internal access, hardware that may be counterfeit or tampered, and software that may be compromised before it arrives. "We can't eliminate trust," she says. "We need vendors. We need software. We need hardware. But trust can be earned and verified rather than assumed and forgotten."

Her proposal covers all three layers. For service providers: security audit requirements written into contracts and conducted periodically, not just at onboarding. Vendor accounts segmented so they can only reach systems they require. Behavioral monitoring on vendor credentials to detect anomalous access. For hardware: procurement only from authorized, vetted distributors. Physical inspection and authenticity verification before deployment. For software: digital signature verification on all installs. Staged rollout of updates through a test environment before production deployment. Development of an SBOM (Software Bill of Materials) for critical applications to understand every external dependency. "We won't be able to audit the entire chain," she tells the room. "But we can dramatically shrink the surface available for abuse."

βœ… Supply Chain Security Controls (1) Vendor management program β€” security audit requirements in contracts, periodic reviews, not just onboarding. (2) Network access segmentation β€” vendor accounts access only required systems; monitor vendor accounts for anomalous behavior. (3) Authorized hardware procurement β€” purchase from vetted, authorized distributors; verify hardware authenticity before deployment. (4) Software verification β€” verify digital signatures; stage updates in test environments before production; maintain SBOM for dependency visibility. (5) Least-privilege vendor access β€” vendor credentials are privileged accounts; restrict scope; alert on unusual patterns.