Skip to content
BoKSA

4 — Accountability and logging

4 — Accountability and logging

Study time: ± 45 minutes

Actions leave a trace

Accountability means actions can be traced back to a responsible identity. Note the chain: a log entry is only worth something if the identity behind it was properly authenticated — weak authentication makes your logs point at the wrong person. Accountability is the goal; logs are the evidence; cryptography (digital signatures) is what makes actions non-repudiable — impossible to deny afterwards.

Three building blocks:

  1. Audit policy — decide beforehand what to log. Log too little and you are blind when something happens; log everything and you drown in noise (and storage costs). Start from questions you will need answered: who logged in and when, who touched which sensitive record, what failed.
  2. Protect the evidence. The first thing an intruder does is delete their tracks. Logs must therefore live where a compromised system cannot reach them: forwarded immediately to a separate log server, or stored append-only. The place where the evidence lives must not be the place the attacker just conquered.
  3. Actually analyse. A log nobody reads proves nothing and detects nothing. Reading, correlating and alerting on logs at organisational scale is exactly what a SOC does with a SIEM — the subject of the Security Operations topics (BOKSA 8.x), which build directly on this foundation.

The privacy tension

Everything you record about attackers, you also record about your own legitimate users. More logging means more surveillance, and under the GDPR that has limits: log what you need for security, minimise personal data in log lines, and be able to explain why each field is there. CyBOK's example of the balance: a company gateway that logs only internal IP + port number against the external address — enough to trace an incident back to a user when an external report comes in, without continuously recording everyone's browsing behaviour.

Core resources

  • OWASP Logging Cheat Sheet — what to log (authentication successes and failures, access-control denials), what never to log (passwords, session tokens), and how to keep log data safe. (± 30 min)
  • Reference: CyBOK KA 14, accountability section (see Start here) — including the deeper techniques (hash chains, WORM storage) if you want to go beyond the required level.

Check yourself

  1. An attacker breaks into a web server and deletes the local log files. Name two measures that would have preserved the evidence anyway.
  2. Your teammate proposes logging the full URL of every page every employee visits, "for security". Give one security argument for and one privacy argument against, and propose a middle ground.
  3. Why does weak authentication undermine accountability, even if your logging is perfect?