The PCI DSS and File Integrity MonitoringUsing FIM, or file integrity monitoring has long been established as a keystone of information security best practices. Even so, there are still a number of common misunderstandings about why FIM is important and what it can deliver.
Ironically, the key contributor to this confusion is the same security standard that introduces most people to FIM in the first place by mandating the use of it - the PCI DSS.
PCI DSS Requirement 11.5 specifically uses the term 'file integrity monitoring' in relation to the need to "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"
As such, since the term 'file integrity monitoring' is only mentioned in requirement 11.5, one could be forgiven for concluding that this is the only part FIM has to play within the PCI DSS.
In fact, the application of FIM is and should be much more widespread in underpinning a solid secure posture for an IT estate. For example, other key requirements of the PCI data security standard are all best addressed using file integrity monitoring technology such as "Establish firewall and router configuration standards" (Req 1), "Develop configuration standards for all system components" (Req 2), "Develop and maintain secure systems and applications" (Req 6), "Restrict access to cardholder data by business need to know" (Req 7), Ensure proper user identification and authentication management for nonconsumer users and administrators on all system components" (Req 8), "Regularly test security systems and processes" (Req 11).
Within the confines of Requirement 11.5 only, many interpret this requirement as a simple 'has the file changed since last week?' and, taken in isolation, this would be a legitimate conclusion to reach. However, as highlighted earlier, the PCI DSS is a network of linked and overlapping requirements, and the role for file integrity analysis is much broader, underpinning other requirements for configuration hardening, configuration standards enforcement and change management.
But this isn't just an issue with how merchants read and interpret the PCI DSS. The new wave of SIEM vendors in particular are keen to take this narrow definition as 'secure enough' and for good, if selfish, reasons.
Do everything with SIEM - or is FIM + SIEM the right solution?
PCI requirement 10 is all about logging and the need to generate the necessary security events, backup log files and analyze the details and patterns. In this respect a logging system is going to be an essential component of your PCI DSS toolset.
SIEM or Event log management systems all rely on some kind of agent or polled-WMI method for watching log files. When the log file has new events appended to it, these new events are picked up by the SIEM system, backed up centrally and analyzed for either explicit evidence of security incidents or just unusual activity levels of any kind that may indicate a security incident. This approach has been expanded by many of the SIEM product vendors to provide a basic FIM test on system and configuration files and determine whether any files have changed or not.
A changed system file could reveal that a Trojan or other malware has infiltrated the host system, while a changed configuration file could weaken the host's inherently secure 'hardened' state making it more prone to attack. The PCI DSS requirement 11.5 mentioned earlier does use the word 'unauthorized' so there is a subtle reference to the need to operate a Change Management Process. Unless you can categorize or define certain changes as 'Planned', 'Authorized' or expected in some way, you have no way to label other changes as 'unauthorized' as is required by the standard.
So in one respect, this level of FIM is a good means of protecting your secure infrastructure. However, in practice, in the real-world, 'black and white' file integrity monitoring of this kind is pretty unhelpful and usually ends up giving the Information Security Team a stream of 'noise' - too many spurious and confusing alerts, usually masking the genuine security threats.
Potential security events? Yes.
Useful, categorized and intelligently assessed security events? No.
So if this 'changed/not changed' level of FIM is the black and white view, what is the Technicolor alternative? If we now talk about true Enterprise FIM (to draw a distinction from basic, SIEM-style FIM), this superior level of FIM provides file changes that have been automatically assessed in context - is this a good change or a bad change?
For example, if a Group Policy Security Setting is changed, how do you know if this is increasing or decreasing the policy's protection? Enterprise FIM will not only report the change, but expose the exact details of what the change is, was it a planned or unplanned change, and whether this violates or complies with your adopted Hardened Build Standard.
Better still, Enterprise FIM can give you an immediate snapshot of whether databases, servers, EPoS systems, workstations, routers and firewalls are secure - configured within compliance of your Hardened Build Standard or not. By contrast, a SIEM system is completely blind to how systems are configured unless a change occurs.
Conclusion
The real message is that trying to meet your responsibilities with respect to PCI Compliance requires an inclusive understanding of all PCI requirements. Requirements taken in isolation and too literally may leave you with a 'noisy' PCI solution, helping to mask rather than expose potential security threats. In conclusion, there are no short cuts in security - you will need the right tools for the job. A good SIEM system is essential for addressing Requirement 10, but an Enterprise FIM system will give you so much more than just ticking the box for Req 11.5.
Full color is so much better than black and white.
No comments:
Post a Comment