Management, compliance & auditing

File integrity monitoring (FIM) and PCI-DSS

In this article, we will learn about the requirement of file integrity monitoring in PCI-DSS (Payment Card Industry Data Security Standard). If we talk about PCI-DSS, FIM is the most commonly overlooked requirement, just because the statements in PCI itself do not quite clearly specify what all needs to be protected in order to ensure protection of card holder data. This article will discuss the basics of FIM, FIM requirements in PCI-DSS, Types of FIM, FIM and the Change and Control management processes, and the features that a FIM product must have. Also, this article will be taking newly released guidelines in PCI-DSS 3.0 as a reference.

I have described here in my previous article clearly what led to the evolution of PCI-DSS 3.0 or the key drivers that led to PCI-DSS. FIM control is a mechanism performed to validate the integrity of operating system and business specific files by regular monitoring the state of files against a valid known base line. A checksum is calculated of the important system file and the FIM process keeps on calculating the on-state checksum of the marked files with that of the baseline checksum.

In an organization, file changes will naturally happen and they will happen in a large amount. That is the reason organizations usually try to overlook the monitoring of system files, but to keep a check on the important data, compliances like PCI have made it as a requirement to regularly monitor the important files that if they were to undergo unexpected changes, it would result in critical data loss and serious damage. There are various attributes of files that should be monitored, like privileges, security settings, content, hash values, configuration values, etc. A good deployment of FIM also ensures that malicious code has not been embedded in the monitored locations and prevents the insertion of backdoor or Trojans into one of the core program files like /etc/host ( hosts . allow and hosts . deny etc.).

FIM requirements in PCI-DSS

The PCI-DSS (Payment Card Industry Data Security Standard) specifies the following requirements:

Requirement no 10.5.5 states that "Use file integrity monitoring or change detection software on logs to ensure that existing log data cannot be changed without generating alerts(although new data being added should not cause an alert)".

PCI Guidance for Requirement no 10.5.5 "File integrity monitoring or change detection systems check for changes to critical files, and notify when such changes are noted. For file integrity monitoring purposes, an entity usually monitors files that don't regularly change, but when changed indicate a possible compromise".

Requirement no 11.5 states that "Deploy a change detection mechanism (for example, file integrity monitoring tools) to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly".

PCI Guidance for Requirement no 11.5 "Change detection solutions such as file integrity monitoring (FIM) tools check for changes to critical files, and notify when such changes are detected. If not implemented properly and the output of the change detection solution monitored, a malicious individual could alter configuration file contents, operating system programs, or application executables. Unauthorized changes, if undetected, could render existing security controls ineffective and/or result in cardholder data being stolen with no perceptible impact to normal processing".

The goal of PCI 10.5.5 and PCI 11.5 is to ensure the integrity of critical logs from the PCI environment and to ensure that changes to files do not allow a breach of PCI data. PCI 10.5.5 ensures the importance of deploying a FIM solution so as to maintain the integrity of the existing log data to make sure log files are not tampered with and the log files meet the requirements during forensic analysis. PCI 11.5 calls for file-integrity monitoring software to look for file changes, and true integrity of your PCI environment requires much more frequent monitoring. An important thing about FIM is that the solution must provide real time monitoring of files and not make system resources take a hit performance wise.

File integrity monitoring (FIM) types

FIM works in two modes, namely:

Agent based
Agent less

In agent based FIM, an agent sits on a host and provides real time monitoring of files. The FIM agent also removes the repeated scanning load on the host and network. But the biggest question that rises against a FIM agent is that it will eat up the host resources. With a FIM agent, a local baseline will be established, and thereafter only qualifying changes will require some operations from the FIM agent and thus consumption of host resources. The FIM agent must have all the capabilities of detecting unauthorized changes, should be platform independent, and have reporting capability of what has been changed alongside with who has changed it.

On the other hand, agent less FIM scanners will be effective only on their scheduled time i.e., there is no real time detection or reporting capability. Also, agent less scanners need to re-baseline and hash every single file on the system each time it scans. Agent less FIM scanner has some positive sides also, like it is easier to operate without the hassle of maintaining the endpoint agents.

