◇ 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 What an OS does"]
  N2["12.2 Windows events"]
  N3["12.3 Linux logs"]
  N4["12.4 Users and privilege"]
  N5["12.5 Services and scheduled tasks"]
  N6["12.6 Configuration as coverage"]
  N7["12.7 Log size and rotation"]
  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 What an OS does"]
  N2["12.2 Windows events"]
  N3["12.3 Linux logs"]
  N4["12.4 Users and privilege"]
  N5["12.5 Services and scheduled tasks"]
  N6["12.6 Configuration as coverage"]
  N7["12.7 Log size and rotation"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX034"]

[Learning outcomes]
    |
    v
[12.1 What an OS does]
    |
    v
[12.2 Windows events]
    |
    v
[12.3 Linux logs]
    |
    v
[12.4 Users and privilege]
    |
    v
[12.5 Services and scheduled tasks]
    |
    v
[12.6 Configuration as coverage]
    |
    v
[12.7 Log size and rotation]
    |
    v
[Worked example] --> [Exercise EX034]

Learning outcomes

You will (1) explain how operating systems manage processes, files, users and logs; (2) locate key security events on Windows and Linux; (3) relate OS audit settings to detection coverage; (4) recognise how configuration changes telemetry.

12.1 What an OS does

The operating system schedules processes, manages memory, controls access to files and devices, and authenticates users. Every one of these functions can produce security events if auditing is enabled.

Auditing turns these background functions into records: a process starting, a file opened, a user signing in. Most systems ship with only part of this enabled, because full auditing produces large volumes and some performance cost. Choosing which functions to audit is therefore a design decision tied to the detections the SOC intends to run.

12.2 Windows events

Windows records logons, process creation, service installation and policy changes in its event logs when audit policy enables them. Process creation with command line, for example, must be switched on deliberately; without it, many endpoint detections have nothing to match.

A default installation may record that a process started but not the command line it was given, which is where much of the useful detail lives. Group Policy lets administrators enable auditing consistently across many machines. Amara checks a sample of portal servers and finds the command-line setting is not applied uniformly, a gap her coverage table later traces to an older build template.

12.3 Linux logs

Linux systems record authentication in system logs, and the audit subsystem can record file access and program execution according to rules. Like Windows, coverage depends on configuration.

Authentication messages land in files such as the system's auth log or in the systemd journal, depending on the distribution. The audit subsystem uses rules that name what to watch, for example execution of any program by a web service account. Each rule adds volume, so rules are written for specific risks rather than recording everything the system does.

12.4 Users and privilege

Operating systems separate normal users from administrators. Events that change privilege — adding a user to an administrators group, for instance — are high-value signals for detection.

Attackers who gain a foothold usually want more rights, so changes in group membership often appear early in an intrusion. Such changes are also rare in normal operations, which makes them good detection candidates with few false positives. Legitimate changes still occur, so alerts are checked against the change-management record for an approved request. Removals from privileged groups are logged too.

12.5 Services and scheduled tasks

Programs can be set to start automatically. New services and scheduled tasks are common persistence mechanisms described in MITRE ATT&CK, so their creation is worth logging.

Persistence lets an attacker's program survive a reboot or a user logging out. Legitimate software also installs services, especially during updates, so a raw alert on every new service would be noisy. Detections narrow it down, for example to services running from user-writable folders or tasks created by unusual parent processes, and analysts compare against known software deployments.

12.6 Configuration as coverage

Detection coverage is only as good as audit configuration. Amara builds a table listing each detection rule and the OS setting it depends on, then checks that the settings are deployed by policy on every server class.

The table reveals gaps that rule testing alone would miss: a rule can pass its tests in the lab yet never fire in production because the event it needs is not generated there. Amara's check finds that one server class records process creation without the command line. Fixing the policy restores coverage for several rules at once, and the table is rechecked after every build change.

12.7 Log size and rotation

Event logs have maximum sizes; when full, old events are overwritten. Forwarding logs to the SIEM promptly prevents loss.

On a busy server, a small event log can wrap in hours, so evidence of an attack in the morning may be gone by the afternoon. Attackers sometimes generate noise deliberately to push older entries out. Forwarding events to the SIEM within seconds keeps a copy outside the host, and alerts on forwarding gaps show when a server stops sending. Log size settings are part of the build standard.

Worked example

Amara's table reveals that the portal web servers lack command-line logging for process creation because they were built from an older template. Three detection rules therefore could never fire on those servers. Paolo raises a change to update the template and verifies afterwards with a harmless test process.

Synthetic case. Servers, templates and rules are invented.

Errors and limits

Enabling more auditing increases volume and cost; enable what detections and investigations need.

Exercises

Synthesis

Operating systems produce rich security events only when configured to; mapping rules to settings reveals blind spots.

Continue studying — chapter 12 of 50

← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →