Chapter 11 — Operating systems

Chapter 11 — Operating systems

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Settings and policy"]
  N2["11.2 Baseline check"]
  N3["11.3 Updates as a process"]
  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 Settings and policy"]
  N2["11.2 Baseline check"]
  N3["11.3 Updates as a process"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX031"]

[Learning outcomes]
    |
    v
[11.1 Settings and policy]
    |
    v
[11.2 Baseline check]
    |
    v
[11.3 Updates as a process]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) relate operating system settings to policy; (2) check laptops against a simple baseline; (3) plan updates as a governed process.

11.1 Settings and policy

Elmfield's policy says laptops must be encrypted, lock after a few minutes idle, receive updates automatically and give staff no administrator rights. Sofia learns that each statement corresponds to operating system settings. Encryption is a disk setting, screen lock is a power and security setting, updates are managed by the update service and administrator rights depend on group membership. Linking policy statements to settings is what makes a policy enforceable and checkable rather than a wish. The administrator rights statement, for example, can be checked by reading group membership on each laptop.

11.2 Baseline check

Sofia uses the device management console to export settings for one hundred and twenty laptops and compares them with the policy baseline. Most comply, but nine lack encryption, all repairs team laptops bought locally, and fourteen users still have administrator rights granted for old software. She lists each with its owner. She learns that baseline checks reveal not only technical gaps but process gaps, such as devices bought outside the normal route, which explain why the technical gaps arose. Dr. Haddad asks the class who should own the fix for the nine repairs laptops, given that they were bought outside the normal route.

11.3 Updates as a process

Updates fix vulnerabilities but can break software. Elmfield needs a governed process: test updates on a few devices, deploy to everyone within a set time and track exceptions. Sofia drafts the process with the IT lead, setting thirty days for critical updates. She learns that update policy is a balance between speed and stability, and that writing down the target and measuring against it lets Elmfield see whether its practice matches its intention. Thirty days for critical updates becomes the target that Sofia later measures in chapter 15.

Worked example

Sofia links policy to settings, finds nine unencrypted laptops and fourteen administrators and drafts an update process.

Synthetic case. Laptop counts are synthetic.

Errors and limits

Console exports miss unmanaged devices. Update targets need exceptions.

Exercises

• EX031 — Policy to setting. Which setting enforces the no-admin rule? Rubric: 3 = group membership;; 2 = groups;; 1 = vague;; 0 = none.
• EX032 — Root cause. Why did nine laptops lack encryption? Rubric: 3 = bought locally outside the normal route;; 2 = procurement;; 1 = vague;; 0 = none.
• EX033 — Update target. What target did Sofia set for critical updates? Rubric: 3 = thirty days;; 2 = 30;; 1 = vague;; 0 = none.

Synthesis

Policies become enforceable when linked to operating system settings and measured processes.

Continue studying — chapter 11 of 40

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