What to watch with your FIM?

Published: 2016-03-30
Last Updated: 2016-03-31 07:34:39 UTC
by Xavier Mertens (Version: 1)
4 comment(s)

A few days ago, one of our readers posted a message in the general discussion forum about FIM (“File Integrity Management”) and, more precisely, which files/directories to monitor. Just a brief introduction for those who are not aware of File Integrity Monitoring: It's a security control that helps to validate the integrity of files present on a file system using a baseline of this system. The comparison with the baseline relies on file hashes but not only. Other file attributes can be monitored: the owner, access rights or the last modification time are good examples.
This control is implemented via processes and enforced with tools. Like most of information security tools, it's just… a dumb tool! The challenge is to configure it in the right way to increase your chances to detect a malicious activity. Available tools are delivered with baselines for standard environments but must be fine tuned to match your own requirements. I think that it’s a good idea to share and discuss some ideas on this topic: What do you monitor with your FIM?
Basically, they are two types of data that you can watch:
  • System” files - They will help you to detect if a server is compromised, if its configuration has been changed or if users are performing dangerous activities (like copying files or installing applications).
  • Data” files - Those are the files used by your “business".
In the second case, it’s impossible to build a list of interesting files. They depend on your business. Here are some examples where a FIM might be helpful:
  • Logging changes on source repository (to track the developers tasks)
  • Logging changes on sensitive department shares (HR, accounting, …)
  • Logging changes on public resources (like web servers, FTP servers)
The implementation of a FIM has also side effects. A classic issue is patching systems. By replacing system files, patches can generate a huge amount of false positives. From a system perspective, here is a non-exhaustive list of files/directories to monitoring on UNIX/Windows systems:
For UNIX systems:

Specific files can be monitored:

  • Executables in /tmp ,/usr/local/tmp, /var/tmp
  • Plain files in /dev
Others must be ignored (changing too often):

For Windows systems:

C:\Documents and Settings/All Users/Start Menu/Programs/Startup
C:\Users/Public/All Users/Microsoft/Windows/Start Menu/Startup
On Windows, the registry contains many useful locations that can also be monitored by most FIM:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components
HKEY_LOCAL_MACHINE\Security\SAM\Domains\Account\Users \Enum$
The following one can be ignored (changing too often):

And you? What are you monitoring? Please share your configurations and tips!

Xavier Mertens
ISC Handler - Freelance Security Consultant

4 comment(s)


I think monitoring the list of trusted root certificates beneath <HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates> would be valuable for detecting the import of potentially malicious root certificates that could be used to intercept encrypted traffic. Microsoft provides an overview of these Registry keys here: https://technet.microsoft.com/en-us/library/cc783813(v=ws.10).aspx#w2k3tr_cacrt_tools_tsno
I get a ton of alerts for files under C:\Windows\winsxs\ and C:\Windows\servicing\ and I generally have to ignore them because there are so many. When I came here, they said that the exclusions don't work. I can't wait to get a different product!
Had a semi-long comment that looks to have gone poof, so here is my short and to the point FIM Tips based on my experience.

For FIM, before anything else, you need to determine if your chosen FIM solution can integrate with your change management solution for the purpose of reconciling detected changes against whether of not there is a valid change ticket for the server, time window and rule being examined.

If it doesn't have this, and if you don't make having this a priority from day one during your design and implementation plan, unless you are a very small shop, you will get buried under changes, and that malicious action you are hoping to detect will be forever lost in a sea of valid normal changes.

Trust me, I've seen it from both sides, and you want integration with your change management solution from day one.

Best of luck!
Starting in 2008R2, the public user startup folder was moved to:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

So I added that to my include list.

Diary Archives