COMP 6660 · Enterprise Cybersecurity Insider Threats and Supply Chain Security

00 Introduction

Unit 3 has examined adversaries through a series of lenses: the risk framework (3.1), threat modeling (3.2), vulnerability assessment (3.3), malware and ransomware (3.4), social engineering (3.5), and advanced persistent threats (3.6). This final lesson closes the unit by examining two threat categories that are frequently underestimated — because they do not fit the model of an external attacker.

The first is the insider. Insiders are the people who are supposed to be trusted — employees, contractors, partners, and service providers with legitimate access to the enterprise's systems, data, and facilities. The threat they pose is not hypothetical; insider incidents produce substantial losses across enterprises of every sector and size. And insider risk does not require a malicious actor; a single misdirected email, a misconfigured system, or a carelessly shared credential can produce consequences indistinguishable from deliberate attack.

The second is the supply chain. Every enterprise depends on third parties — software vendors, cloud service providers, managed service providers, hardware manufacturers, and business partners. Each dependency extends the enterprise's exposure beyond its own controls. The SolarWinds campaign (Lesson 1.6) demonstrated what this means at scale: a single compromised vendor update affected tens of thousands of downstream organisations, including many of the world's most sophisticated and well-defended enterprises.

The two categories interact in important ways. Insiders frequently enable supply-chain compromise — by approving malicious vendor updates, providing access to third parties, or disclosing information that facilitates attacks. Supply-chain compromise frequently produces insider-like access — an external actor operating through a trusted vendor's legitimate credentials looks, in many respects, like an insider. And the defensive strategies for both categories share a common theme: extending the enterprise's security governance beyond the individuals it directly employs and the systems it directly operates.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 3 outcomes U3.1 (threat analysis), U3.3 (attack techniques), and U3.4 (mitigation strategies), and to Module 2 outcomes M2.1, M2.3, and M2.4. See the Unit 3 learning outcomes page for the full mapping.

02 Two threat categories

Insider threats and supply chain risk are distinct categories, but they share important characteristics that justify treating them together.

Why they are treated together

How the categories differ

03 Insider threat types

The term "insider threat" covers three distinct phenomena. Confusing them leads to poorly designed controls — because the controls that address malicious insiders are not the controls that address negligent ones, and neither set addresses the compromised insider effectively.

Why the distinction matters

The three types require fundamentally different defensive approaches:

Why insiders are disproportionately damaging

Insider incidents are frequently more damaging than external attacks of comparable technical sophistication. Several factors contribute:

• They bypass perimeter controls. Insiders have legitimate access, so controls designed to keep outsiders out do not apply.
• They know what is valuable. Insiders understand which data matters, where it lives, and how it is protected — knowledge that external attackers must acquire over time.
• Their activity looks legitimate. An insider accessing systems during working hours is not anomalous. Detection requires behavioural baselines and careful analysis.
• They may act over extended periods. Malicious insiders can sustain activity for months or years without detection, particularly when the volume of activity is small and consistent with their role.
• Post-incident attribution is difficult. Determining what was taken, when, and by whom can be impossible without comprehensive logging and clear identity attribution.
• Trust magnifies the consequence. The enterprise has invested trust in the individual — through access, through knowledge, through relationships. The consequence of that trust being violated is not merely the direct harm but the erosion of the trust on which the enterprise's operations depend.

04 Insider threat risk factors

Insider risk is not random. Certain circumstances increase the likelihood of malicious insider activity, and certain circumstances increase the likelihood of negligent incidents. Understanding these factors allows enterprises to focus monitoring and intervention where they are most needed.

Risk factors for malicious insider activity

Risk factors for negligent insider activity

Negligent insider incidents are produced by different factors, generally related to the conditions under which work is performed:

• Time pressure. Users under pressure take shortcuts, skip verification, and make errors.
• Complexity. Complex processes and systems produce errors; users develop workarounds that bypass controls.
• Friction. Security controls that impose excessive friction drive circumvention — users find ways to avoid the friction, often reducing security.
• Unclear expectations. Users who do not understand the security expectations cannot meet them.
• Lack of feedback. Users who receive no feedback on their security behaviour cannot improve it.
• New employees and contractors. Individuals who are new to the enterprise, the role, or the systems are more likely to make errors.
• Change. New systems, processes, or responsibilities disrupt established habits and increase error rates.

The ethics of risk factor identification

