File integrity monitoring (FIM) started back in 1997 when Gene Kim launched Tripwire and its “Change Audit” solution. Just a few years later, Change Audit became FIM; this rebranded tool worked with the 12 security controls identified in Visa’s Cardholder Information Security Program (CISP). CISP became PCI DSS 1.0, and things continued to evolve after that.

Which brings us to the present day. Through our more than two decades of experience, we’ve come to learn that there are some misconceptions still surrounding FIM. It’s imperative that we address those fallacies now so that organizations don’t forsake this security practice and thereby leave themselves exposed to additional risks.

Misconception #1: False Positives

The first misconception is that FIM will generate too many alerts and false positives. Sure, FIM could generate this alert overload…but only if you decide to turn on monitoring for everything. The purpose of FIM is to zero in on critical files like the “system32” folder, and other critical files, including registry entries and the like. If you lease FIM on all your systems, I can guarantee that the monitoring process will become onerous and time-consuming and that it will generate too many alerts.

You can further automate processes here by integrating your FIM capabilities with other security systems such as IT Service Management solutions for change reconciliation. This will help reduce the number of alerts you’ll receive when something does change, thereby enabling your security teams to focus on unauthorized changes without having to deal with too much noise from the network.

Misconception #2: Endpoint Overload

Next, we have the notion that FIM will overload the endpoint. There’s no grounds for that. As an example, Tripwire uses an agent that sits on the endpoint that is optimized. This agent effectively helps Tripwire’s solutions effectively monitor for changes (Read more...)