14 — Insider Threats and Supply Chain Attacks
Level: Intermediate · Time: ~20 min · Prerequisites: Lesson 13 — Credential and Active Directory Attacks
Why this matters
Every perimeter control assumes the threat arrives from outside. Two entire threat families ignore that assumption: the person who already has access, and the supplier you trusted to deliver something you did not inspect. Neither needs a vulnerability, a phishing email or a firewall hole, because in both cases the door was opened from the inside on purpose. Small organisations are hit disproportionately hard by both — an insider because two people do everything and nobody reviews it, a supplier because a single IT provider holding remote access holds the keys to hundreds of businesses at once. This lesson gives you the vocabulary, the controls that actually work, and the questions to ask before granting access.
The mental model: two ways to be already inside
| Insider threat | Supply chain attack | |
|---|---|---|
| Where the attacker starts | inside, with legitimate access | inside, wearing a trusted identity |
| What it exploits | trust in a person, and no monitoring of legitimate users | trust in a vendor, a package manager or a build system |
| Why perimeter controls fail | nothing crosses the boundary | the bad thing arrives as an approved update |
| Detection that works | behavioural anomaly, not signatures | provenance and integrity — what was built, from what, and by whom |
| Typical scale | one organisation | many organisations at once from one compromise |
Recognise the pattern: in both cases the defence is not a wall, it is verification — of behaviour, and of provenance.
Insider threats: three types, three playbooks
Treating "insider risk" as a single problem produces policies that punish the wrong people. There are three distinct cases.
| Type | Why it happens | Indicators | What actually helps |
|---|---|---|---|
| Malicious insider | money, grievance, ideology, or coercion — sometimes an employee under pressure from an external organised group | mass downloads or file copies before a resignation, access outside their role, unusual hours, printing sprees, queries for data they have no business in, sudden refusal to take leave | least privilege, need-to-know, logging all access to sensitive data, egress monitoring, exit process that revokes access the same day, mandatory leave and rotation for sensitive roles |
| Negligent insider | no malice at all: shadow IT, taking work home on a USB stick, reusing passwords, skipping a step because the process slows them down | unauthorised cloud services in use, data in personal email, unapproved devices on the network, process exceptions nobody recorded | security culture that makes the safe path the easy path, data classification, DLP, automation instead of admonition — this type is the most common by volume, which is why culture is a control and not a slogan |
| Compromised insider | their account is controlled by an external attacker — really Lesson 13 arriving through a legitimately logged-in session | logons from unusual locations or times, MFA prompts they did not initiate, mail rules created automatically, impossible travel | the identity controls: MFA, conditional access, session revocation, alerting on anomalous session behaviour |
The important consequence: for insiders, signature detection is worthless and anomaly detection is everything. There is no malware to match on — you are looking for a legitimate user behaving unlike themselves. That requires a baseline (Lessons 22 and 23), and it requires accepting that a legitimate account doing something odd is a finding.
Controls that work, and the ones that do not
| Works | Why | Does not work | Why |
|---|---|---|---|
| Least privilege and just-in-time elevation | access exists only when needed, so there is less to abuse and a cleaner log | "everyone is admin for convenience" | removes every barrier and every signal at once |
| Separation of duties | one person cannot complete a sensitive action alone | trusting a single approver | the same insider approves and executes |
| Mandatory leave and rotation | fraud and quiet abuse need continuity and secrecy | never reviewing access | dormant rights accumulate into privilege paths |
| Data classification and DLP | you can only protect and monitor what you have labelled | blanket "confidential" labels on everything | no signal, no enforcement |
| Logging privileged and data access | the only way to spot the mass-download pattern | logs nobody reads | detection without review is theatre |
| Egress monitoring | large volumes moving out look different from work traffic | blocking all USB ports with no process | users route around controls that break their job |
| Exit process run the same day | revokes access while the person still has other things on their mind | disabling accounts "at the end of the month" | a fortnight of live access after a resignation is an open door |
| A reporting culture that does not punish mistakes | negligent insiders self-report near-misses instead of hiding them | blaming the clicker | next incident goes unreported |
Supply chain, part one: the software you install
You are not writing most of the code you run. You are installing it, and by doing so you accept someone else's build decisions. Here is the pattern catalogue, in roughly the order a small team meets it.
| Attack pattern | How it works | Why it succeeds |
|---|---|---|
| Typosquatting | a package named one character away from a popular one, published on the same registry | installs are typed by hand or auto-completed |
| Dependency confusion | an attacker publishes a public package with the same name as an internal private package, at a higher version | build systems that resolve internal names from a public registry first |
| Malicious transitive dependency | a legitimate package depends on a package that is itself malicious — you never chose it | nobody reviews the full dependency tree |
| Compromised maintainer account | a maintainer's credentials are stolen and a malicious version published from the real project | consumers trust the package name, not the publisher's security |
| Poisoned build pipeline | code injected through a CI job, a build script or a compromised build tool, so the source looks clean | the artefact, not the repository, is what ships |
| Backdoored upstream component | a backdoor introduced into a widely used library or utility, sometimes over years of patient contribution | scale — one compromise reaches everyone downstream |
| Malicious update through a vendor's own channel | the attacker uses the vendor's signed update mechanism to deliver to all their customers at once | this path is trusted by design and often allowlisted at the firewall |
These are not hypothetical: documented cases include compromise of a widely deployed management platform's build, and a backdoor painstakingly inserted into a compression utility intended for distribution inside major Linux distributions. Both were found — one by a security vendor, one by accident — which is the honest headline: you will usually not detect these yourself. You depend on someone else detecting them, fast, and on your own ability to identify what you are exposed to.
The defence stack
| Layer | What to do specifically |
|---|---|
| Pin and lock | pin exact dependency versions, commit lockfiles, and treat a dependency change as a code change |
| Control the source | use a private registry or vendor your dependencies, so a public package cannot impersonate an internal name |
| Verify integrity | check signatures and checksums where the ecosystem provides them (package signing, Sigstore-style provenance attestations) |
| Know your inventory | generate a software bill of materials (SBOM) per application, so "are we affected" becomes a query, not a project |
| Scan continuously | scan dependencies for known-vulnerable versions in the pipeline and on running images (open-source scanners such as Trivy and Grype do this offline for free) |
| Limit CI blast radius | scope CI secrets narrowly, never expose long-lived credentials to pull requests from forks, and require review for any change to build configuration or dependency files |
| Watch upstream | subscribe to advisory feeds for what you actually run, and to the security mailing lists of your critical vendors |
[!WARNING] Your end-of-life and unmaintained dependencies are the quietest risk you carry: a package nobody maintains receives no security fixes and no advisory attention. If it is in your SBOM and its last release was years ago, treat it as a finding.
The practical reality for a small business: you cannot audit your vendors' code. You can reduce how many vendors you depend on, require evidence of their practices instead of trusting assurances, and make sure someone owns the question "what would we do if vendor X were compromised tomorrow?". That pre-written answer is worth more than any reading of their source code.
Supply chain, part two: the providers who hold your keys
A managed service provider or IT support company with remote access does not hold one key — they hold one key that opens hundreds of doors. When that provider is compromised, so is every client, which is why the cases small businesses actually suffer are usually vendor-mediated. Note the risk runs both ways: a compromised customer can be used to reach the provider's other customers, and the provider's tools are a route into you.
| Element | What it looks like in practice | What to do |
|---|---|---|
| Remote access | a support tool with unattended access, sometimes one credential for all clients | least-privilege access per client, time-limited sessions, named accounts, MFA with no shared admin login |
| Remote support tools as attacker tooling | the same legitimate remote-control software used by your IT provider is used by the attacker — nothing "malicious" is installed | alert on new remote-access tooling, monitor who the sessions are from, log every session |
| SaaS misconfiguration | a third-party app with delegated permissions to your mailbox, drive or identity platform | review delegated consents and third-party app grants on a schedule, remove what is unused |
| Contract gaps | no obligation to disclose a breach, no obligation to log for you, access nobody remembers to revoke | put access scope, logging, breach notification and offboarding in writing before signing |
Everything above belongs in the contract, not in good intentions. The essentials: least-privilege remote access scoped per environment; named individual accounts with MFA and no shared administrative logins; logs the provider shares with you (not just holds); a defined offboarding step that removes access when the contract ends; and a breach-notification clause with a deadline.
Supplier risk: the table to fill in before you grant anything
| Vendor type | The access you grant | The question to ask before granting it | Evidence to request |
|---|---|---|---|
| IT support provider | remote access to endpoints and servers, often administrative | who exactly can reach our systems, and is it named and MFA-protected? | access list, MFA policy, session logging sample |
| Cloud or SaaS provider | your data, sometimes delegated identity permissions | where is the data, who can read it, how do you notify me of a breach? | certifications or audit reports, data-processing terms |
| Hosting or data-centre provider | physical and network layer under your workloads | who has physical access, and what is the notification process? | facility controls summary, incident history |
| Software vendor | code running with your privileges | how do you sign your updates, and how fast do you ship critical patches? | SBOM, signing and release policy, patching SLA |
| Contractor or freelancer | an account, sometimes with repository access | which systems, for how long, and who revokes it? | access request, end date, offboarding checklist |
| Accounts or payroll service | your financial and personal data | what is the breach notification timeline? | contract clause, insurance, security questionnaire |
The security questionnaire you actually send
Keep it short enough that a small supplier answers it, and pointed enough to be useful. Nine questions:
- Do you enforce MFA on all administrative access, without exception?
- Who can access our data or systems, are those accounts named to individuals, and are they reviewed?
- What are your patch and end-of-life policies for the components exposed to us?
- Do you log administrative and access activity, and can you provide logs or evidence on request?
- How and within what timeframe would you notify us of a breach affecting our data?
- Where is our data stored, and who else can reach it (sub-processors)?
- How do you develop and release software — signing, dependency review, separate environments?
- What happens to our access and our data when the contract ends?
- Can you provide a third-party attestation (ISO 27001, SOC 2) or a penetration test summary?
If the answers arrive late, vague or defensive, that is itself the finding: it predicts how they will behave during an incident.
Attack it / Defend it
| The attack | How it works | The control that stops it |
|---|---|---|
| Departing employee data theft | copies what they can reach before resigning | least privilege, egress monitoring, same-day revocation, exit checklist |
| Negligent data handling | personal cloud storage, personal email, USB drives | classification, DLP, approved alternatives that work, awareness |
| Compromised legitimate account | external attacker uses a real user's session | MFA, conditional access, anomaly detection, session revocation |
| Typosquatted or fake package | a near-identical name on a public registry | lockfiles, private registry, curated allowlist of package names |
| Dependency confusion | a public package impersonates an internal one at a higher version | private registry precedence, namespace control, review of dependency changes |
| Poisoned build pipeline | build script or CI job modified to inject code | protected build config, review required for pipeline changes, scoped CI secrets, reproducible builds |
| Malicious vendor update | the vendor's own signed update channel delivers the payload | staged rollouts, monitoring for unexpected outbound behaviour from new versions, vendor diversity |
| MSP compromise | one provider's tooling reaches every client | per-client least privilege, MFA, session logging, contract clauses, alerting on new remote-access tooling |
| Third-party SaaS over-permission | an app granted broad access to mail or files, then breached | consent review, minimum scopes, remove unused integrations |
| Shadow IT | staff adopt a tool that never met your review | an approved-tools list, fast review so the answer is not always "no" |
Key takeaways
- The insider does not need a vulnerability. What you control is access, visibility and speed of revocation — not whether someone can be trusted.
- Negligence outnumbers malice, so "security culture" and ease of doing the right thing are controls, not soft extras.
- A compromised insider is just credential theft wearing a legitimate badge — the identity controls from Lesson 13 are the insider controls.
- You cannot audit your suppliers' code, so you reduce their number and demand evidence: SBOM, signatures, attestations, notification clauses.
- A supplier with remote access holds one key that opens hundreds of doors — so reduce their number, demand evidence, and pin, lock and inventory your own dependencies, so "are we affected?" is an afternoon's query rather than a month of archaeology.
Check yourself
- A helpdesk technician downloads 4,000 customer records over a weekend, two weeks after handing in their notice. Name two controls that would have prevented or detected it, and one that would not have helped.
- Why is password spraying or credential stuffing described as "a compromised insider" when nobody inside intended any harm?
- What is dependency confusion, and which single configuration choice makes it ineffective?
- Your IT provider's remote-management platform is breached. What three things would you want in place to know what happened on your systems?
- Which four questions would you ask a prospective managed service provider before signing, and why those?