The identification and use of insider risk factors raises ethical and legal considerations. The factors listed above are statistical tendencies, not individual predictions; most employees who exhibit one or more of them do not become malicious insiders. Using these factors to target individuals for surveillance or adverse treatment is both ethically problematic and often legally constrained — and counterproductive, because it undermines the trust and culture on which enterprise security depends.

The appropriate use of risk factors is to inform the design of supportive interventions — access reviews, additional checks during high-risk periods, grievance mechanisms, employee assistance — not to identify individuals for suspicion. The enterprise that treats insider risk as a matter of employee wellbeing rather than employee suspicion produces better security outcomes and a better workplace.

05 Insider threat detection

Detection of insider activity is among the most difficult challenges in enterprise security — because the activity that matters resembles legitimate activity, because insiders have access, and because the distinction between legitimate and illegitimate use of that access frequently depends on context.

Detection approaches

Detection limitations

Insider detection has inherent limitations that must be understood:

• Legitimate activity and malicious activity look similar. A user accessing data they are authorised to access is not anomalous, even if their motivation is malicious.
• Small volumes are hard to detect. An insider who takes a small amount of data at a time, over a long period, may never exceed the thresholds that trigger alerts.
• False positives are common. Users whose roles involve varied activity generate legitimate anomalies; distinguishing them from malicious anomalies requires investigation.
• Context is essential. The same activity may be legitimate in one context and malicious in another; detection requires understanding context, which is difficult to automate.
• Post-hoc detection is common. Many insider incidents are identified after the fact — through investigation of another incident, through departure, or through external discovery.
• Investigation capability is required. Detection without investigation capability produces alerts that are not acted on; investigation is skilled, time-intensive, and requires legal and HR involvement.

06 Insider threat defence

Insider threat defence combines technical controls, procedural controls, and cultural elements. No single control is sufficient; the combination is what reduces risk to acceptable levels.

The four defensive dimensions

The role of culture

Culture is the least tangible dimension of insider threat defence and frequently the most consequential. Enterprises where employees feel valued, fairly treated, and engaged with the enterprise's mission are substantially less exposed to malicious insider activity than enterprises where employees feel alienated, unfairly treated, or disconnected. And enterprises where employees feel comfortable reporting mistakes and concerns detect insider activity — including negligent incidents — far more effectively than enterprises where such reporting is discouraged.

The culture dimension cannot be produced by technology. It requires investment in the employee experience, in fair and consistent management practices, in grievance mechanisms that employees trust, and in leadership behaviour that models the values the enterprise claims.

The privacy tension

Insider threat programmes sit at the intersection of security and privacy. The controls that are most effective against insider threats — behavioural monitoring, access anomaly detection, data-loss prevention — involve surveillance of employees. The controls that are most protective of employee privacy — minimal monitoring, presumption of innocence, strong access controls without behavioural analytics — leave insider risk less well addressed.

The enterprise must navigate this tension, informed by legal requirements (privacy regulation, employment law, works council agreements in some jurisdictions), by cultural context, and by the enterprise's values. There is no universal answer; different enterprises will reach different balances. The important thing is that the balance is struck deliberately — not by default, and not without consideration of both security and privacy implications.

07 Third-party risk

Every enterprise depends on third parties. The dependencies extend the enterprise's exposure beyond the controls it operates directly — because the security of the enterprise is partly determined by the security of the parties on which it depends.

Categories of third-party dependency

Why third-party risk is increasing

Third-party risk has increased substantially over the past decade for several reasons:

• Specialisation. Enterprises increasingly rely on specialised providers for functions they previously performed in-house — amplifying both the value of the relationship and the consequence of its failure.
• Cloud adoption. Moving workloads to cloud platforms transfers operational responsibility but not accountability; enterprises remain responsible for what they place on the platform.
• Open source dependence. Modern applications are assembled from thousands of open source components, frequently without full visibility into what is used and what risks those components introduce.
• Supply chain attacks. Adversaries have recognised that compromising a supplier provides access to many downstream targets — making third parties a preferred attack path.
• Regulatory scrutiny. Regulators increasingly hold enterprises accountable for the security of their third parties, particularly where personal data is involved.
• Concentration. A small number of providers serve a large proportion of the market; compromise or outage of a major provider affects many enterprises simultaneously.

Managing third-party risk

Managing third-party risk requires extending the enterprise's security governance beyond its own boundaries. The principal activities include:

