Secure Architectures and Systems - Systems Security: Core Concepts

class: center, middle

### Secure Computer Architecture and Systems
***
# Systems Security: Core Concepts

---
class: inverse, center, middle

# Introduction & Motivation

---
# Computer Security

- Historically focused on the **physical machine**
  - To prevent theft of or damage to the hardware

--
- Today, the value of data is greater than the value of hardware
    - Computer security therefore now focuses on **information security and availability**
        - Prevent theft of or damage to the information stored/processed/transmitted by the computer
        - Prevent disruption of service

---
# Systems Security

- Practice of safeguarding computer systems against **unauthorised access**, **unauthorised modification**, or **disruption**

.leftlargecol[
Two key components:
1. **Software (SW) security**: protecting applications and systems software against vulnerabilities and their exploitation
2. **Hardware (HW) security**: protecting CPU/memory/devices against attacks

**SW/HW security are heavily intertwined:** SW makes assumptions about HW, controls it; cross-SW/HW attacks
]

.rightsmallcol[
  <div style="text-align:center"><img src="include/sw-hw.svg" width=250 /></div>
]

---
# Why is Systems Security Important?

.leftcol[
- 4th June 1996: first flight of the ESA Ariane 5 rocket
- Goes off track and disintegrates 40 seconds after lift-off
- Root problem: 16-bit signed integer overflow
- Code originally written for Ariane 4, making assumptions that no longer held for Ariane 5
- Code wasn't even doing anything useful after lift-off
- Cost: $370M
]

