Security auditing — what to record, and what kind of number it is

Same data, different tense

The rule that keeps this lesson apart from the intrusion-detection module: auditing is the collection, storage and analysis of security data; intrusion detection is the real-time use of the same data. One is retrospective and evidential, the other is immediate and operational, and they read the same records. If you can say that sentence you will not confuse the two under exam pressure.

A security audit is an independent examination of records and activities. It has four aims — judge whether the controls are adequate, confirm compliance with policy and procedure, detect breaches, and recommend changes — and one basic objective: accountability. Everything else in the chapter serves that word.

A security audit trail is a chronological record, kept in sufficient detail to reconstruct the sequence of events surrounding a security-relevant operation, from inception to final result. The phrase from inception to final result is the design requirement: a log that records only the outcome cannot reconstruct anything.

Four categories of trail

System-level — logins, device usage, operating-system events, changes to system configuration. Application-level — what happened inside one application, in that application's own vocabulary, which is often the only place a business-meaningful event exists at all. User-level — the commands a specific user issued, the identifications and authentications they attempted, the files they touched. Physical access — card readers, doors, alarm systems. That fourth one is regularly forgotten, and it is the one that answers was that person even in the building?

A design point that surprises people: collection is not limited to events that trigger alarms. Normal conditions may need auditing too, because behaviour that triggers nothing is precisely what defines normal for later comparison. An audit trail that records only exceptions can never establish a baseline.

The audit and alarms model

The reference model is a data-flow chain, and the exam can ask you to place any stage in it:

event discriminator → audit recorder → audit trail → audit analyzer → audit archiver → archives

with an alarm processor hanging off the analyzer, plus an audit provider, an audit examiner, and reports. Two details carry the marks. First, the alarm processor's own actions are themselves auditable and are fed back into the recorder — the audit system audits itself, which is exactly why clearing the audit log is itself an audited event. Second, the trail has two protection duties: integrity, because an intruder's first instinct is to remove the evidence, met by digital signatures or write-once media; and confidentiality, because trails hold sensitive personal data and are therefore a target in their own right, met by encryption. And the audit function must protect itself, not merely its trail — an analyzer an attacker can silence is no better than no analyzer.

What kind of number is it? The four metric types

When you decide what to record, you are also deciding what kind of quantity each metric is, and there is a four-way vocabulary for that. This taxonomy is EXT — see the warning below — but it is examined, so learn it.

• A counter only ever climbs: it is a whole number that increments and never falls back until something explicitly clears it. Logins by one user in an hour; executions of a given command.
• A gauge reports a level at an instant, and a level can fall as well as rise. Connections currently held open by an application; messages currently waiting in a process's outbound queue.
• An interval timer is the length of time between two related events — for instance between successive logins to an account.
• Resource utilization is the quantity of a resource consumed during a specified period — pages printed, total execution time, records read.

The entire discrimination the exam turns on is counter versus gauge, and there is exactly one test: can the number go down? A counter only ever goes up. A gauge measures a level, and a level moves both ways. Number of messages queued is a level, not a tally — that is the tell, and it is the tell in the sample paper's own example.

Watch for the neighbouring confusion too. These four are metric types. The model types from the same older literature — operational, mean-and-standard-deviation, multivariate, Markov process, time series — are a different list answering a different question, and only some of them survive into the current edition's treatment of anomaly detection.

Implementation guidance, and syslog

Three rules constrain how audit work is actually done. Audit tests must be limited to read-only access to production data. Anything not read-only runs on isolated copies, erased afterwards. And tests that could affect availability run outside business hours.

syslog is the UNIX logging facility and it has four parts worth naming: the syslog() API that a program calls, the logger command that lets a shell script log, the configuration file /etc/syslog.conf that says where messages go, and the syslogd daemon that routes them.

A syslog message is [PRI][HEADER][MSG]. PRI encodes the facility (which subsystem produced it) and the severity; the arithmetic is PRI = facility × 8 + severity, which is why a single small integer carries both. HEADER carries a timestamp and the hostname. MSG splits into a TAG — the name of the generating program — and the CONTENT. The severity scale runs most severe first: emerg → alert → crit → err → warning → notice → info → debug.

One operational trap worth knowing: rate limiting protects the syslog server by dropping exactly the messages you most want, because a flood of messages is the characteristic output of an adverse event. Rate limiting is correct and it is also how you lose the record of the incident.

Analysis, and what a SIEM adds

Analysis comes in three timings: after the event (forensic), periodic (scheduled review), and real-time — which is intrusion detection. The techniques are basic alerting, baselining (with thresholding and windowing as its sub-techniques), and correlation.

Keep two terms apart: audit review is a human reading selected records; audit analysis is data reduction and tooling applied to the whole trail. They are a direct exam pair.

SIEM — security information and event management — centralises collection from many sources, normalises the formats, and correlates across them. What it adds is the thing a single log cannot show by construction: a pattern whose evidence is distributed across sources. Configurations come in two shapes: agentless, where the raw logs are shipped and normalisation happens on the SIEM server; and agent-based, where normalisation happens on the monitored host before shipping, which costs host resources and saves network bandwidth.

Worked example — the audit trail for Coldstream's records service

Design it in four questions.

Which events? At application level: every read of a student record (who, which record, which field group), every amendment with the before and after values, every export, every permission grant. At system level: authentication successes and failures, privilege escalations, service restarts, configuration changes. At user level: administrator command history. At physical access level: card events on the basement records room. Include the normal reads, not only the refusals — without them there is no baseline, and this account read four thousand records in an hour is only alarming against a norm.

What does a record contain? Timestamp from a synchronised clock, the subject (user and process), the object, the action, the outcome, and the source address. From inception to final result: an amendment record that omits the prior value cannot reconstruct anything.

Where is it stored, and how is it protected from the administrator it audits? Shipped off the host in near real time to a collector the records administrators cannot write to, signed or written to append-only storage for integrity, and encrypted at rest for confidentiality, because the trail itself is a register of who accessed whose personal data.

What kind of number is each metric? Records read by this account this hour — a counter. Concurrent sessions currently open on the records service — a gauge; it falls when people log out. Time between successive administrator logins — an interval timer. Total CPU seconds consumed by the export job this week — resource utilization. Then the SIEM correlation that no single log could produce: a card-reader event placing an administrator outside the building at the same minute as an interactive login using their account. Neither log is remarkable alone. Together they are the incident.