What Are Audit Logs?

The concept of audit logs is simple. When a change is applied to a system, it correlates with a change in the system’s behavior. That change should be documented in an audit log. Per Wikipedia: “An audit trail (also called audit log) is a security-relevant chronological record, set of records, and/or destination and source of records that provide documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure, or event.”  An audit log in its most primitive form would be a pen and paper a person would use to make entries to accompany changes made to a system. Signing your kids in and out of daycare would be an example of an audit log. In the digital age, audit logs are more likely to take the form of file or database tables. Further, these logs typically require elevated privileges in order to access them. When I go to sign my child out of daycare, the entire log is open for all to see; I can see what time other parents dropped off and picked up their children. Is that any of my business? Probably not. What's more, in the digital world, you typically cannot bypass audit logs. If you access a system, an entry will be made to the log. This ironclad quality is what gives digital audit logs their value and also what allows them to hold up in a courtroom if necessary. As a member of a tech team, it is important to understand what audit logs are and why they can be useful. Skimping on audit logs should be a deliberate decision, not a default state.

There are many reasons for capturing the changes to a system and many different parties who may have an interest in viewing audit logs.   From a developer’s perspective, audit logs can keep you sane by giving you some insight into how a complex system arrived at its current state. Developers are typically fond of state diagrams and deterministic outcomes. An audit log that shows that a person or process applied a change can give developers valuable insight.   Imagine a scenario where some critical data was deleted. Without any kind of audit log, all you can do is speculate and shrug your shoulders. But if you're using an audit log, you can say with certainty that Joe User deleted the data at 9:56 a.m. PST on July 17, 2018. The latter is a much more satisfying answer to most concerned parties. Plus from a compliance perspective, audit logs are an absolute necessity. There are many legal concerns that companies must adhere to, and audit logs are an official record that we can provide when an auditor asks for proof of compliance.   Security is another area in which audit logs can be invaluable. Now that even the most sensitive data is accessible via the internet, audit logs are critical. Having a public-facing web service is the equivalent of allowing billions of people to “rattle the doorknob" just to see if they can get in. Even with the strongest security measures in place, it is still very useful to know the frequency and source of potential attacks. An audit log can capture this type of data.

In a world where disk space is considered cheap, there aren’t many compelling reasons not to “capture everything." So why would some companies fly without audit log capability? The answer is usually that audit logging is an afterthought. If you catch a startup in its early phases, it is typically moving at fast and furious speeds to build out features and functionality. When the objective is to produce a minimum viable product (MVP), non-functional requirements like audit logging typically don’t make the cut. Later down the line, if the product gets legs, audit logging capability is often added as a reactive measure. When stakeholders can’t provide acceptable answers to questions regarding data, security, and system state, they will typically see the light and allocate resources toward attaining audit logs. As we’ll see, audit logging is a very broad term that can cut across every layer of a tech stack. Sometimes, audit logging can be a freebie, and you can get adequate logging just by turning on the capability. Other times, it will require some time and effort (i.e., cost) to get there.

If you are considering implementing audit logging for your application, there are two distinct areas of consideration: applications and infrastructure.

This is typically within the purview of the developer. Changes to the database, the path a user takes through the application, logging in and logging out, identity, etc. are all considerations here. Sometimes you may need code changes to get the level of audit logging that you need. If you are using a traditional relational database, then you should be aware of one of its primary shortcomings. SQL databases are built to store data in its current state. They are not known for telling you how you got to your current state. To get around this, you should design audit logging into your storage. There are many techniques for achieving this. One is the use of triggers and archive tables to capture a full history of how values change over time and who made the changes. Another possibility is the use of an event sourcing model that only appends to the database and captures all changes as events. There are other options available, but the key takeaway is this: consider audit logging early and treat it as a requirement. Another area of interest may be a flow report. This type of audit log captures a user's path through the application. It can be useful in marketing contexts to understand how users are navigating the UI, but it can also serve as an audit log. In a highly secure application, every click may be tracked to show who is attempting to access various resources.

Infrastructure is the territory of DevOps. While the DevOps team does not build the application, they are responsible for the environments that host them. And they should have an interest in audit logging as a means of tracking changes to those environments. Deployments are transient events in systems. They take the system from one version to another and are worthy of verbose entries in an audit log. If you use an off-the-shelf tool for deployments, there will be some free logging available. For those who roll their own scripts for deployments, be sure to pepper them with copious amounts of log statements. If you are doing manual deployments with a lot of mouse clicks, then you should consider upgrading your deployment process. Manual processes make audit logging haphazard at best and untrustworthy at worst. Environment changes also drive state changes in systems. Operating system updates are an obvious example here. A Windows Server OS update should be automatically captured in a system log, but do you know how to interrogate those logs if needed? Be sure that you learn how to understand why your server environment may have changed. Also, be mindful of manual changes to an environment. Did someone change the host file to redirect a specific URL? Document that change with a name, date, and reason. Network traffic is another key area to be aware of. All inbound and outbound network calls and their payloads may be worth capturing.

As we’ve seen, audit logging can provide a ton of value. If you need to defend a system’s behavior, audit logs are indispensable, and they can really save your bacon if you find yourself in a legal battle. For a comprehensive audit logging solution, application developers should partner with their DevOps and infrastructure teams. Automation is your friend when it comes to audit logging, so automate everything that you can. Practice the process of producing the logs in short order upon request, and be sure you're able to analyze them to answer any questions about your system’s state and behavior. You won’t regret the investment.