Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2016-03-30 InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

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)

SOC Resources for System Management

Published: 2016-03-30
Last Updated: 2016-03-30 01:08:56 UTC
by Tom Webb (Version: 1)
2 comment(s)

I have recently started looking at the MITRE 10 strategies for a SOC (hxxps://   Strategy one in their doc is to consolidate the following under one management team: Tier 1 Analysis, Tier 2+, Trending & Intel, SOC System admin and SOC Engineering.  This makes a lot of sense.  But what do you do when you don’t have enough skilled people or positions to have a separate system admins and engineers?


My group has  individuals assigned responsibilities to different products for patching, maintenance  and operational optimization. The current problem I run into is that we get into an engineering mode where a large amount of time is spent deploying, patching or scripting things. While all these items need to be done, it reduces our IR bandwidth with backlogs. One strategy is to have the tier 2+ group alternate between weeks for engineering/maintenance. This will force  them to better plan upgrades within that window or work on other assignments.  


Long term plans should include additional positions that can be assigned the maintenance and engineering of systems  What are other strategies being used by groups that maintain their systems, but without a dedicated resource to it? Please leave comments..


Tom Webb

2 comment(s)
Diary Archives