|
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:
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:
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:
Others must be ignored (changing too often):
For Windows systems:
On Windows, the registry contains many useful locations that can also be monitored by most FIM:
The following one can be ignored (changing too often):
And you? What are you monitoring? Please share your configurations and tips! Xavier Mertens |
Xme 532 Posts ISC Handler Mar 31st 2016 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Subscribe |
Mar 31st 2016 4 years ago |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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
|
Anonymous |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Quote |
Mar 31st 2016 4 years ago |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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!
|
Anonymous |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Quote |
Mar 31st 2016 4 years ago |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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! |
StephenLange 1 Posts |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Quote |
Apr 1st 2016 4 years ago |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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. |
StephenLange 2 Posts |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Quote |
Apr 1st 2016 4 years ago |
Sign Up for Free or Log In to start participating in the conversation!
