Wednesday, 19 June 2013

File Integrity Monitoring - View Security Incidents in Black and White or in Glorious Technicolor?

FIM solutionsThe PCI DSS and File Integrity Monitoring
Using 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.


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.

Wednesday, 12 June 2013

File Integrity Monitoring - FIM Could Just Save Your Business

Busted! The Citadel Cybercrime Operation

No guns were used, no doors forced open, and no masks or disguises were used, but up to $500Million has been stolen from businesses and individuals around the world. Reuters reported last week that one of the worlds biggest ever cybercrime rings has just been shut down. The Citadel botnet operation, first exposed in August last year, shows that anyone who wants to think big when it comes to cybercrime can make truckloads of money without even leaving home.

It's a familiar story of basic identity theft - PC's used to access on-line bank accounts were infiltrated by keylogging malware known as Citadel. This allowed security credentials to be stolen and then used to steal money from the victims' bank accounts. The malware had been in operation for up to 18 months and had affected up to 5 million PC's.

Like any malware, until it has been discovered, isolated and understood, anti-virus technology cannot tackle malware like Citadel. So-called 'zero day' malware can operate undetected until such time as an anti-virus definition has been formulated to recognize the malware files and remove them.

This is why file integrity monitoring software is also an essential defense measure against malware. File integrity monitoring or FIM technology works on a 'zero tolerance' basis, reporting any changes to operating system and program filesystems. FIM ensures that nothing changes on your protected systems without being reported for validation, for example, a Windows Update will result in file changes, but provided you are controlling when and how updates gets applied, you can then isolate any unexpected or unplanned changes, which could be evidence of a malware infection. Good FIM systems filter out expected, regular filechanges and focus attention on those system and configuration files which, under normal circumstances, do not change.

A victimless crime? Maybe not if you're a business that has been affected

In a situation like this, banks will usually try and unravel the problem between themselves - bank accounts that have been plundered will have had money moved to another bank account and another bank account and so on, and attempts will be made to recover any misappropriated funds. Inevitably some of the cash will have been spent but there is also a good chance that large sums can be recovered.
Generally speaking, individuals affected by identity theft or credit card fraud will have their funds reimbursed by their bank and the banking system as a whole, so it often feels like a victimless crime has been perpetrated.

Worryingly though, in this case, an American Bankers Association spokesman has been reported as saying that 'banks may require business customers to incur the losses'. It isn't clear as to why the banks may be seeking to place blame on business customers in this case. It is reported that Citadel was present in illegally pirated copies of Windows, so the victims may well be guilty of using counterfeit software, but who is to blame, and how far down the line can the blame be passed? The business customer, their supplier of the pirated software, the wholesaler who supplied the supplier?

Either way, any business user of on-line banking technology (and the consensus of estimates suggest that around half of businesses do at least 50% of their banking on-line, but that this is increasing year on year) should be concerned that protecting access to their bank account should be something they take seriously. It could well be that nobody else is looking out for you.


It may still be the case that 'Crime doesn't pay' but it seems that Cybercrime can pay handsomely. But for cybercrime to work, there needs to be a regular supply of victims and in this case, victims not using any kind of file integrity monitoring are leaving themselves exposed to zero-day malware which is currently invisible to anti-virus systems.

Good security is not just about installing AV software or even operating FIM but should be a layered and integrated approach. Leveraging security technology such as AV, FIM, firewalling, IDS and IPS should be done in conjunction with sound operating procedures to harden and patch systems regularly, verified with a separate auditing and governance function.
The biggest security threat is still complacency.