Tuesday, 1 February 2011

File Integrity Monitoring - PCI DSS Requirements 10, 10.5.5 and 11.5

Although FIM or File Integrity Monitoring is only mentioned specifically in two sub-requirements of the PCI DSS (10.5.5 and 11.5), it is actually one of the more important measures in securing 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 primary purpose of FIM is to detect changes to files and their associated attributes. However, this article provides the background to three different dimensions to file integrity monitoring, namely

secure hash-based FIM, used predominantly for system file integrity monitoring

Secure Hash Based FIM

Within a PCI DSS context, the main files of concern include

System files e.g. anything that resides in the Windows/System32 or SysWOW64 folder, program files, or for Linux/Unix key kernel files

The objective for any hash-based file integrity monitoring system as a security measure is to ensure that only expected, desirable and planned changes are made to in scope devices. The reason for doing this is to prevent card data theft via malware or program modifications.

Imagine that a Trojan is installed onto a Card Transaction server – the Trojan could be used to transfer card details off the server. Similarly, a packet sniffer program could be located onto an EPoS device to capture card data – if it was disguised as a common Windows or Unix process with the same program and process names then it would be hard to detect. For a more sophisticated hack, what about implanting a ‘backdoor’ into a key program file to allow access to card data??

These are all examples of security incidents where Windows File Integrity Monitoring is essential in identifying the threat. Remember that anti-virus defenses are typically only aware of 70% of the world’s malware and an organization hit by a zero-day attack (zero-day marks the point in time when a new form of malware is first identified – only then can a remediation or mitigation strategy be formulated but it can be days or weeks before all devices are updated to protect them.

How far should FIM measures be taken?

As a starting point, when implementing file integrity monitoring for Windows, it is essential to monitor the Windows/System32 or SysWOW64 folders. Similarly for Unix and Linux systems, the /etc files and other core binary paths must be monitored, plus the main Card Data Processing Application Program Folders. For these locations, running a daily inventory of all system files within these folders and identifying all additions, deletions and changes. Additions and Deletions are relatively straightforward to identify and evaluate, but how should changes be treated, and how do you assess the significance of a subtle change, such as a file attribute? The answer is that ANY windows file integrity change in these critical locations must be treated with equal importance. Most high-profile PCI DSS security breaches have been instigated via an ‘inside man’ – typically a trusted employee with privileged admin rights. For today’s cybercrime there are no rules.

Any change to the hash when the file-integrity check is re-run is a red alert situation – using SHA1 or MD5, even a microscopic change to a system file will denote a clear change to the hash value. When using FIM to govern the security of key system files there should never be any unplanned or unexpected changes – if there are, it could be a Trojan or backdoor-enabled version of a system file.

Which is why it also crucial to use FIM in conjunction with a ‘closed loop’ change management system – planned changes should be scheduled and the associated File Integrity changes logged and appended to the Planned Change record.

File Content/Config File Integrity Monitoring

Whilst a secure hash checksum is an infallible means of identifying any system file changes, this does only tell us that a change has been made to the file, not what that change is. Sure, for a binary-format executable this is the only meaningful way of conveying that a change has been made, but a more valuable means of file integrity monitoring for ‘readable’ files is to keep a record of the file contents. This way, if a change is made to the file, the exact change made to the readable content can be reported.

For instance, a web configuration file (php, aspnet, js or javascript, XML config) can be captured by the FIM system and recorded as readable text; thereafter changes will be detected and reported directly.

Similarly, if a firewall access control list was edited to allow access to key servers, or a Cisco router startup config altered, then this could allow a hacker all the time needed to break into a card data server

One final point on file contents integrity monitoring - Within the Security Policy/Compliance arena, Windows Registry keys and values are often included under the heading of FIM. These need to be monitored for changes as many hacks involve modifying registry settings. Similarly, a number of common vulnerabilities can be identified by analysis of registry settings.

File and/or Folder Access Monitoring

The final consideration for file integrity monitoring is how to handle other file types not suitable for secure hash value or contents tracking. For example, because a log file, database file etc will always be changing, both the contents and the hash will also be constantly changing. 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 put in place. As an example scenario, in an EPoS retail system, a card transaction or reconciliation file is created and forwarded to a central payments server on a scheduled basis throughout the trading day. The file will always be changing – maybe a new file is created every time with a time stamped 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 Admin 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 had access to the data. Much of PCI DSS Requirement 10 is concerned with recording audit trails to allow a forensic analysis of any breach after the event and establish the vector and perpetrator of any attack. Much more detail on this requirement can be found here - 'Event Log Monitoring and the PCI DSS'