Security Risk
Part Of
Reduced By Practices
- Issue Management: Track and Prioritise Security Issues and Incidents.
- Monitoring: Monitors for security breaches and anomalies.
- Redundancy: Enhances security by providing alternative paths and systems.
- Security Testing: Identifies and addresses vulnerabilities in the software.
- Training: Educates team members on security protocols and practices.
Attendant To Practices
- Automation: Automation can introduce security issues if automated processes are given elevated privileges.
- Delegation: Delegating responsibility can introduce new security risks.
- Outsourcing: Sharing responsibilities across multiple organisations can introduce new security risks.
Security Risk is a subset of Operational Risk looking at dangers to the operation due to hostile agents (bad actors) or events occurring.
As we already discussed in Agency Risk, within a system we may wish to prevent our agents from causing accidental (or deliberate) harm, but we also have Agency Risk from unwanted agents outside the system. So security is also about ensuring that the environment we work in is safe for the good actors to operate in while keeping out the bad actors.
Interestingly, security is handled in very similar ways in all kinds of systems, whether biological, human or institutional:
- Walls: defences around the system, to protect its parts from the external environment.
- Doors: ways to get in and out of the system, possibly with locks.
- Guards: to make sure only the right things go in and out. (i.e. to try and keep out bad actors).
- Police: to defend from within the system against internal Agency Risk.
- Subterfuge: hiding, camouflage, disguises, pretending to be something else.
These work at various levels in our own bodies: our cells have cell walls around them, and cell membranes that act as the guards to allow things in and out. Our bodies have skin to keep the world out, and we have mouths, eyes, pores and so on to allow things in and out. We have an immune system to act as the police.
Our societies work in similar ways: in medieval times, a city would have walls, guards and gates to keep out intruders. Nowadays, we have customs control, borders and passports.
We're waking up to the realisation that our software systems need to work the same way: we have Firewalls and we lock down ports on servers to ensure there are the minimum number of doors to guard, we police the servers with monitoring tools, and we guard access using passwords and other identification approaches.
Worked Example
For a firm wanting to strengthen its security posture, there is almost an unlimited variety of third party tools and services they can turn to to help them. The choice is bewildering and it's often hard to separate out the genuinely useful from the distractions.
In the diagram above, a firm decides to address security risk with training, multi-factor authentication schemes, endpoint detection and response (EDR) and encrypting it's data. In many scenarios, these are all good practices if implemented correctly. However, Agency Risk and Security Risk thrive on complexity: the more complex the systems we create, the more opportunities there are for bad actors to insert themselves and extract their own value. The dilemma is, increasing security also means increasing Complexity Risk, because secure systems are necessarily more complex than insecure ones.
CrowdStrike's Falcon tool is an Endpoint Detection and Response (EDR) tool designed to detect attacks aimed at compromising staff's personal computers, such as ransomware, Advanced Persistent Threats and Zero-Day Exploits. As more and more staff moved outside of corporate firewalls during the COVID-19 pandemic, tools like this were seen as more and more valuable.
However, what clients of CrowdStrike were unware of was the company's extremely lax approach to quality assurance of its product - they pushed code out to computers around the world without any rigorous testing, which was a disaster waiting to happen. In July 2024 a CrowdStrike release caused widespread sytems crashes and a global IT outage as Windows PC's rebooted over and over again, unable to start properly.
It is estimated that Fortune 500 companies suffered $5.4bn of losses due to the outage.
Regulation and Compliance
Example Threats
1. Cybersecurity Threats
Some examples include malware, phishing, Zero-Day Exploits and Distributed Denial of Service (DDos) attacks.
See: Mitre Att&ck is a database of Cyber-Security Risk threats, broken down into:
- Tactics: the reasons why an adversary is performing an action.
- Techniques: how the adversary will attack.
- Defences: things you can do to defend against adversaries.
2. Physical Security Threats
Threat: External actors engaged in unauthorized access, theft or vandalism.
Threat: Natural disasters such as fires, floods or earthquakes.
3. Personnel-Based Threats
Threat: Insider attacks (see Agency Risk for more examples.
Threat: Social engineering - persuading employees to reveal sensitive information or grant elevated access.
4. Software Supply Chain Threats
Threat: The software supply chain - malware can be embedded in third-party components.
Examples of Common Supply Chain Attacks
Attack Name | Description | Example |
---|---|---|
Dependency/Manifest Confusion | An attacker publishes a package with the same name as a private package used by a specific company but in a public repository. If the company's build system is not properly configured, it may pull the malicious public package instead of the intended private one. | Alex Birsan |
Package Stealing/Hijacking | Attackers can sometimes take over abandoned or poorly maintained packages and introduce malicious changes. They then publish the updated malicious version, and dependent systems automatically pull in these updates. | us-parser-js |
Malicious Forks/Masquerading | An attacker might create a fork of a popular open-source project, introduce malicious changes, and then attempt to promote or advertise this fork to unsuspecting users. | Stephen Lacy |
RepoJacking | An attack where a malicious actor registers a username and creates a repository used by an organization in the past but which has since changed its name. Doing so results in any project or code that relies on the dependencies of the attacked project to fetch dependencies and code from the attacker-controlled repository, which could contain malware. | CTX |
Piggybacking on Legitimate Packages/Pull Request Sneaking | Some attackers contribute malicious code to popular and legitimate projects, usually through pull requests. If not thoroughly reviewed, the malicious code might get merged into the main project. | Teleport |
Download Count Inflation/Star Jacking | To make a malicious package look popular and trustworthy, attackers artificially inflate the download count. | Pampyio |
Trojan Package | In the trojan package infection method, the attacker publishes a fully functional library but hides malicious code in it. | lemaaa |
Joke Packages | Not strictly an attack, but publishing packages as jokes. Can harm the supply chain and cause dependency bloat. | true |
Cache Poisoning | Exploiting weaknesses in parameter handling by package managers. | Rack |
TypoSquatting | Typosquatting is the practice of obtaining (or squatting) a famous name with a slight typographical error. | "Amzon.com" |
See: JFrog Blog on Infection Methods
5. Hardware Supply Chain Threats
Threat: Malicious modifications to hardware components.
See:
6. Emerging Technology Risks
Threat: Internet-of-Things (IOT) smart devices get exploited (e.g. baby monitors, thermostats).
Threat: AI tools generating personalised phishing emails, deepfakes, spam.
Threat: Eventually, quantum computing may pose a threat to existing encryption algorithms.