Chapter 12 — Operating systems
Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Service accounts"]
N2["12.2 Logs as platform evidence"]
N3["12.3 Isolating parsers"]
N4["12.4 Patching"]
N5["12.5 Time and scheduling"]
N6["Practice note — Host baselines"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Service accounts"]
N2["12.2 Logs as platform evidence"]
N3["12.3 Isolating parsers"]
N4["12.4 Patching"]
N5["12.5 Time and scheduling"]
N6["Practice note — Host baselines"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX034"]
[Learning outcomes]
|
v
[12.1 Service accounts]
|
v
[12.2 Logs as platform evidence]
|
v
[12.3 Isolating parsers]
|
v
[12.4 Patching]
|
v
[12.5 Time and scheduling]
|
v
[Practice note — Host baselines]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes
You will (1) run intelligence services under least-privilege accounts; (2) use OS logs as evidence of platform behaviour; (3) isolate parsers that handle untrusted input; (4) patch and configure hosts for an always-on platform.
12.1 Service accounts
Lantern's collector runs as a dedicated account with permission only to its working directory and outbound HTTPS to partner servers. It cannot read the firewall configuration it eventually influences; a separate, audited service does that.
If the collector were compromised through a malicious partner file, the attacker would hold an account that can only read its own folder and talk to partner servers. They could not change firewall rules or reach the analysts' reports. Kofi lists each service account with its permissions and reviews the list after every release, removing any right that crept in for a test and was never taken back.
12.2 Logs as platform evidence
Authentication logs, process starts and file modifications show what the platform itself did. When a partner asks whether a TLP:RED report was accessed, the OS and application logs answer.
That question needs logs that were kept, protected from change and synchronised in time. Lantern sends host logs to a separate store where platform administrators can read but not delete them. Kofi tested the answer once by opening a test report and checking that the access appeared within a minute, with the user, the time and the object. A partner who trusts BEN with restricted material may ask for such a check, and BEN should be able to answer it confidently.
12.3 Isolating parsers
Partner files are untrusted input. Parsers run in a container or sandbox with no network access beyond what they need, read-only file systems where possible, and memory limits. A bug in a parser then cannot become a foothold in the SOC.
Kofi tests the sandbox by giving the parser a file that tries to open a network connection and another that tries to write outside its folder. Both attempts fail and are logged. A failed test would block the release until the sandbox is fixed.
12.4 Patching
Platforms facing the internet need prompt patching. A maintenance window, a tested image and a rollback snapshot let BEN patch weekly without long outages.
Kofi's routine applies patches first to a test host that replays a day of synthetic feed traffic. If the pipeline output matches the expected snapshot, the same image goes to production in the weekly window. A snapshot taken just before lets the team return to the previous state within minutes if something breaks. Urgent fixes for actively exploited flaws can skip the weekly wait, with the same test and rollback steps compressed into hours.
12.5 Time and scheduling
Cron or systemd timers schedule polls and decay recalculations. Record timers in configuration management so changes are reviewed.
An unreviewed timer is easy to miss. Kofi once found a decay job set to run every minute after a test, which loaded the database for no reason. Because timers now live in configuration management, such a change shows up in review and in the host baseline. Each timer records its purpose and owner, so nobody has to guess whether it can be removed. Times are set in UTC to avoid surprises when the clocks change.
Practice note — Host baselines
A baseline lists expected processes, open ports and scheduled tasks for each Lantern host. A nightly comparison flags drift: an unexpected listener or a new timer. Baselines are kept in configuration management and reviewed after every approved change so that alerts mean something.
Worked example
A partner archive contains a deliberately malformed file (synthetic test). The parser crashes inside its sandbox; the container restarts; a reject record is written. Nothing else on the host is affected, and the crash appears in logs with the file's hash for the partner.
Synthetic case. The malformed file and sandbox behaviour are invented.
Errors and limits
Running everything as root is fast to deploy and slow to recover from. Sandboxes reduce but do not remove risk.
Exercises
- EX034 — Collector rights. Should the collector account be able to write firewall rules? Explain. Rubric: 3 = no; least privilege/separation; separate audited service; 2 = no; 1 = yes; 0 = none.
- EX035 — Access question. Which evidence answers "who opened the TLP:RED report?" Rubric: 3 = application access logs + OS authentication logs; 2 = one; 1 = ask staff; 0 = none.
- EX036 — Sandbox settings. Name three sandbox settings for a parser of untrusted files. Rubric: 3 = three of no/limited network, read-only FS, memory/CPU limits, unprivileged user; 2 = two; 1 = one; 0 = none.
Synthesis
Least privilege, logs as evidence, sandboxed parsers and disciplined patching keep the platform trustworthy.
Continue studying — chapter 12 of 50
← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →