They Hacked Your Supplier To Own Your Network.

Nov 12

Written By: AKATI Sekurity Insights Team | Cybersecurity Consulting & MSSP Experts

Reading Time: 6 minutes

The Investigation: In 2020, hackers compromised a single IT management software vendor called SolarWinds. That one breach cascaded into 18,000 organizations including US government agencies, Fortune 500 companies, and critical infrastructure operators. Nobody attacked these organizations directly. They attacked the vendor everyone trusted. This is supply chain security—the invisible threat most organizations don't know they're vulnerable to until it's too late. This investigation reveals how modern supply chain attacks work, why they're nearly impossible to prevent using traditional security, and what organizations can actually do about threats they don't control.

The Attack Nobody Saw Coming Because They Were Looking in the Wrong Direction

December 2020. FireEye, one of the world's premier cybersecurity companies, discovers they've been breached. Not by amateurs. By sophisticated attackers who stole their red team tools—the very software FireEye uses to test clients' defenses. Embarrassing, certainly. But as investigators dig deeper, they uncover something far more sinister. The attackers didn't break into FireEye directly. They came through a routine software update from SolarWinds, a company that makes network monitoring tools used by thousands of organizations including FireEye. SolarWinds Orion software—trusted, legitimate, digitally signed with valid certificates—had been compromised during the build process. Hackers inserted malicious code into the software updates that SolarWinds distributed to approximately 18,000 customers. When those customers installed what they thought were legitimate security patches, they were actually installing backdoors giving attackers access to their networks.

This wasn't a vulnerability in SolarWinds software that could be patched. This was intentional supply chain compromise—corrupting the software at its source so that the poison spread to everyone downstream. The sophistication was staggering. Attackers compromised SolarWinds' build environment—the systems where software is compiled before distribution. They hid their malicious code in legitimate updates. They used the software's own trusted communication channels to communicate with compromised systems, making detection incredibly difficult. The backdoor stayed dormant for weeks to avoid immediate detection. It checked for security tools and would deactivate if it detected analysis. It communicated with command-and-control servers disguised as normal SolarWinds network traffic. Organizations discovered they'd been compromised not because their own security detected anything, but because FireEye publicly disclosed the campaign. Even then, many didn't immediately realize they were affected.

The SolarWinds attack fundamentally changed how security professionals think about risk. Your organization might have perfect security. State-of-the-art firewalls. Best-in-class monitoring. Highly trained security teams. None of that matters if attackers compromise a vendor you trust and use that vendor as a trojan horse into your environment. This is supply chain security—and it's the nightmare scenario keeping CISOs awake at night.

The Vendors You Know About And the Vendors' Vendors You Don't

Here's what makes supply chain security so wickedly complex. You probably know which vendors have access to your systems. Your cloud provider. Your email provider. Your payroll processor. Your CRM system. You've (hopefully) vetted these direct vendors, reviewed their security certifications, maybe even audited their practices. But what about their vendors? Your cloud provider uses third-party data center operators, networking equipment from hardware manufacturers, and software components from dozens of suppliers. Your email provider relies on infrastructure vendors, security tools from other companies, and open-source libraries maintained by volunteers you've never heard of. Your CRM system incorporates code from countless third-party services—payment processors, analytics platforms, mapping services, authentication providers.

Each of these represents a potential attack vector. Attackers have figured out that breaching one widely-used vendor provides access to hundreds or thousands of downstream targets. Why hack a bank directly when you could hack the banking software vendor and compromise hundreds of banks simultaneously? Why target one hospital when you could breach the medical device manufacturer and reach thousands of healthcare facilities? This is n-tier supply chain risk—the idea that you're not just depending on your direct vendors (tier 1), but on their vendors (tier 2), and their vendors' vendors (tier 3), extending indefinitely. Most organizations have no visibility beyond tier 1, maybe tier 2 at best. Attackers understand this blind spot and exploit it ruthlessly.

Real-world example: In 2017, accounting software called CCleaner was compromised. Millions of users downloaded what they thought was a legitimate system optimization tool. Instead, they installed malware that gave attackers access to their systems. The attackers didn't target individual users. They compromised the software vendor's build pipeline, just like SolarWinds. Another example: British Airways suffered a 2018 data breach affecting 380,000 customers. Attackers hadn't breached BA directly. They compromised Modernizr, a JavaScript library BA's website used for browser feature detection. Through that compromised library, attackers injected code that skimmed credit card data during transactions. BA had vetted their payment processors. They had strong security. But they didn't control the security of every third-party JavaScript library their website loaded, and that's what attackers exploited.

Step 1: Map Your Supply Chain All the Way Down the Rabbit Hole

The first step in supply chain security is understanding your supply chain—which sounds obvious but proves shockingly difficult in practice. Most organizations can list their major vendors. Fewer can list all vendors with system access. Almost none can map dependencies beyond direct vendors. Start with an inventory of all external parties with any level of access to your systems, data, or operations: Cloud infrastructure providers, software-as-a-service applications, managed service providers, outsourced IT support, payroll and HR systems, contractors and consultants with VPN access, vendors with API integrations, third-party code libraries and open-source components, and hardware suppliers whose firmware or software runs on your equipment.

For each vendor, document: What systems or data can they access? What authentication mechanisms protect that access? How is their access monitored? What's their security posture—do they have relevant certifications (SOC 2, ISO 27001, etc.)? Have they experienced known breaches? What's your contractual recourse if they cause a security incident? Now comes the hard part—understanding tier 2 and tier 3 dependencies. Your cloud provider depends on whom for data centers, network infrastructure, and hardware? Your SaaS applications incorporate which third-party services, libraries, or APIs? Your contractors use what tools and systems to do their work for you? Most vendors can't or won't provide complete lists of their sub-vendors, considering it proprietary information. This creates blind spots you'll never fully eliminate. But asking the question and getting partial answers is better than no visibility at all.

Step 2: Implement Vendor Security Requirements With Teeth, Not Just Paperwork

Traditional vendor management treats security as a checkbox exercise. Vendor fills out a questionnaire. Maybe provides a SOC 2 report. Gets approved. Done. This approach fails catastrophically for supply chain security because it's backward-looking (assessing past state, not current security) and trust-based (assuming vendors remain secure after vetting). Modern supply chain security requires continuous verification, not periodic trust. Establish minimum security requirements for vendors based on their access level: Tier 1 vendors (high access, sensitive data) require SOC 2 Type II or ISO 27001 certification, mandatory security training for staff accessing your systems, multi-factor authentication for all access, regular penetration testing with results shared, incident response plans with defined notification timelines, and cyber insurance with adequate coverage naming you as additional insured.

Tier 2 vendors (moderate access) require documented security policies, multi-factor authentication, incident response plans, and annual security assessments. Tier 3 vendors (low access) require basic security questionnaire completion and acknowledgment of security responsibilities. Here's the crucial part—put teeth in these requirements through contracts. Include security requirements in vendor agreements, not as appendix boilerplate but as material terms. Specify right to audit vendor security annually or after incidents. Define service level agreements (SLAs) with penalties for security failures. Require prompt breach notification—many vendor contracts say they'll notify you "promptly" but don't define timeframes, leading to delays. Make security failures grounds for contract termination without penalty. Include indemnification clauses for losses caused by vendor security failures.

Step 3: Monitor Vendor Access Like You Monitor Everything Else

Granting vendors system access then forgetting about them is how breaches happen. Vendor credentials get stolen. Employees leave vendors but keep access. Vendor companies get acquired and new owners have different security standards. Monitoring vendor access requires: Dedicated accounts for vendors that are easily identifiable in logs—never let vendors share credentials with internal staff. Time-limited access that expires automatically—vendor needs access for a three-month project, access terminates automatically at project end rather than requiring manual revocation. Just-in-time privileged access for sensitive operations—vendors request elevated permissions for specific tasks, receive temporary access for defined duration, then automatically downgraded. All vendor sessions logged and monitored for anomalous activity—if a vendor usually logs in during Singapore business hours and suddenly connects from Eastern Europe at 3 AM, that triggers alerts. Regular access reviews to confirm vendors still require access—quarterly reviews where business owners confirm each vendor account is still necessary, disabling unused accounts.

Step 4: Segment Networks to Contain Vendor Breaches

Accept this reality: vendors will be compromised. You can't prevent it. What you can do is limit damage when compromises happen. Network segmentation creates barriers preventing compromised vendors from reaching your crown jewels. Place vendors in isolated network zones (DMZs) separate from internal systems—vendors connect to dedicated environments, not your corporate network. Implement least-privilege network access where vendors reach only specific systems they need, nothing else. Use jump servers or bastion hosts for vendor remote access—vendors remote into intermediate systems that connect to internal resources, never directly to internal systems, creating audit and control points. Deploy micro-segmentation for critical assets ensuring your most sensitive systems have additional access controls beyond general network security.

Monitor traffic between vendor zones and internal networks with intrusion detection—not just logging connections but analyzing what vendors are doing once connected. Real example: A financial institution allowed an HVAC vendor network access to building automation systems. Proper segmentation would have isolated building controls from financial systems. They hadn't implemented segmentation. When the HVAC vendor was compromised (remember the casino aquarium from earlier?), attackers pivoted from building controls to financial networks. Segmentation would have prevented this lateral movement, containing the breach to non-critical systems.

Step 5: Plan for Vendor Security Incidents Because They're Coming

