Logblog: Log Trustworthiness Hierarchy

« Just What is Enterprise Class? Part II | Main | Breaches Rise - PCI DSS Enforcement Lags »

Log Trustworthiness Hierarchy

This post is inspired by the old TaoSecurity post Enterprise Trust Pyramid where he explains that he trusts some security, system and network evidence data more than other. For example, dedicated NSM sensor records are trusted more than vanilla server logs. With this post, I am looking to establish a log trustworthiness hierarchy so that people start thinking about trusting log data as a kind of a spectrum, from "probably trash" to "guaranteed to be an accurate record of activities."

So, do you trust your logs to accurately depict what happened on the system or network? Which logs do you trust the most? How do we increase this trust?

My first draft of such trust hierarchy follows below (from low trust to high trust):

Compromised system logs (mostly trash, but might contain bits that attacker missed/ignored)
Desktop / laptop OS and application logs (possibly changed by users, legitimate systems owners, etc)
All logs from others systems where 'root'/Administrator access is not controlled (e.g. test servers, etc)
Unix application logs (file-based)
Local Windows application logs
Local Unix OS syslogs
Unix kernel audit logs, process accounting records
Local Windows server OS (a little harder to change)
Database logs (more trusted since DBA cannot touch them, while 'root' can)
Other security appliance logs (located on security appliances)
Various systems logs centralized to a syslog server
Network device and firewall logs (centralized to syslog server)
Logs centralized to a log management system via a real-time feed (obviously, transport encryption adds even more trust)

Admittedly, the differences between some of them are minor or even non-existent ...

To conclude, some logs DO in fact provide reliable evidence in case of an incident; you just need to know which ones to trust and which ones to only consider to be "hints" (or possibly even a misdirection). But of course, you need to first have logs and then look at them.