• Third-party inventory. Knowing which third parties the enterprise depends on — and for what. This is the foundation for everything else.
• Due diligence. Assessing the security posture of third parties before engaging them, and periodically thereafter.
• Contractual controls. Security requirements in contracts — including notification obligations, audit rights, and security standards.
• Architectural containment. Limiting the access that third parties have to enterprise systems, and the impact if that access is misused or compromised.
• Continuous monitoring. Monitoring third parties for changes in security posture, breach notifications, and other risk signals.
• Concentration risk management. Understanding where the enterprise relies on a single provider or a small number of providers, and planning for the consequences of failure.
• Exit planning. Understanding how the enterprise would transition away from each critical third party if the need arose.

08 Software supply chain risk

Software supply chain risk is a specific and increasingly significant category of third-party risk. Modern software is assembled from many components — some developed in-house, most drawn from external sources — and the enterprise's security depends on the security of every component in the chain.

Where software supply chain risk arises

Notable software supply chain attack patterns

• Compromised updates. The adversary compromises the software vendor's development or distribution systems and delivers malicious code through legitimate updates. SolarWinds and NotPetya (Lesson 1.6) are canonical examples.
• Compromised dependencies. The adversary compromises a library or package used by many downstream applications, propagating malicious code through the dependency chain.
• Typosquatting. The adversary publishes malicious packages with names similar to popular legitimate packages, hoping that developers will install the wrong one.
• Dependency confusion. The adversary publishes a package to a public repository with the same name as a private package used internally, exploiting package managers that prefer public sources.
• Maintainer compromise. The adversary compromises the account of a maintainer of a popular open source project, gaining the ability to publish malicious updates.
• Protestware and sabotage. Maintainers who deliberately introduce malicious or destructive code into their own projects, often for political or ideological reasons.
• Development environment compromise. The adversary compromises developer workstations or accounts to gain access to source code, credentials, and build systems.

Visibility and the software bill of materials

A fundamental challenge of software supply chain risk is visibility. The enterprise frequently does not know what components its software uses — because dependencies are transitive (libraries depend on libraries), because components are embedded in commercial software without disclosure, and because the enterprise's own development practices may not track dependencies systematically.

The software bill of materials (SBOM) is the emerging response to this challenge. An SBOM is a machine-readable inventory of the components that make up a software artifact — including their versions, their dependencies, and their provenance. With an SBOM, an enterprise can determine, when a vulnerability is disclosed, whether it is affected — without waiting for the vendor to provide the information.

SBOM adoption is now encouraged or mandated in several jurisdictions, particularly for software supplied to government and critical infrastructure. Adoption remains uneven, and the practical use of SBOMs requires tooling and process investment. But the direction is clear: SBOM is becoming a baseline expectation for software supply chain transparency.

09 Defending the supply chain

Supply chain defence combines governance, assurance, and architecture. No single approach is sufficient; the combination reduces exposure across the multiple dimensions of supply chain risk.

Defensive approaches

The limits of defence

Supply chain defence has inherent limits. The enterprise cannot fully inspect every component of the software it uses; cannot fully audit the security practices of every vendor; cannot eliminate the dependence on cloud providers, libraries, and software vendors whose operations it does not control. Supply chain compromise is not fully preventable.

The appropriate posture is therefore similar to the posture against APTs: assume that supply chain compromise will sometimes occur, and design so that compromise of any single third party does not produce enterprise-wide compromise. Limit third-party access; monitor third-party activity; architect for resilience; prepare for response.

10 Case patterns

The patterns of insider and supply chain incidents recur across enterprises. Several are worth understanding.

Pattern 1 — Departing insider exfiltration

A frequent pattern involves an employee departing to a competitor or to start their own venture, who takes data with them — customer lists, intellectual property, source code. The exfiltration frequently occurs in the period before departure is announced, when the employee's access remains legitimate and their activity does not attract attention.

The pattern illustrates why exit processes — including access review, monitoring for unusual data access, and legal preparation — matter.

Pattern 2 — Negligent disclosure

A single misdirected email, a shared document with the wrong link, a misconfigured cloud storage bucket. The most common form of insider-caused loss involves no malicious intent — just error, compounded by controls that did not prevent the error or detect it.

The pattern illustrates why guardrails, data-loss prevention, and process design matter — and why punishing negligent users is counterproductive.

Pattern 3 — Credential compromise of a trusted user

An external attacker compromises the credentials of a user with legitimate access — frequently through phishing or credential theft — and operates through that user's account. The activity resembles the user's normal activity; detection requires behavioural analytics.

