Many of you have used File Integrity Monitoring already – if you’ve ever used Tripwire, Samhain, OSSEC, or even “rpm -Va” to verify the integrity of system binaries, you’ve got enough experience that I probably don’t need to explain what a checksum is. 🙂 We thought it might make sense to quickly cover the differences between our File Integrity Monitoring (FIM) implementation and traditional FIM tools. For more detailed information, take a look at the File Integrity Monitoring User Guide found under “Help & Support” in the Halo portal.
Keep in mind that as of Feb 2012, this is a Beta release intended to provide early access to the FIM module. We’re covering some of the limitations of that Beta release in the blog so you won’t be surprised, but also don’t be surprised if these limitations disappear soon. 🙂
Here are the things that are similar to other FIM tools:
– You have to create a policy, which is a list of files and directories (in FIM, these are called “Targets”) that you want to watch.
– The policy is applied to one or more servers. These servers are regularly checked for changes in the specified files and directories.
– As part of setting up FIM for a machine or group of machines, we take a baseline – a pristine image of how the system or group should look. We compare the state of that system or group to the baseline once a day (or more frequently, up to once an hour) to look for differences. Read on, though, about how the baseline is picked.
– When differences are found, you can choose where that information is sent. All exceptions are sent to Security Events and Security Events History (both found under the “Servers” tab). You can see the most recent report for a particular system by going to Servers, then File Integrity Monitoring, then clicking on the system name.
If you want to be notified by email for certain files, check off “Alert” for those files when editing the policy and your admin team will get live emails about exceptions. (See: Setting up alerts profiles). Both approaches allow you to set or clear the “Critical” flag to further refine which exceptions get reported where.
– You’re alerted when files are added to or removed from a monitored directory (see the reference below for adding and removing directories).
There are a few differences in how Halo’s FIM module works:
– Traditional FIM compares the current state of system N to how system N looked when you created the pristine baseline. Because elastic cloud servers can come and go, and because cloud servers should be essentially identical to each other, we’re comparing all the systems in a group to the pristine baseline. For example you could setup a Web server as your gold standard image, go to the web server FIM policy, press “Baseline”, and select the Web server to be your baseline image. Now all the web servers in the web server group will be compared to the way this server looked when you baselined it. This technique is especially useful since you’re likely cloning those servers from the gold master.
This might seem odd to people used to the old way of comparing N to how N looked in the past. If you stop and think about how cloud systems are far more likely to look identical and have few if any custom changes from each other, it’ll start to make more sense that we’re treating group members as essentially identical images. That translates into less work for you, and that has to be a good thing. 🙂
– Traditional FIM tools warn you when almost any aspect of the file changes (content via checksums, size, dates, ownership, permissions, inode number, etc). Halo’s FIM only notifies you when the content of the file changes (like other tools, using a checksum). When the content changes, you’ll also get to see some of the metadata (user and group owner, permissions, mtime and ctime) for the modified files. However, if the content stays the same (checksum does not change), you will not be notified if the ownership, permissions, dates, or any other aspect of the file changes. To clarify – you only get notified when the file content changes. To watch for changes in user ownership, group ownership or permissions on specific files, you can use configuration policies.
– When you put a directory in a policy (such as “/etc/*”), you do not look at all files anywhere under /etc/; FIM in the current beta release does not search down recursively. To see all files immediately under the /etc/ directory, you use “/etc/*” (that will match /etc/passwd, /etc/group, etc. but not /etc/pam.d/login). You can go one level deeper with “/etc/*/*”; that looks at files in all directories immediately under /etc/ (such as /etc/pam.d/login), but will not see changes to /etc/gnome-vfs-2.0/modules/ssl-modules.conf . To go deeper than two levels, you’ll need to pick individual subdirectories and make new rules for them, such as: “/etc/*”, “/etc/*/*”, “/etc/gnome-vfs-2.0/*/*”, etc. This is a limitation of the current FIM beta code.
– The current release doesn’t allow you to exclude files or directory trees. Like above, this is also a limitation of the current FIM beta code.
– You’re not alerted when directories are added to or removed from a monitored directory. This is also a limitation of the current FIM beta code.
– If you find that one of the FIM alerts is a false positive (perhaps because someone’s temporarily working on that file or you don’t want to see the alert for a short time for some other reason), you can suppress the email alerts for that file. In a FIM report, go to the “Suppress” drop down box to the right of the file in question. You can tell Halo to suppress emailed alerts for this file for 1 day, 7 days, or 30 days. “Suppressed” file changes will still show up in the web portal’s FIM reports (along with a notice like “Email alerts suppressed until 2012-01-20 23:59:59”), but email alerts for that file will be quieted, giving you a change to fix the problem in peace. When you’re done fixing the issue(s), simply take a new Baseline and that automatically clears any email suppressions.
To more permanently disable checking a file or directory (a “Target”), edit the FIM policy and either uncheck “Enable Scan” if you think you might re-enable the target later, or simply delete the target permanently with the “x” icon to the right.