Include vendor compromise scenarios in incident response planning. What if your email provider is breached—how do you communicate during response? What if your cloud provider suffers an outage or breach—do you have data backups you control? What if a critical SaaS application becomes unavailable—can you operate manually temporarily? What if you discover a vendor has been compromised for months—how do you assess what data was accessed? Your incident response plan should include: Vendor notification procedures during your incidents and procedures for when vendors notify you of their incidents. Vendor communication protocols—who contacts vendors, how quickly, what information is shared. Alternative vendors or manual processes for critical dependencies if primary vendor is compromised or unavailable. Data recovery procedures that don't depend solely on vendor cooperation.

Legal and public relations protocols for vendor-caused breaches, since these situations create complex liability and communication challenges. Conduct tabletop exercises specifically for vendor compromise scenarios. Walk through what happens if a major vendor is breached. Who gets notified? What actions are taken? What communications go where? Organizations that practice these scenarios respond dramatically better during real vendor incidents than those improvising.

Step 6: Embrace the Uncomfortable Truth You'll Never Eliminate This Risk

Here's what you need to understand: supply chain security is fundamentally about managing risks you don't control. You can vet vendors. You can implement monitoring. You can segment networks. You can plan for incidents. But you cannot eliminate the risk of vendor compromises affecting your organization. This is uncomfortable for security-minded people who like definitive solutions. There is no definitive solution to supply chain risk. There's only risk management—reducing likelihood where possible, limiting impact when breaches occur, and maintaining awareness of your dependencies. The organizations that handle this well accept this reality and build resilience. Multiple vendors for critical dependencies so single vendor compromise doesn't halt operations. Data controls ensuring sensitive information isn't wholly dependent on vendor security. Monitoring and detection that catches vendor-sourced attacks quickly. Incident response capabilities that work even when vendors are compromised or unavailable.

Organizations that handle this poorly live in denial, trusting vendors completely because acknowledging the risk is too uncomfortable, or they become paralyzed, refusing to use any external vendors and trying to build everything in-house (which creates different problems and usually isn't feasible). The middle path—informed risk acceptance with active management—is where mature organizations operate.

AKATI Sekurity: Helping Organizations Navigate Third-Party Risk

Supply chain security requires specialized expertise assessing risks you don't directly control. AKATI Sekurity's Cybersecurity Consulting services include third-party risk management program development—creating vendor security requirements, assessment processes, and ongoing monitoring frameworks. We help organizations map supply chain dependencies, identify high-risk vendors requiring additional scrutiny, and prioritize remediation efforts. Our Security Posture Assessments include third-party risk evaluation, analyzing whether your vendor security practices adequately protect against supply chain attacks. We evaluate vendor contracts for security provisions, highlighting gaps where terms don't adequately protect you from vendor-caused incidents.

Through 24/7 Managed Security Services, we monitor vendor access to client environments, detecting anomalous vendor activity that might indicate compromised credentials or malicious insiders. Our Penetration Testing services include supply chain attack simulation—testing whether attackers could use vendor access as entry points to reach critical systems. For ASEAN organizations managing regional vendor ecosystems, we understand local vendor security maturity levels and help establish risk-appropriate requirements balancing security with business realities. For US organizations facing regulatory scrutiny of third-party risk management (particularly in financial services and healthcare), we help implement frameworks satisfying regulatory expectations while remaining operationally practical.

You can't eliminate supply chain risk. But you can manage it. Contact AKATI Sekurity at hello@akati.com for more information.

About the Author: This article was written by AKATI Sekurity's third-party risk management and supply chain security specialists who help organizations assess, monitor, and mitigate vendor security risks across financial services, healthcare, technology, and manufacturing sectors in ASEAN and North America.

Key Terms Explained:

Supply Chain Attack: Cyberattack targeting an organization indirectly by compromising a trusted vendor or supplier
N-Tier Risk: Risk extending through multiple levels of vendors (your vendors' vendors' vendors)
Third-Party Risk Management (TPRM): Process of identifying, assessing, and mitigating security risks from external vendors
Vendor Security Assessment: Evaluation of a vendor's security practices before granting access or sharing data
Network Segmentation: Dividing networks into isolated zones to limit lateral movement during breaches

References:

SolarWinds Supply Chain Attack Analysis, Cybersecurity & Infrastructure Security Agency (CISA)
NIST Special Publication 800-161: Cybersecurity Supply Chain Risk Management
Third-Party Cyber Risk Management Guidelines, Monetary Authority of Singapore

Tags: Supply Chain Security, Third-Party Risk Management, Vendor Security, SolarWinds Attack, Supply Chain Attack, N-Tier Risk, Vendor Risk Assessment, Third-Party Access Management, TPRM, Vendor Compromise, Cybersecurity Supply Chain Malaysia, Third-Party Security ASEAN

Supply Chain SecurityThird-Party Risk ManagementSolarWinds AttackVendor Risk Assessment