.rightcol[
  <div style="text-align:center"><img src="include/boom.png" width=450 /></div>

.small[Source: https://www.france24.com/en/live-news/20230705-final-ariane-5-blasts-off-amid-europe-rocket-crisis-1]
]

---
# Why is Systems Security Important?

- Our world is massively computerised, so **cyberattacks have a huge impact:** financial losses, service disruption, privacy breaches, etc.
- Computer systems are **increasing in complexity**, and so are the chances of vulnerabilities
- Threats and attack vectors are evolving

---
name:attack-surface

# Attack Surface

- Computer systems are not perfect and designers may introduce **bugs**
- Some of these bugs are **security vulnerabilities** that can be exploited to mount attacks with various effects
- Vulnerabilities can be present at every level of the SW/HW stack

---
# How to Build Secure Systems?

- When faced with a particular computer systems engineering task, e.g., developing an application, you already know how to:
  - Make it work (**functionality**)
  - Make it fast, memory-efficient, low-power, etc. (**performance**)

--
- Third key objective that cannot be ignored today: how to make it **secure**?
  - Need to **reason about trust** in the target system, **from the ground up**:
      - Identify what (and who) you trust and what you don't trust in the system
      - Protect trusted components/actors from untrusted ones

```python
import sys

if len(sys.argv) != 2:
    sys.exit(f"usage: {sys.argv[0]} <name>")
```

---
class: inverse, center, middle

# Core Concepts

---
# Vulnerabilities

- Software and hardware used in production are increasingly **complex**
  - Linux kernel v7.2 has 30M LoC
  - An Apple Silicon M4 Max SoC has 95B transistors

--
- There is no way to guarantee this software/hardware is entirely correct

--
- In fact, it is likely **not correct**
  - Software/hardware designers and engineers are human: they make mistakes and introduce **bugs**
--

- These bugs have various consequences:
  - Software/hardware instability, crashes
  - **Security vulnerabilities**
      - Bugs mostly silent under normal operation: hard to detect, can remain in the codebase for years
      - When triggered in a certain way, open the system to **attacks**

---
# Attacker's Objectives

An attacker's objectives can include:
- **Read what they are not supposed to read**
  - Sensitive data such as passwords or cryptographic keys, information about the target system (e.g. open ports) to enable further attacks, etc.

--
- **Write what they are not supposed to write**
  - Corrupt sensitive data structures to escalate privileges, inject malicious code and data, forge access tokens, escape detection, etc.

--
- **Control what they are not supposed to control**
  - Disturb operation (denial of service), execute code to enable further attacks, etc.

---
# The CIA Triad

.rightsmallcol[
<div style="text-align:center"><img src="include/cia.svg" width=130 /></div>
]

High-level security properties we want computer systems to maintain:

- **Confidentiality**: prevent unauthorised disclosure of sensitive information
  - E.g. using encryption, access control, secure deletion, etc.
--

- **Integrity**: prevent unauthorised tampering with sensitive information
  - E.g. through checksum verification, digital signatures (keys), etc.

--
- **Availability**: prevent disturbances to the operation of a system
  - E.g. with behavioural monitoring and filtering, redundancy/replication, backups, etc.

---
# The CIA Triad, Identity

.rightsmallcol[
<div style="text-align:center"><img src="include/cia.svg" width=130 /></div>
]

High-level security properties we want computer systems to maintain:

- **Confidentiality**: prevent <u>unauthorised</u> disclosure of sensitive information
  - E.g. using encryption, access control, secure deletion, etc.
- **Integrity**: prevent <u>unauthorised</u> tampering with sensitive information
  - E.g. through checksum verification, digital signatures (keys), etc.
- **Availability**: prevent disturbances to the operation of a system
  - E.g. with behavioural monitoring and filtering, redundancy/replication, backups, etc.
- **Identity**: ensure an actor is who they claim to be (e.g. passwords or certificates)

---
name: trust-model
# Trust Model

- **Trust model:** reasoning about which components of a computer system are trusted vs. untrusted

Example scenario: Infrastructure as a Service (IaaS, renting VMs in the cloud):

---
template: trust-model
<div style="text-align:center"><img src="include/trust-model-1.svg" width=380 /></div>

---
template: trust-model
<div style="text-align:center"><img src="include/trust-model-2.svg" width=380 /></div>

---
template: trust-model
<div style="text-align:center"><img src="include/trust-model-3.svg" width=380 /></div>

---
template: trust-model
<div style="text-align:center"><img src="include/trust-model-4.svg" width=380 /></div>

.center[Trust models vary depending on which actor and scenario are considered]

---
# Trusted Computing Base

- **Trusted Computing Base (TCB):** set of software and hardware components that are critical to the security of the system
  - They are assumed to be working correctly to maintain the target security guarantees
- The TCB should be:
--

1. As **minimal** as possible to make it easier to secure
  2. **Isolated** from non-critical components of the system as they are not trusted
--

- In our IaaS example, from the cloud provider's point of view, the TCB includes the hardware and host systems software (hypervisor, host kernel/firmware/boot process)

---
name: threat-model
# Threat Model

- **Threat model**: set of assumptions about what the attacker can and cannot do

Examples in our IaaS scenario:

---
template: threat-model
<div style="text-align:center"><img src="include/threat-model-1.svg" width=450 /></div>

---
template: threat-model
<div style="text-align:center"><img src="include/threat-model-2.svg" width=450 /></div>

---
template: threat-model
<div style="text-align:center"><img src="include/threat-model-3.svg" width=450 /></div>

---
name:boxes
# Isolation Approaches

Isolating components to enforce the target trust model:

---
template: boxes
<div style="text-align:center"><img src="include/boxes-1.svg" width=800 /></div>

---
template: boxes
<div style="text-align:center"><img src="include/boxes-2.svg" width=800 /></div>

---
template: boxes
<div style="text-align:center"><img src="include/boxes-3.svg" width=800 /></div>

---
## Sandboxing/Safeboxing/Mutual Distrust

- **Examples of sandboxing**:
  - Processes/virtual machines isolated from the rest of the system by an OS/hypervisor
  - Web pages from different sites running in different tabs, isolated by the browser

--
- **Examples of safeboxing**:
  - Cryptographic library isolated within a web browser
  - Isolating code manipulating passwords in a password manager

--
- **Examples of mutual distrust**:
  - Trusted execution environments: enclaves/confidential virtual machines distrust the OS/hypervisor, which in turn distrusts them

---
# Principle of Least Privilege (PoLP)

- **Actors (processes, users, etc.) in a system should only be granted the minimum permissions required to perform their duties correctly**
--

- Limits the damage that can be done to the system should an actor be subverted by an attacker
  - Introduced by Saltzer and Schroeder in their seminal 1975 paper *The Protection of Information in Computer Systems*
--

- It is applied extensively and examples are plentiful:
  - Privilege levels of execution on the CPU
  - Access control: user-based file access permissions, app permissions on mobile systems
  - `sudo` used only for operations requiring root privileges
  - etc.
--

- Hard to apply fully/precisely in practice: for complexity or performance reasons, components often end up **overprivileged**

---
# Wrapping Up

- Computer hardware and systems software **critical** to the security of computer systems
- Vulnerabilities, bugs and attacks
- **Trust and threat models**, trusted computing base
- **Isolation approaches**: sandboxing, safeboxing, mutual distrust
- Principle of least privilege