The pattern illustrates why strong authentication, phishing-resistant MFA, and identity monitoring are essential.

Pattern 4 — MSP compromise providing broad access

A managed service provider is compromised, and the attacker uses the MSP's privileged access to reach its customers. The compromise of a single MSP can affect many downstream enterprises.

The pattern illustrates why third-party access requires the same rigour as employee access — least privilege, monitoring, and rapid response.

Pattern 5 — Software update compromise

An adversary compromises a software vendor's build or distribution pipeline, delivering malicious code through legitimate updates. The SolarWinds campaign (Lesson 1.6) is the most significant example, but the pattern is recurring.

The pattern illustrates why build pipeline security, code signing, and architectural containment are essential supply chain controls.

Pattern 6 — Dependency chain compromise

An adversary compromises a library or package used by many downstream applications, propagating malicious code through the dependency chain. The pattern is increasingly common as software supply chains grow more complex.

The pattern illustrates why SBOM, software composition analysis, and dependency monitoring are essential.

Pattern 7 — Contractor access as an unmanaged path

Contractors and temporary staff frequently have access to enterprise systems, but are governed with less rigour than employees. Their access may be excessive, their de-provisioning delayed, their activity unmonitored.

The pattern illustrates why contractor access requires the same governance as employee access — with additional attention to the contractual relationships and the shorter durations of engagement.

Pattern 8 — Supply chain compromise enabling APT objectives

Supply chain compromise is frequently used by APT actors (Lesson 3.6) as a path to their primary targets. Compromising a supplier provides access that bypasses the primary target's controls; the pattern is efficient and effective.

The pattern illustrates why supply chain defence is essential even for enterprises that do not consider themselves primary targets of APT activity — they may be targeted because of their relationships.

11 Common pitfalls

Insider and supply chain defence programmes fail in predictable ways. Recognising the pitfalls accelerates improvement.

Insider threat pitfalls

• Treating all insiders as suspects. Surveillance-oriented approaches undermine the trust and culture on which effective insider defence depends.
• Assuming insiders are only malicious. Negligent insiders are the most common source of insider-caused loss; overlooking them leaves substantial exposure.
• No detection capability. Assuming that because insiders have legitimate access, detection is impossible. Behavioural analytics and data-loss prevention detect what simple access controls cannot.
• No exit processes. Departing employees retain access, and exfiltration frequently occurs before departure is announced.
• Insufficient logging and investigation capability. Detecting insider activity requires comprehensive logging and skilled investigation — often absent.
• Punitive response. Treating insider incidents as user failures produces concealment and undermines the reporting culture.

Supply chain pitfalls

• Incomplete third-party inventory. Not knowing what third parties the enterprise depends on — and for what.
• Superficial due diligence. Assessing third parties on the basis of certifications or questionnaires without meaningful verification.
• Excessive third-party access. Granting third parties broad access on the assumption that the relationship is trusted.
• No monitoring of third-party activity. Third parties with access are not monitored for anomalous activity.
• No SBOM or dependency visibility. Not knowing what components the enterprise's software uses leaves it unable to respond when vulnerabilities are disclosed.
• Assuming vendor certifications guarantee security. Certifications describe practices, not outcomes; a certified vendor can still be compromised.
• Ignoring concentration risk. Not understanding where the enterprise relies on a single provider or a small number of providers.
• No exit planning. Not understanding how the enterprise would transition away from critical third parties if required.

12 Key concepts

The terms below are used throughout Module 2 and Module 3. Capture them in your own words as you work through the lesson.

Insider threat

Risk arising from individuals with legitimate access to enterprise systems, data, or facilities — whose actions, whether deliberate or accidental, cause harm.

Malicious insider

An insider who deliberately causes harm through theft, sabotage, fraud, or provision of access to external actors.

Negligent insider

An insider who unintentionally causes harm through carelessness, error, or lack of awareness. The most common form of insider-caused loss.

Compromised insider

An external actor operating through a legitimate account, having stolen credentials or compromised the user's system.

User and entity behaviour analytics (UEBA)

Establishing behavioural baselines for users and systems and detecting anomalies that suggest malicious activity.

Data-loss prevention (DLP)

Monitoring and controlling the movement of data across enterprise boundaries — email, cloud storage, removable media, print — to detect and prevent exfiltration.

Exit process

The procedures through which an employee's access is removed on departure, and their activity monitored during the departure period. Timeliness is critical.

