If File Integrity Monitoring (FIM) were easy, everyone would be doing it. Actually, it is pretty easy. It’s not exactly rocket science. Practically anyone with a modicum of Python, Perl or development skills can write an app or a script to gather the checksum of a file, compare it to a list or baseline, and tell you whether or not said file has changed.
Hell, turn the auditing of most operating systems on and start sending change data off to your favorite syslog server or SIEM, and you can go to sleep at night thinking you have invented the latest and greatest FIM solution.
Why do you even need File Integrity Monitoring?
But, why do you even need FIM? Why does it matter? If it’s such a foundational control, why aren’t more folks doing it?
Because while detecting change is easy, reconciling it is not, and there is the core of the problem that folks who offer checkbox FIM solutions or logging solutions don’t seem to be able to solve. They offer up the customer the idea that all you need to do is set their solution into place and start collecting change data, and the auditors will be happy.
For many of them, FIM is just an item to be checked off on a list of products that they are trying to sell you. What they don’t tell you is that while you might get away with such an approach with an inexperienced auditor, it can lead to significant findings if you come across one that knows what they are looking for.
I’ve had customers who have run into both. The customer who was prepared with Tripwire Enterprise reports and could show authorized versus unauthorized changes to the SOX auditor passed with flying colors. The other one? Well, let’s just say that they are looking to make what was a small deployment much larger…
One of the key issues is that of maturity in their security and/or compliance best practices. Small organizations in particular have fairly minimal staff who wear a lot of hats. The same person who manages the servers and applications may also be the person who generates the reports for the auditors. Our founder Gene Kim used to do presentations to auditors and security folks and he had a little saying: The person who saved the ship may have been the one who started sinking it in the first place.
The sysadmins may not even have the skills for the role they are in (through no fault of their own). I visited a customer once who told me that prior to being one of two members of the security team he was a “loss prevention specialist.” That’s right…the guy who stopped shoplifters was now in charge of security at a multi-million dollar business.
These skills gaps magnify the problem that the reconciliation of change, the process of determining whether it was authorized or unauthorized, is not easy. And choosing a checkbox FIM solutions when the people running it can’t even wrap their heads around the concept can lead to a number of issues:
1. NOISE
Change happens – a lot. Every week, hell, every day there is a new patch, hotfix, service pack, upgrade, or even normal system activity that happens on a server. Hundreds or even thousands of changes can occur. Now, multiply that across an entire data center and think about trying to sift through those changes to find the malware or the misconfiguration that interrupts a service. It will be like searching for a needle in a stack of needles.
2. PERFORMANCE
Ask anyone who has turned on C2 Auditing on a SQL database or tried to enable Object Access: Success on a large number of files and directories on a Windows server. Performance on that system will suffer.
3. RECONCILIATION IS HARD
Checkbox FIM products are, more often than not, a minimally viable product designed to get you over the low bar of FIM. The higher bar of change reconciliation lies out of reach for most of these solutions. Trying to match changes against any given change management process requires the technical prowess of a company that understands such things and having spent almost its entire existence to understand what the auditors were looking for. It also requires understanding how unauthorized change can impact a business.
4. AUTHORIZED CHANGE IS NOT NECESSARILY GOOD CHANGE
This is one that many folks can’t wrap their brains around, but it speaks to the anecdotal idea that most downtime or breach occurs due to some internal IT action. The sysadmin could have a fully authorized change ticket to install Dropbox or enable telnet on a server, but is that a good thing? Probably not.
Even deciding what it is you want to monitor and how is something a lot of checkbox vendors can’t help you with. Do you try to monitor every single file? Just the operating system? What about the applications that are on the server?
The folks here at Tripwire have been working on these problems for over 20 years now. Out of the box, we provide coverage for all of your major operating systems (and more than a few older or obscure ones.) Need help with a custom application or other file or directory? We have seen more than our share and stand ready to help you.
What about this reconciliation thing you keep harping about? That, my friend, is the magic sauce… well, not magic. Instead, it’s a set of robust APIs and partnerships with large and small change management solution vendors like ServiceNow or Remedy that allows Tripwire Enterprise to take detected changes and match them up against a known ticket or vendor patch. It’s our built-in ability to test those changes against a benchmark like the Center for Internet Security, NIST, or PCI and tell you whether or not the changes take you out of compliance.
We haven’t even gotten into the more security-related aspects of true FIM. Our ability to match our FIM data against the Indicators of Compromise (IoC) databases of our threat intelligence partners is just one of the many uses of Tripwire Enterprise. For example, many of our customers download our free Splunk App to integrate our products, so that change data can be reconciled against other network level security events.
At the end of the day, the business needs to make a decision. Do we spend less on a checkbox FIM product in the hopes that their auditor doesn’t call them out on it, or do they end up spending multiples more when an outage occurs due to a bad change and because they trusted their sysadmin? Or do they invest in a company with a long track record of successful change reconciliation that works well within just about any security ecosystem?
Let me answer it with this final, little, aphorism from Gene Kim who wrote the original Tripwire code so many years ago: “Hope is not a strategy, and trust is not a control.”
Interested in learning about 10 reasons why Tripwire’s solutions outperform other companies’ products? Click here.
