Reading Uri Rivner's blog this week (http://blogs.rsa.com/rivner/anatomy-of-an-attack/), RSA have been rather brave to disclose how their systems were recently breached.
According to Uri, an Excel attachment with embedded Adobe Flash content was sent to a small group of low profile users within RSA, with the title “2011 Recruitment Plan”. At least one user had opened this attachment to sneak a peak, not knowing that the Flash content contained a 0day exploit that planted a Poison Ivy back door on the machine.
Poison Ivy is a remote access ‘utility' that calls home and opens up a reverse connection over HTTPS back to it's command and control centre.
The one thing that could have stopped this attack would have been the end user, by not opening the attachment.
So why did I mention PCI DSS? Well, being a fully fledged data security standard, it doesn't actually implement any technical controls that would have prevented this type of attack.
Anti-virus wouldn't have worked, as no signatures exist for 0days (although it might have been able to pick up Poison Ivy, depending on how well it were hidden). Event logging wouldn't have helped, apart from after the incident. No signatures in IDS/IPS would have helped, as none exist.
Card data could easily have been exposed if this 0day ended up on a sysadmin or dba's machine at a retailer or service provider – the criminal could have sniffed the credentials used to access card data, poke around the database and extract pretty much what they wanted and send it back out over the HTTPS connection.
The one PCI DSS Control that COULD help is 12.6 – a formal security awareness program that teaches users not to open untrusted attachments. But this control is extremely weak, implying that users only need to be made security aware upon hire, and then annually thereafter.
Furthermore, the PCI SSC have dumped this control under Milestone 6, which Visa are now suggesting that merchants do not have to adopt.
What else do we have. A formal risk assessment under 12.1.2. OK, well that should pick up APTs as being a significant risk as long as the risk assessment is run by somebody that understands the current threat landscape. Again, only need to do it annually and it's been dumped in Milestone 6.
12.5 might also help – assign information security responsibility to a “security-knowledgeable member of management”. So in theory, a security officer would know about APTs and be able to quickly formulate a defence plan against them. But more often than not, security responsibility is assigned to an IT Manager (operations) or a low level member of staff, “just to get through the audit”.
In fact, I'd put my head on the line and publicly state that PCI DSS does not help address emerging threats. It's not due another update for another 3 years and the milestone approach infers that the bits that could actually help merchants deal with emerging threats are tucked away at the end under Milestone 6.
If Visa are now offering safe harbour to merchants that are breached, but are 100% compliant with Milestones 1-4, then if a merchant gets hit with an 0day exploit and gets past a poorly trained end user, then will they seriously be picking up the bill?
If I could change things? Risk assessments, security awareness and security management ownership would be Milestone 1 controls – they are cornerstones to security best practice and they're almost being pushed out of the standard by controls that deal with threats of the past.
If anyone wants to test their exposure to APTs then just ask yourself how easy it would be for a user to install an apparently benign piece of software on their machine. Secondly, ask yourself how easy it would be to get a user to open up a semi-trusted attachment in their Inbox.
Scary, isn't it?