It is quite common for novice and hobbyist attackers to break into an environment through an unpatched system and upload modded files to effectively over-write the functionality that may already exist within your environment in order to hide their activities. On Linux, this may consist of uploading a rootkit that mods ls, ps, w, who, netstat, login, and top. On Windows, this may consist of over-writing files within the system32 directory or hooking API calls. Either way, many organizations add security controls to aid in preventing and detecting this type of anomalous behavior. One such way to mitigate this activity is to use File Integrity Monitoring (FIM) to provide some basic visibility around unauthorized file modifications.
FIM can be deployed as an agentless or agent based solution within an environment and can be run in a central or distributed architecture. It generally, runs on a scheduled basis and signatures are written to detect adds, changes, deletes, and modifications for each grouping of binaries and files on the file system. Out of the box, most FIM solutions provide signatures for monitoring critical operating system files and to detect known rootkits. And FIM software can alert when unauthorized changes occur depending on the rules you provide. As part of your overall strategy, FIM also aids in providing value for SIEM solutions where FIM alerts and logs can be shipped via XML or syslog to a SIEM monitoring solution for triage and correlation to other events.
It is also important to note that much of the FIM market these days is driven by standards requirements such as PCI DSS which require that FIM be installed on systems within the Card Holder Data (CHD) environment. In this case, an auditor will look for FIM to be installed and sending alerts, but its overall value to the organization is only as good as the signatures and monitoring alerts which rarely comes up during a PCI DSS audit. The smaller market demands come from security professionals who use FIM knowing its strengths and weaknesses to protect and detect the server OS and other critical files as part of a larger strategy.
FIM Products
Because of PCI DSS there are many more tools, software, and services in this space than in previous years. And each of these products has their own features and benefits which now include additional reporting and correlation elements. Here is a partial list:
- Tripwire
- OSSEC
- NNT Change Tracker
- File Integrity Monitor (ncircle)
- File Integrity Monitoring (LogRhythm)
- NetIQ Change Guardian
- CIMTrak
- AIDE (Advanced Intrusion Detection Environment)
- Verisys
- McAfee Integrity Control
- Osiris
- Samhain
- ...
Planning Questionnaire
FIM planning is key to the success of this detection control. Because of this, it is important to create a planning questionnaire which can help you to determine which product/service to choose and the necessary elements required for integration into your environment. Here are some basic questions to consider adding to your planning questionnaire:
- What are the goals for FIM? __________
- What is the amount budgeted for FIM? __________
- Will FIM be used to meet compliance requirements? __________
- Will FIM be used as a key control within your environment? __________
- How many systems will need to be monitored with FIM? __________
- Which Operating Systems will require monitoring? __________
- Where will FIM be installed? __________
- Which type of architecture will need to be deployed? __________
- Will you use agents on the servers/assets being monitored? __________
- How will agents be deployed?
- Does your environment leverage central configuration management? __________
- How will FIM alerts be evaluated? __________
- Will FIM logs be sent to a centralized log repository? __________
- Who will monitor and approve changes for FIM? __________
- What reports should be developed and who should receive these? __________
- Is FIM required to meet regulatory or standards requirements? __________
- How will FIM be tuned and who will be responsible for identifying new FIM signatures? __________
- Will a SIEM solution be utilized within the environment? __________
- ...
Use Cases
Use cases are necessary when implementing detailed monitoring solutions within your environment. For FIM, security use cases provide a great deal of insight into what is important and how it relates to the specifics of the business. A use case for FIM is usually structured towards what a FIM can provide which is information about modifications, new files, permissions, and file stamps. Here are some use case examples to get you thinking:
- Detect critical binary changes.
- Monitor: Modifications, Permissions
- Binaries: ps, ls, w, who, login, netstat
- Rule: Dynamic
- Why: Suspected Rootkit, Unauthorized Change
- Detect critical file changes.
- Monitor: Modifications, Permissions
- Files: passwd, group, httpd.conf, hosts, exports, crontab
- Rule: Dynamic
- Why: Unauthorized Change
- Discover new files in specific directories.
- Monitor: Add
- Directories: etc, var, init.d, xinetd.d
- Rule: Dynamic
- Why: Malware, Unauthorized Change
Implementation Guidance
To implement FIM, it is strongly recommended to utilize agile or scrum to phase the installation and configuration steps in order to ensure that the product is working properly and detecting events before spending time tuning. Similarly, a solution design is essential in reaping rewards from a FIM implementation because it is necessary to achieve alignment for this solution from the start. Consider the following as part of your FIM solution architecture: (1) placement, (2) hardware and OS, (3) access, (4) initial configuration, (5) logging, and (6) integrations.
If you go for an out of the box install during the implementation phase, you will quickly realize things about your FIM solution architecture that you had not considered. For example, if you have a configuration manager within the environment, every time it runs a schedule job your FIM solution will detect a modification where timestamps are being monitored.
Tuning Guidance
Tuning is one of the most detailed tasks that a security engineer takes on. Essentially, it requires a great deal of planning and knowledge about the environment in order to derive benefit from a FIM. Here are some tasks to take into consideration for your tuning project:
- Organize your assets into groups, ie: by OS, by type, by function, by VLAN, by service.
- Next you will want to determine the criticality of your assets since some products allow you to classify your assets for notification and alerting purposes. This is easily accomplished by setting up a notation for criticality and ranking each server within the organization. Ranking may not be very valuable for FIM by itself but plays into a much larger security strategy whereby it becomes essential to support correlation and triage.
- Identify the strategy for the rules being written and how a new rule will add value to other security use cases.
- If you are using a SIEM, determine what information needs to be added to the rule for it to be useful during correlation.
- Identify other software in the environment which may alter files or timestamps and which requires correlation to exclude false positives.
Maintenance
Most highly tuned security tools require extensive maintenance to ensure that their value is maintained over time. For FIM products it is essential and vital to ensure that maintenance efforts continue to include review and upkeep for signatures, rules, actions, and reporting. Without this continuous effort, a FIM will begin to break down as changes deviate from the initial patterns that were set up. As a result, most FIM products require daily reviews and upkeep. Depending on your server farm and FIM product, this effort could range from minutes per day to hours and in many cases require a dedicated staff member to trace changes back to their origin.
Limitations and Countermeasures
But it is not good to think that FIM by itself provides silver bullet protection for your servers without additional controls and processes. Likewise, it is not a good strategy to think that FIM can protect your systems from all rootkit and activity hiding that can be attempted on a system. Why do I say this? Simple - FIM watches what you want it to watch and alerts you when something you did not expect to happen happens in a precise manner. In this case, if you implement a FIM and write a signature to let you know when /sbin/ls has been modified, FIM will send an alert anytime the file gets modified.
But FIM breaks down when file hooking is leveraged by files that have been hidden in directories, tmp space, memory or slack space. In this way, a FIM rule that watches /sbin/ls may not be aware of a program on the system that hooks the functionality for /sbin/ls whenever it is opened. Signatures for catching this type of activity are far more advanced and require a great deal of skill and knowledge about specific types of attacks and changes at a low level of each operating system type. Because of this, FIM only works as well as the signatures being developed for the environment and finding skilled resources can be a real challenge.
Consider overcoming these limitations by utilizing FIM as part of a control group, where it provides value by adding to other control pairings.
