Chapter 11 — Operating systems

Chapter 11 — Operating systems

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Accounts and permissions"]
  N2["11.2 Baselines"]
  N3["11.3 Updates"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 Accounts and permissions"]
  N2["11.2 Baselines"]
  N3["11.3 Updates"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX031"]

[Learning outcomes]
    |
    v
[11.1 Accounts and permissions]
    |
    v
[11.2 Baselines]
    |
    v
[11.3 Updates]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) compare account and permission models on Windows and Linux; (2) harden laptops and servers with baselines; (3) manage updates in a small organisation.

11.1 Accounts and permissions

Lucas studies how Windows and Linux control access. Both have users and groups; both distinguish administrators from ordinary users. At Fernway, every store laptop user is a local administrator, a convenience that lets any malware run with full rights. Hannah agrees to remove local administrator rights and provide a request process for software installation. Lucas also reviews a Linux server where several staff share the root password. He recommends individual accounts with elevated rights through logged commands, so actions can be attributed to people.

11.2 Baselines

A baseline is a documented set of secure settings. For laptops, Lucas proposes full-disk encryption, automatic screen lock, a host firewall, removal of unused software and standard user accounts. For servers, he proposes disabling unused services, key-based administrator login with multi-factor authentication and centralised logging. He maps the baseline to SP 800-53 Rev. 5 control families such as configuration management and access control, so Fernway can show auditors what it does. Applying a baseline consistently removes many easy footholds attackers rely on.

11.3 Updates

Unpatched software is a frequent entry point. Fernway's laptops update automatically, but tills run an old operating system version that the vendor still supports only with paid updates, and the warehouse scanners have never been updated. Lucas proposes an update policy: automatic updates where possible, a monthly window for servers, vendor contracts covering tills and a replacement plan for scanners. Each exception is recorded with an owner and a review date. He notes that the hardest updates are those for devices nobody thinks of as computers.

Worked example

Lucas removes local administrator rights, replaces a shared root password with individual accounts, proposes laptop and server baselines and writes an update policy with exceptions.

Synthetic case. Devices, versions and policies are synthetic; SP 800-53 Rev. 5 is real.

Errors and limits

Removing admin rights increases support requests at first. Some vendor devices cannot be updated without breaking warranties.

Exercises

• EX031 — Local admin risk. Why is local administrator for every user risky? Rubric: 3 = malware runs with full rights;; 2 = full rights;; 1 = vague;; 0 = none.
• EX032 — Shared root fix. What replaces the shared root password? Rubric: 3 = individual accounts with logged elevation;; 2 = individual;; 1 = new shared password;; 0 = none.
• EX033 — Hardest updates. Which updates does Lucas call hardest? Rubric: 3 = those for devices nobody thinks of as computers, like scanners and tills;; 2 = devices;; 1 = laptops;; 0 = none.

Synthesis

Operating-system security rests on individual accounts, consistent baselines and an update policy that includes forgotten devices.

Continue studying — chapter 11 of 40

← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →