February 26, 2024

Understanding Auditing and Accountability

By Matt James / 4 min read

Logs are everywhere. Whether they actually serve you depends on whether anyone designed them to.

Most organizations treat logging as an afterthought, something the platform does automatically, something that sits in a folder until an incident forces someone to go look. That instinct is expensive. Auditing and accountability are not about accumulating data. They are about having the right data, protected, when you need it most: for a forensic investigation, a compliance audit, a breach notification, or simply proving that what you said happened actually happened.

What auditing is actually for

In a traditional physical infrastructure environment, logs track the things that matter: login attempts, file access, configuration changes, network traffic. Done right, this creates a timeline you can reconstruct. Done poorly, the logs exist but prove nothing, because nobody protected them, nobody reviewed them, and the attacker who pivoted through your network deleted them three hours before you noticed.

Three disciplines hold physical auditing together. Log integrity means logs have to be tamper-proof and stored somewhere an attacker cannot reach after compromising the system they describe. Access controls means the set of people who can view, modify, or delete log files should be small, deliberate, and itself audited. And regular review means logs that are never read are just storage costs. Periodic human or automated review is what turns a log into an early-warning system.

None of this is exotic. NIST SP 800-92 has been the reference standard for computer security log management for years, and the OWASP Logging Cheat Sheet covers the implementation specifics in practical terms. The gap is rarely knowledge. It is prioritization.

The cloud complicates everything

Cloud environments introduce the same requirements under more complicated conditions. The shared responsibility model is the first thing to understand clearly: your cloud provider secures the infrastructure, but what you log, where you store it, and who can access it is your problem. SaaS, PaaS, and IaaS each carve the boundary differently, and assuming your provider handles logging on your behalf is one of the more common and consequential mistakes in cloud security posture.

Multi-tenancy adds another wrinkle. In shared environments, log isolation matters both for preventing data leakage and for ensuring that one tenant's audit trail cannot be poisoned by another's activity. The Cloud Security Alliance Security Guidance v4 addresses this in detail, and it is worth reading before you design a logging architecture for anything sensitive.

Dynamic infrastructure is the hardest part to get right. Cloud resources spin up and down on demand. If you are not capturing logs centrally before an instance terminates, you may lose the only record of what that instance did. Centralized logging solutions that aggregate across services and instances solve this problem, but they have to be built in deliberately. They do not appear by default.

What good looks like

Mature auditing practice has a few consistent characteristics regardless of environment. Logs are encrypted in transit and at rest, so they cannot be intercepted or read by unauthorized parties on their way to or sitting in storage. Access controls are granular and enforced, not just documented. And automation carries the review burden that no human team can sustain at scale, flagging deviations from baseline behavior and triggering alerts before a compliance violation or breach goes undetected for months.

The implementation specifics vary by platform. AWS CloudWatch Logs, Azure Monitor, and Google Cloud's Operations Suite each handle log collection and retention differently. The ELK stack and Splunk are common choices for aggregation and analysis across hybrid environments. PCI DSS has its own logging standard for organizations in scope, and ISO/IEC 27002 provides the broader information security controls framework that auditing sits within.

Accountability, in the end, is not a technology problem. It is a design decision. You either build systems that can answer for themselves, or you build systems that hope nothing goes wrong. The standards and tooling exist. The question is whether your organization treats this as infrastructure or as a checkbox.