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.
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.