This post is partly inspired by the old Richard's post "TaoSecurity Enterprise Trust Pyramid" where he explains that he trusts some security, system and network evidence (not in the legal sense though) 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 pure distilled crap :-), 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'/Admin 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).
No comments:
Post a Comment