What is File Integrity Monitoring (FIM)?

File Integrity Monitoring (FIM) is a control or process that compares the current state of operating system and/or application software files against a known baseline to validate the integrity of the files (i.e. looking for inconsistencies).

The integrity verification uses a cryptographic hash function to calculate an initial checksum of a file, which is then compared with a newer calculated checksum of the current state of the same file. In essence, a checksum is a small block of data that is derived from another block of data.

In the example below, you will notice that a change from jumped to hopped has resulted in a different checksum:

[the cow jumped over the moon] > [cryptographic hash function] > [5654908665]
[the cow hopped over the moon] > [cryptographic hash function] > [6759085632]

In addition, irrespective of the size of the block of data that is used to derive the checksum, the generated checksum will always be of the same length, as demonstrated below:

[cow] > [cryptographic hash function] > [4563218853]
[the cow jumped] > [cryptographic hash function] > [2963269855]

FIM can either be a manual or an automated process. The Unix cksum manual command will generate a checksum value for a file for each file given in its arguments (e.g. cksum test.txt). Alternatively, an automated process performing file integrity monitoring can be set up to perform such monitoring either randomly, at a predefined period, or in real-time, and of course, it will generate alerts if any inconsistencies are found.

What does File Integrity Monitoring do?

Updates to system configurations, files, and file attributes across your IT infrastructure will be a normal day-to-day business activity. They’re required for continuing business function. However, within those daily updates, there is the possibility of hidden changes that could impact the integrity of data and/or system configuration files. Consequently, if accidental, these changes could reduce the security posture of the business or, if deliberate, indicate a security breach in progress. FIM is a simple way of identifying any changes that could impact the security of the business IT infrastructure.

What are the PCI compliance objectives of File Integrity Monitoring?

• Requirement 10.5: Audit data must be secured so it cannot be altered. In this situation, file integrity monitoring will ensure that any changes to existing audit data will generate alerts.
• Requirement 10.5.5: File integrity monitoring will also ensure that existing log data cannot be changed without generating alerts. However, it is important that any new data being added does not cause an alert to be generated.
• Requirement 11.5: For this requirement, file integrity monitoring needs to alert you to unauthorised modifications of critical system files, configuration files, or content files. Furthermore, file integrity monitoring should also perform critical file comparisons at least weekly.

In addition, Requirement 12.10.5 makes it clear any incident response plan must include alerts from security monitoring systems, including file integrity monitoring systems.

What are the problems with File Integrity Monitoring?

File object selection

This is probably the most difficult question to answer, but the PCI DSS can help. Take a look at Requirement 10.5/10.5.5. Audit data repository/storage would be the first area to deploy file integrity monitoring, even if access to audit data is restricted to specific roles/named individuals. Ensuring that any modifications to audit data are identified and alerted upon would be your priority.

Then we have Requirement 11.5; alerting on changes to critical system files, configuration files, or content files. Critical files normally do not regularly change. However, any modification could indicate a system compromise. Most FIM solutions will come pre-configured with critical files for conventional operating systems. Other critical files, such as those for business applications, must be evaluated and defined by the business.

Lastly, we have Requirement 10.8. While this is a requirement for service providers, it makes sense to include it within all file integrity monitoring activities, whether a service provider or merchant. For example, you could deploy file integrity monitoring across anti-virus/malware clients on local machines. Obviously, as the anti-virus updates, there would be a lot of alerts generated. But, conversely, a lack of a generated alert could indicate that a particular anti-virus client had not been updated.

False positives/false negatives

Probably the next most difficult question to address, which (if left unchecked) can lead to alerting fatigue. There is always a trade-off between too many alerts which serve no benefit, and not receiving enough appropriate alerts. In essence, this boils down to file object selection, understanding your PCI DSS obligations, what you want FIM to achieve, and what the FIM solution can achieve. Cheap is not always best. In this situation, it might be beneficial to have a chat with a QSA company.

Alerting fatigue

Leading on from above, alerting fatigue is always a real danger with too many false positives. Again, this is down to file object selection. However, making use of file integrity monitoring products that come pre-configured with critical files for operating systems would help enormously with this problem.

How do you effectively deploy File Integrity Monitoring?

In essence, what we are talking about here is the business having a complete and detailed understanding of your PCI DSS environment, and those requirements you must meet to remain (or become) PCI DSS compliant. As mentioned, most file integrity monitoring products usually come pre-configured with critical files. However, other critical files, such as those for custom applications, must be evaluated and defined by the business. In this situation, it might be beneficial to seek expert advice.

Furthermore, to ensure that the FIM solution provides an effective alerting mechanism, elements such as false positive/false negatives and alerting fatigue must be kept to a minimum. To achieve this, most file integrity monitoring allows for the development of a system baseline, and/or learning functionality. Over a period of time, this fine-tunes the response of the file integrity monitoring solution to meet the requirements of the business. Another way of achieving this would be to make use of a service provider that can offer a Security Operations Centre (SOC), and they would then do all the heavy lifting.

Conclusions

If implemented and deployed appropriately, file integrity monitoring is a powerful way of checking the well-being of your PCI DSS environment. Even if you are not required to deploy file integrity monitoring, the tool offers an insightful understanding of the operation and status of your IT and data assets.

Nettitude has been a registered Qualified Security Assessor (QSA) company for over 10 years. We have a reputation with our clients for taking a pragmatic and realistic approach to PCI DSS, and our history of delivering PCI DSS assessments means we have likely faced many of the challenges your organisation must overcome before. Find out more about our PCI DSS services here