Logging for security

Topic: Security basics

Log auth events, admin actions, and access to sensitive data so you can detect and investigate incidents. Send logs to a central, protected store; retain per policy and alert on high-risk patterns. Use this when designing or improving security visibility.

Intent: How-to

Quick answer

  • Log authentication (success and failure), privilege changes (sudo, role change), and access to sensitive data (DB, object storage, admin APIs). Include identity, timestamp, action, resource, and outcome.
  • Send logs to a central system (SIEM or log aggregation) so they survive local tampering. Restrict who can delete or alter logs; use separate credentials for the logging pipeline.
  • Retain logs per policy (e.g. 90 days or 1 year). Alert on many failed logins, permission changes, or bulk export; tune to reduce noise and review alerts so they lead to action.

Steps

  1. Decide what to log

    Auth (login, logout, failure), privilege use (sudo, role assume), and sensitive data access. Include who, when, what, which resource, and result. Do not log secrets or full credentials.

  2. Centralize and protect

    Forward logs to a central store. Ensure only the logging system can write; restrict delete and update so a compromised host cannot erase history. Use TLS and auth for the logging channel.

  3. Retain and index

    Retain for the required period (compliance or policy). Index by user, time, resource, action so you can search. Test periodically that you can find a known event.

  4. Alert and review

    Alert on high-risk patterns (many failures, privilege change, bulk access). Tune to avoid alert fatigue; review and update rules; document response for each alert type.

Summary

Log auth, privilege use, and sensitive access; centralize and protect logs; retain and index for search; alert on high-risk events. Use this to build security visibility and support incident response.

Prerequisites

None.

Steps

Step 1: Decide what to log

Log auth (success and failure), privilege use, and sensitive data access. Include identity, time, action, resource; never log secrets.

Step 2: Centralize and protect

Send logs to a central store. Restrict write and delete so logs cannot be tampered with from a single host.

Step 3: Retain and index

Retain per policy; index by user, time, resource. Verify you can find events when needed.

Step 4: Alert and review

Alert on failure spikes, privilege changes, bulk access. Tune and review; document response.

Verification

Relevant events are logged and searchable; logs are centralized and protected; alerts fire and are acted on.

Troubleshooting

Too much data — Sample or filter; keep full detail for auth and privilege; aggregate for high-volume data access. Logs not arriving — Check forwarding, network, and credentials; add health checks for the pipeline.

Next steps

Continue to