Scope of FIM

PCI has stated in a NOTE under requirement no 11.5 that "For change detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change detection mechanisms such as file integrity monitoring products usually comes pre configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider)".

This statement is a very general and does not point to a particular area (i.e. the word critical is not very well defined). So as a starting point, FIM should be configured to monitor the system files like for Windows System32 or SysWOW64 directory structure. Alongside these system files, Application folders where card related data is kept must also be monitored. The FIM approach should be to track all file attributes and to generate a secure hash out of it. Even a small change would be reported when the file integrity checks will be re-run again as the newly created hash will not be same as that of the hash previously created at the file. A FIM check process should include:

File Size
Version
When the file is created and modified
Who has modified the file
Unauthorized access of confidential files
Changes to directories
Security permissions - newly added permissions, deleted permissions and changed to existing permissions
Registry Changes - changed registry values, removed registry keys and sub keys
Changes in System Binaries and Configuration files

FIM and change management process

If FIM is deployed and configured in a standstill mode, then a large number of false positives would result. As a best practice, the FIM process should be tightly integrated with the Change Management process defined in an organization. Since FIM provides zero tolerance to any amount of changes (whether major or minor), the change management process should be well defined, followed and must inform FIM well in advance about the changes about to occur, so that the false positive count does not rise.

In fact, most advanced FIM systems provide a means through a change template that can be predefined to provide easy means to observe all the changes marked as a planned activity. This will also help in detecting any changes that have occurred outside the planned change window or template and will be recognized as unplanned and therefore damaging or malicious. Therefore, FIM used in conjunction with a closed loop change management system schedules planned changes, and associated file integrity changes must be logged.

Features that a FIM must possess

A FIM product without some useful features as described below is of no use. A FIM product must be capable of detecting that an unauthorized change has occurred, what has been changed, who has changed it, etc. Following are the features that a FIM product must possess:

Detection of unauthorized change

The first and foremost feature of the FIM product should be to detect any unauthorized changes to file system. I have used the term unauthorized because a FIM deployment must happen with a change control process so as to remove approved changes from being listed as a FIM alert. FIM products must generate a hash using algorithms like SHA to protect the data theft from malicious software like malware.

A question that usually comes from organizations is that they have an antimalware or antivirus solution in place, so the chances of a malicious program to do something in the system are very low. One thing organizations must realize and understand is that solutions like antimalware first of all must be regularly updated, and even if they are so, there can be zero day exploits that can happen against them. So if a zero day attack happens, then there is no means to detect any unusual modifying of file content. So a FIM is a necessary solution that actually acts as a last line of defense.

Give more information about who has changed what, when.

Generating a secure hash will only give you indication that something has changed, but not other attributes like what has changed, who has changed it, etc. So a good FIM solution alongside detecting that something has changed must also provide more information about who has changed it and what exactly has changed. For this to happen, the FIM product should consider the file and capture the file as a readable text, and any changes will be detected and reported. Suppose if an access control list is changed, so if that ACL comes under FIM, then it must state out the exact changes.

File or Folder access monitoring

We have discussed that the hash should be generated for files that need to be monitored, and FIM on a re-run check again generates a hash file to detect any change. But think about log files. Log files are constantly updated, so generating a hash and re-generating a hash on a re-run will always trigger an alert that is certainly a false positive. As per reports, most of the data theft that has occurred is because of an insider, so to deal with log files, files and folders access permissions must be under FIM radar, so that any access, whether authorized or unauthorized (for rogue admins) is detected, and the FIM product must provide a full audit trail, including account names about who has accessed the data and their further activity.

A lightweight FIM endpoint agent

If an organization has chosen to deploy a FIM agent, then the FIM agent must be very light and should not eat up too many host resources. Organizations must keep a check on performance and resource consumption of the FIM agent.

Conclusion

FIM is a must-have monitoring solution that every organization must deploy and manage. But deploying a FIM without a defined change management process would generate a lot of false positives, so the organization's specific change management process should be well defined and integrated with FIM to gather unapproved and malicious events from FIM.

Sources

Posted: July 18, 2014

Security Ninja

View Profile