◇ OpenCyber Academy
Engineering · Chapter 12 · English

Chapter 12 — Operating systems

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 12 — Operating systems

Lesson map

Lesson 12 published. Map, example, EX034.

flowchart TD
  N0["Learning outcomes"]
  N1["12.1 Processes and permissions"]
  N2["12.2 Hardening"]
  N3["12.3 System logging"]
  N4["12.4 Updates"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX034"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["12.1 Processes and permissions"]
  N2["12.2 Hardening"]
  N3["12.3 System logging"]
  N4["12.4 Updates"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX034"]
[Learning outcomes]
    |
    v
[12.1 Processes and permissions]
    |
    v
[12.2 Hardening]
    |
    v
[12.3 System logging]
    |
    v
[12.4 Updates]
    |
    v
[Worked example] --> [Exercise EX034]

Learning outcomes

You will (1) explain process isolation and permissions; (2) harden operating system configurations; (3) collect useful system logs.

12.1 Processes and permissions

Operating systems run programs as processes owned by user accounts, and permissions decide what each account can read, write or execute. Lindiwe examines a synthetic Saltmarsh file server and finds that a backup service runs as the most powerful account. If the service were compromised, the attacker would gain full control. She recommends a dedicated account with only the rights backups need. Prof. Hale notes that running services with least privilege limits the damage any single flaw can cause. The server team agrees.

12.2 Hardening

Default installations favour convenience. Lindiwe works through a hardening checklist for Saltmarsh's Linux servers: disable remote root login, remove unused services, apply updates within a set period and encrypt disks. She learns that each item reduces attack surface or limits the impact of a stolen device. She also learns that checklists drift: servers configured correctly last year may have changed since, which is why later chapters measure compliance automatically instead of trusting installation records. She records which checklist items each synthetic server already meets and which need work.

12.3 System logging

Operating systems record logins, privilege changes and service failures. Lindiwe configures synthetic servers to forward these logs to a central collector, so an attacker who gains control of a server cannot simply erase local evidence. She chooses events carefully, because logging everything produces noise and cost. Prof. Hale asks her to justify each event type by an investigation question it would answer, such as who used administrator rights on this server last week, which keeps logging purposeful. The collector keeps logs for a year.

12.4 Updates

Operating system updates fix vulnerabilities but can break applications. Saltmarsh delays updates on some servers because a warehouse application once failed after an update. Lindiwe proposes a test group of servers that receives updates first, with automatic promotion to the rest after a week without problems. She learns that reliable update processes are a security control in themselves, because fear of breakage is one of the most common reasons organisations leave known vulnerabilities open for months. The warehouse application owner agrees to join the test group.

Worked example

Lindiwe moves a backup service to a least-privilege account, applies a hardening checklist, forwards purposeful logs centrally and proposes staged updates.

Synthetic case. Servers are synthetic.

Errors and limits

Logs kept only on the server can be erased by an attacker who controls it.

Exercises

Continue studying — lesson 12 (chapter 12 of 50)

← Chapter 11 · Course chapter index · Chapter 13 →

Continue to the next authored lesson.