Audit logs are that thing that everyone has a good grasp about in theory, but is hard to define in practice. We have previously covered what is an audit log in IT context and now we’ll focus on why it’s important for security.
Why Are Audit Logs Important For Security
An important theoretical point we’d like to make is that every security log can be seen as an audit log. This is why at LogSentinel SIEM logs are presented in an actor/action/entity form regardless of the source. Treating every security log as an audit log allows you to fit all of that data into effective user and entity behaviour analytics (UEBA) because each event has a user or entity that is performing it.
But how come all security logs are audit logs? Apart from the obvious ones, like database audit logs, and application-specific audit logs (e.g. SAP security audit log), let’s take a few examples that might seem counterintuitive at first:
- Firewall logs – they’d typically have an IP address, a protocol, a port. The IP address is the actor (user or entity). Yes, it’s not necessarily personalized, but it still identifies a distinct actor. Each connection attempt is an action, and the protocol/port are the contexts. So “IP address connects to TCP#22” is an audit log. If the IP is internal, you can even match that via DHCP to a particular human user or system for an even better overview
- ActiveDirectory logs – authentication logs are a good example of audit logs – “User X signed in to domain Y”. Or, performed a failed login. Or escalated privileges. AD logs always answer the question “who did what”
- IaaS logs – GCP, AWS, Azure and other IaaS providers have a lot of different logs – CloudTrail, for example, is the typical infrastructure audit log, but there are authentication logs as well. Because these services are often API-driven, actors can be subsystems or API clients, but that’s why it’s “user and entity” in UEBA – not every activity is performed by a human user.
- OS security logs – OS security logs contain a lot of data about processes. Getting back to the previous point, a process is an “entity” that performs certain actions – requests permissions, writes files, starts a service, etc. All of these fit nicely into the audit log frame.
- Database query logs – there are two types of authentication against databases – applications and human users. Both send queries (DML and DDL) to the RDBMS. Logging human users queries (DBAs usually) is the easy part. Associating an application-issued query with an application-specific user is next to impossible without extending the application in some way, but monitoring the queries with the application user is still a good step.
- Flows – flows are not typical “logs”, let alone “audit logs”. But they too give you a picture of “who did what”, in this case – which IP had a session to which other IP over what protocol, for how long, with how many bytes transferred, etc.
What Are Audit Logs Typically Used For?
All of those logs (and more) are crucial for forensics (understanding what happened), threat hunting (finding potential threats in historical data) and for real-time threat detection. Correlating actors across these assets based on multiple parameters (the actor itself or something else) is important for all of the activities above.
And then we get to all other, application-specific audit logs, which would give the full picture – authentication into a SaaS (e.g. Salesforce or Microsoft365), downloading files from SharePoint, changing a contract in SAP, changing numbers in the accounting system, making a leave request in the HR system, and more. All these events are audit logs and while they are too often ignored by SIEM projects, they are very, very useful for all of the above – forensics, threat hunting, real-time threat detection and for compliance.
Data is usually sitting in databases, but accessing those databases is often done through the applications that store the data, by insiders and outside malicious actors alike. Therefore application audit logs are as important as the other types that we saw above.
The combination of network-level security logs, authentication logs and application-level audit log gives the full visibility on the organizational IT ecosystem. Ignoring one or the other, or treating them as “just logs”, rather than audit logs, misses a lot of useful contexts. Correlation rules and machine learning work much better if they have the full picture as well.
LogSentinel SIEM and the LogSentinel Collector aim at aggregating all security logs, not just a few network or OS logs. The more security-relevant data is ingested, the better a SIEM performs.
Bozhidar Bozhanov is a senior software engineer and solution architect with 15 years of experience in the software industry. Bozhidar has been a speaker at numerous conferences and is among the popular bloggers and influencers in the technical field. He’s also a former government advisor on e-government, transparency, and information security.
