CyberForte
0/32 guides done, see your progress

Home Secure by Design and Default Playbook 10

Playbook 10 of 22 · Secure by Design · Operational Integrity

Logging, monitoring and alerting

Keep a diary of what matters, keep it safe, and get a tap on the shoulder when something looks wrong.

Operational IntegritySecure by DesignENISA suggests: early baseline
CyberForte's summary · not ENISA text

In plain words

If you cannot see it, you cannot stop it or explain it later. This playbook asks for a small set of high-value security logs: logins, failed logins, admin actions, permission changes, updates and configuration changes.

Send those logs to one central place, protect them from tampering, keep them for a set time and make sure all clocks agree. Then start with a handful of alerts that really matter, give each one an owner, and practise what you would do when one goes off.

Picture this: Ten failed admin logins in a minute, followed by a new admin account, is worth a phone call. A thousand routine messages a minute is not.

Your turn

Practical checklist

A short, practical version for small teams, written by CyberForte from the ENISA playbook. The full ENISA checklist, evidence list and release gate are in the original text below. Your ticks are saved only in this browser.

Original text · unchanged

The full ENISA playbook

Source: ENISA Secure by Design and Default Playbooks, 10-logging-monitoring-and-alerting.md, European Union Agency for Cybersecurity (ENISA), licensed under CC BY 4.0. Reproduced word for word; only converted from Markdown to this page.

Logging, monitoring and alerting

Principle

(secure by design)

Systems should generate appropriate security-relevant logs, retain them for a defined period and protect them from tampering, so that they can support investigation and compliance needs.

Objective

Provide sufficient visibility to detect misuse, investigate incidents and maintain system integrity over time. The focus is on a small set of high-signal security events, reliable log retention and actionable alerts that do not overwhelm teams.

Checklist

Define the “must-log” security events

  • Authentication: login success/failure; MFA events; token issuance/refresh/revocation.
  • Authorisation: access denied, privilege or role changes, admin actions.
  • Boundary events: external API calls, device onboarding or pairing, OTA/update events.
  • Data or security changes: configuration changes, key or secret changes, user or service enabled or disabled.
  • Do not log personal or secret data by default. In general, log only the bare minimum required to understand events in default log level

Standardise access and audit log structure and attribution

  • For access and authorisation logging, use consistent fields capturing who (actor), what (action or event type) and when (timestamp), with additional contextual fields as appropriate.
  • Ensure that admin actions are attributable to a named identity (no shared accounts).

Centralise collection and protect log integrity

  • Central log store (SIEM/log platform or managed logging).
  • Separate logs based on type and/or service.
  • Restrict access to logs; separate duties and apply write-only permissions where feasible.
  • Set retention targets (e.g. 30 days or 90 days, longer for archival material if required). Plan storage accordingly.
  • Ensure time sync (NTP) across systems.

Implement actionable monitoring and alerts

  • Start with a small alert set (high confidence, high impact): repeated auth failures, new admin creation, privilege escalation, unusual API error spikes, updates failing, disabled logging, access to sensitive endpoints from new locations.
  • Tune alerts to reduce noise (rate thresholds, suppression windows, environment filters).

Practice incident triage and response

  • Define on-call duties / ownership for security alerts.
  • Document a minimal triage playbook covering: validate, scope, contain, remediate and communicate.
  • Carry out a quarterly tabletop exercise or dry run for one common scenario (account takeover or API key leak).

Minimum evidence

  • Logging baseline: list of must-log events and required fields (one page)
  • Central logging proof: screenshot/export/config showing logs from key components arriving centrally
  • Retention setting: configured retention is in place and there is an access-control policy for logs
  • Alert catalogue: list of enabled alerts with thresholds and owners (initial set can consist of around 5 to 10 alerts)
  • Triage runbook: one-page steps and escalation contacts, plus one recent test (tabletop note)

Release gate

  • [ ] Must-log security events implemented for new/changed components (auth, admin, updates, boundary events)
  • [ ] Logs include attribution fields (actor, request/session ID, source) and are centralised
  • [ ] Log access restricted, retention configured, time sync verified
  • [ ] High-signal alerts enabled and assigned an owner (at least brute force events, new admin / role change, key/secret change, update failures)
  • [ ] Triage runbook exists and has been tested recently (tabletop exercise or test alert)
  • [ ] Logging/alerting exceptions are documented, with owner and review/expiry date
↑ ↓ to moveEnter to openEsc to close