App security means app visibility, and audit logs are becoming a key requirement of both enterprise customers and fast growing startups. Building audit logs into your app will help land those larger deals and give your customers conviction in your product’s security profile (View Highlight)
The basics: what audit logs are and why you should care (View Highlight)
Every time a user does anything of consequence – log in, reset password, create report, you name it – your system emits an event with useful metadata about that event. Companies will expose these events via a UI and/or an API so admins can analyze them at scale (View Highlight)
In specific industries such as finance, there are laws that require companies store a “paper trail” of user behavior (such as messages) in an audit log, often referred to as data retention (View Highlight)
These logs may also be used for digital forensics in the case of a breach, or “e-discovery” during a lawsuit (View Highlight)
The goal of audit logs is to provide a paper trail of important actions that help IT admins and security folks get a detailed picture of what’s happening in your app – that’s the driving logic for what kinds of events you should be writing (View Highlight)
Chances are you already emit events in a similar fashion: but your audit log events should not be the same as analytics or observability events. This is a common mistake companies make - the kind of data a team needs internally for product analytics and general instrumentation will overlap with audit logs, but different use cases necessitate different data (especially handling concerns around PII). The same is true of your observability data: if you’re sending events to Elasticsearch / Prometheus / Honeycomb / your monitoring system of choice, those events might overlap with audit logging use cases – but you’ll need to do a ton of scrubbing and cleaning in advance. (View Highlight)
The typical format looks something like this:
An actor - The ID of the user that’s carrying out the action (can also be the system).
A group - The permission group(s) the user is part of, usually an organization ID or domain.
An action type - The name of the event (password_changed, authentication_successful).
Timestamp - A… timestamp. Keep things in UTC, as always. (View Highlight)
Note: Typical security log format
Unsurprisingly, there is at least one standard that’s gotten some traction: it’s called the Common Event Format (CEF), and it comes from ArcSight, a SIEM provider (more on that later). The standard is aimed at making it easier to communicate between security systems, and prescribes a library of standard event fields like sourceHostName and and requestURL. However, in practice most audit log systems do not match the CEF. (View Highlight)
audit logs should be immutable once they’re stored. That’s the whole point. (View Highlight)