Separation of duties

The principle that no single individual should be able to complete a sensitive action alone, reducing the consequence of any single individual's action.

Insider risk programme

A structured programme that brings together HR, security, legal, and management to identify and mitigate insider risk, combining multiple signal sources.

Third-party risk

Risk arising from the enterprise's dependence on external parties — cloud providers, software vendors, managed service providers, and business partners.

Supply chain risk

Risk arising from the ecosystem of suppliers, dependencies, and delivery channels on which the enterprise depends. Includes both third-party commercial relationships and software supply chains.

Software supply chain

The ecosystem of components, libraries, build systems, and vendors that produce the software an enterprise uses. A strategic vulnerability because enterprises depend on software they cannot fully inspect.

Software bill of materials (SBOM)

A machine-readable inventory of the components that make up a software artifact, allowing enterprises to identify exposure when a component is later found vulnerable.

Software composition analysis (SCA)

Analysis of applications and their dependencies to identify vulnerable components. Essential where third-party libraries are used at scale.

Build pipeline

The systems that compile, test, and package software. A target of supply chain attacks because compromise allows malicious code to be inserted into legitimate software.

Typosquatting

The practice of publishing malicious packages with names similar to popular legitimate packages, hoping developers will install the wrong one.

Dependency confusion

An attack in which the adversary publishes a package to a public repository with the same name as a private package used internally, exploiting package managers that prefer public sources.

Managed service provider (MSP)

A third party that provides IT, security, or business services to the enterprise, typically with elevated access to enterprise systems. Compromise of an MSP provides broad access to its customers.

Concentration risk

The risk that arises from reliance on a single provider or a small number of providers — whose compromise or outage would affect the enterprise materially.

Architectural containment

The design principle of limiting what any single compromise can reach — through least privilege, segmentation, and monitoring — so that compromise of one party does not produce enterprise-wide compromise.

Provenance

The origin and history of a software artifact — who produced it, from what components, through what processes. Provenance verification reduces supply chain risk.

Code signing

The use of digital signatures to verify the origin and integrity of software. Reduces the risk of tampered or malicious software being deployed.

13 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 2. They are not graded, but completing them will substantially improve your preparation.

14 Self-check

Answer the questions below. Unit 3 is complete after this lesson; if you cannot answer a question confidently, revisit the corresponding section before moving to Unit 4.

15 Summary

This lesson has examined insider threats and supply chain security — two categories that are frequently underestimated because they do not fit the model of an external attacker. It completes Unit 3. The essential points are:

• Insider threats take three forms. Malicious, negligent, and compromised insiders — each requiring different controls. Confusing them produces ineffective defence.
• Insider risk factors are statistical tendencies, not individual predictions. Their appropriate use is to inform supportive interventions, not to identify individuals for surveillance.
• Insider detection is fundamentally difficult. Legitimate and malicious activity look similar; detection requires behavioural analytics, data-loss prevention, integrity monitoring, and skilled investigation.
• Insider defence requires four dimensions. Reduce opportunity; increase detection; reduce motivation; improve response. Culture is the least tangible and frequently most consequential dimension.
• The appropriate posture treats employees as partners, not suspects. Surveillance undermines the trust and culture on which effective insider defence depends.
• Third-party risk is increasing. Specialisation, cloud adoption, open source dependence, and deliberate supply chain attacks have made third parties a preferred attack path.
• Software supply chain risk is a specific and growing category. Libraries, build pipelines, package repositories, update mechanisms, and container images all present supply chain risk. SBOM and software composition analysis provide visibility.
• Supply chain defence combines governance, technical controls, architectural containment, and preparedness. Architectural containment — limiting what any single third party can reach — is the most useful strategic principle.
• Neither category can be fully prevented. The appropriate posture is to limit access, monitor for anomalies, and contain the consequences of any single compromise.
• Common pitfalls recur. Treating insiders as suspects; overlooking negligent insiders; no detection capability; no exit processes; incomplete third-party inventory; superficial due diligence; excessive third-party access; no monitoring; no SBOM; assuming certifications guarantee security; ignoring concentration risk; no exit planning.

Unit 3 is complete. You have examined risk fundamentals, threat modeling, vulnerability assessment, and five specific attack classes — malware and ransomware, social engineering and phishing, advanced persistent threats, and insider and supply chain risk. These constitute the threat picture that Module 2's remaining units will address through architecture (Unit 4) and infrastructure security (Unit 5).