Chapter 6 — Operating systems and virtualization

Chapter 6 — Operating systems and virtualization

Lesson map

Lesson 06 published. Map, example, EX016.

flowchart TD
  N0["Learning outcomes"]
  N1["6.1 Settings and policies"]
  N2["6.2 Virtualisation and cloud"]
  N3["6.3 Consistency"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX016"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["6.1 Settings and policies"]
  N2["6.2 Virtualisation and cloud"]
  N3["6.3 Consistency"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX016"]

[Learning outcomes]
    |
    v
[6.1 Settings and policies]
    |
    v
[6.2 Virtualisation and cloud]
    |
    v
[6.3 Consistency]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX016]

Learning outcomes

You will (1) relate operating system settings to Riverton's policies; (2) understand virtual machines and cloud hosting; (3) check configuration consistency across clinics.

6.1 Settings and policies

Riverton's policy requires screen locks, automatic updates, encryption and no local administrator rights on reception computers. Priya learns how each requirement maps to operating system settings managed centrally through device management. She also learns that imaging devices often run older operating systems that suppliers control, so they cannot follow the same settings. These exceptions need separate treatment, such as network isolation, recorded in the risk register. Isolating imaging devices on their own segment lets them keep supplier-controlled software while limiting what can reach them.

6.2 Virtualisation and cloud

The practice management system runs on virtual machines hosted by a cloud provider. Priya learns that virtualisation lets many systems share hardware, while the provider manages the physical layer. Governance must therefore define which security tasks belong to the provider and which belong to Riverton. Under a shared responsibility model, the provider secures the infrastructure, while Riverton controls user access and configuration. She notes that misunderstandings about this division are common sources of gaps. User access to the practice system, for example, stays Riverton's job even though the provider runs the servers.

6.3 Consistency

Priya compares settings across fourteen clinics using the device management report. Eleven clinics match the baseline. Three have reception computers with screen locks disabled because staff found them inconvenient at busy times. She suggests a longer timeout with a quick unlock method rather than no lock at all. She learns that inconsistency often reflects real usability problems, and that adjusting the control can achieve compliance without fighting clinic staff. A longer timeout with quick unlock keeps a lock in place in the three busy clinics instead of none at all.

Worked example

Priya maps policy to settings, isolates supplier-managed imaging devices, clarifies cloud responsibilities and fixes screen lock inconsistencies with a usable compromise.

Synthetic case. Settings and clinics are synthetic.

Errors and limits

Reports may lag reality. Shared responsibility terms vary by provider.

Exercises

• EX016 — Imaging exception. How should imaging devices on old operating systems be treated? Rubric: 3 = network isolation recorded in the risk register;; 2 = isolation;; 1 = vague;; 0 = none.
• EX017 — Provider duty. Under shared responsibility, what does Riverton control? Rubric: 3 = user access and configuration;; 2 = access;; 1 = infrastructure;; 0 = none.
• EX018 — Screen lock fix. What did Priya suggest instead of disabled screen locks? Rubric: 3 = longer timeout with quick unlock;; 2 = usable compromise;; 1 = vague;; 0 = none.

Synthesis

Settings enforce policy, but exceptions and shared responsibilities need explicit governance.

Continue studying — chapter 06 of 30

← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →