Although FIM or File-Integrity Monitoring is only specifically mentioned in two PCI DSS sub-requirements (10.5.5 and 11.5), it is actually one of the most important measures to protect business systems from card data theft.
What is it and why is it important?
File integrity monitoring systems are designed to protect card data from theft. The main purpose of FIM is to detect changes to files and their associated attributes. However, this article provides the background to three different dimensions of monitoring file integrity, namely:
– Secure hash-based FIM, efficiently used to monitor the integrity of system files
– file content integrity monitoring, useful for firewall, router and web server configuration files
– monitoring of access to files and/or folders, vital to protect sensitive data
hash-based secure FIM
Within a PCI DSS context, the main files of concern include:
– System files, for example, anything residing in the Windows/System32 or SysWOW64 folder, program files, or Linux/Unix kernel key files
The goal of any hash-based file integrity monitoring system as a security measure is to ensure that only expected, desirable, and planned changes are made to scope devices. The reason for doing this is to prevent data theft from the card through malware or program modifications.
Imagine a Trojan being installed on a card transaction server: the Trojan could be used to transfer card details off the server. Similarly, a packet sniffer program could be placed on an EPoS device to capture card data; if it were disguised as a common Windows or Unix process with the same program and process names, it would be hard to detect. For a more sophisticated trick, how about implanting a ‘back door’ in a key program file to allow access to card data?
These are all examples of security incidents where file integrity monitoring is essential to identify the threat.
Remember that antivirus defenses typically only know about 70% of the world’s malware and an organization affected by a zero-day attack (zero-day marks the time a new form of malware is first identified; only then can a se formulate a remediation or mitigation strategy, but it can take days or weeks before all devices are updated to protect them.
How far should the FIM measures be taken?
As a starting point, it is essential to monitor the Windows/System32 or SysWOW64 folders, in addition to the main card data processing application program folders. For these locations, run a daily inventory of all system files within these folders and identify all additions, deletions, and changes. Additions and deletions are relatively easy to identify and evaluate, but how should changes be treated, and how do you evaluate the significance of a subtle change, such as a file attribute? The answer is that ANY file changes to these critical locations should be treated with equal importance. Most high-profile PCI DSS security breaches have been instigated through an ‘inside man’, usually a trusted employee with privileged administrator rights. For today’s cybercrime there are no rules.
The industry-recognized FIM approach is to track all file attributes and record a secure hash. Any change to the hash when the file integrity check is rerun is a red flag situation: when using SHA1 or MD5, even a microscopic change to a file on the system will denote a clear change in the hash value. When FIM is used to control the security of key system files, there should never be any unplanned or unexpected changes; if there are, it could be a Trojan or a backdoor-enabled version of a system file.
This is why it is also crucial to use FIM in conjunction with a “closed loop” change management system: planned changes must be scheduled and associated file integrity changes must be recorded and attached to the planned change log.
Config file/file content integrity monitoring
While a secure hash checksum is a foolproof means of identifying any changes to the system file, this only tells us that a change has been made to the file, not what that change is. Sure, for an executable in binary format, this is the only meaningful way to convey that a change has been made, but a more valuable means of monitoring file integrity for ‘readable’ files is to keep track of the file’s contents. This way, if a change is made to the file, the exact change made to the readable content can be reported.
For example, the FIM system can capture a web configuration file (php, aspnet, js or javascript, XML configuration) and record it as readable text; thereafter, changes will be detected and reported directly.
Similarly, if a firewall ACL was edited to allow access to key servers, or the startup configuration of a Cisco router was changed, then this could allow a hacker as long as it takes to break in. to a card data server.
One final point about monitoring file content integrity: Within the scope of security/compliance policy, Windows registry keys and values often fall under the heading of FIM. These should be monitored for changes, as many hacks involve modifying registry settings. Similarly, several common vulnerabilities can be identified by analyzing registry settings.
File and/or Folder Access Monitoring
The final consideration for file integrity monitoring is how to handle other file types that are not suitable for secure hashing or content tracking. For example, because a log file, database file, etc. will always change, both the content and the hash will also constantly change. Good file integrity monitoring technology will allow these files to be excluded from any FIM template.
However, card data can still be stolen without detection unless other measures are implemented. As an example scenario, in a retail EPoS system, a card transaction or reconciliation file is created and sent to a central payment server on a scheduled basis during the trading day. The file will always change; maybe a new file is created each time with a timestamped name, so everything about the file is always changing.
The file would be stored on an EPoS device in a secure folder to prevent user access to the contents. However, an ‘inside man’ with administrator rights to the folder could view the transaction file and copy the data without necessarily changing the file or its attributes. Therefore, the final dimension for File Integrity Monitoring is to generate an alert when any access to these files or folders is detected, and to provide a full audit trail by account name of who has accessed the data.
Much of PCI DSS Requirement 10 is concerned with recording audit trails to enable forensic analysis of any breaches after the event and to establish the vector and perpetrators of any attacks.
