Home > Incident Response, Intrusion Detection, Systems Hardening > The Value of File Integrity Alerts

The Value of File Integrity Alerts

Tools like AIDE and the original Tripwire have long been used in the Unix world for so-called intrusion detection. They let you know when a file has changed by presenting you with an old and new checksum, but usually don’t provide much more info than that.

While knowing that a file changed is useful, how much inherent value is there in simple file hash reports and alerts? In my opinion, very little.

These old tools don’t provide any context about the change. They don’t tell you who changed it, what happened just before and after the change, and what in the file actually changed. At best, you’re left with a bewildered goose-chase trying to figure out what happened.

To make matters worse, a well administered systems is supposed to change. If critical system files aren’t changing, you’re probably not patching. And if you are patching, you’re getting these alerts all the time and will eventually ignore them. The more systems you have, the worse the problem is.

Does that mean there is no value at all in integrity checks? Of course not. The value lies in two things:

  1. Getting alerts for rare but important events. Knowing about a file added to the init.d directory or the Windows run key in the registry might be valuable.
  2. Having the checksums available on a secured system for forensics.

Security is always a balancing act. Getting flooded with information about low value events is just as bad, if not worse, than not getting any alerts. Alerts should be meaningful and should, at the very least, cause you to stand up and take notice of something that isn’t normal.

Addendum: Complete IDS systems are also sometimes lacking in context. It probably took three or four tries just to post this due to content in the post that the IDS thought was a web attack. :)