In the past few days there has been substantial media coverage over a rather serious flaw discovered by Esteban Martinez Fayo at Appsec in a current major database platform. All enterprises using Oracle 11G (release 1 and 2) databases need to be concerned - especially given the fact that this opens up another convenient attack point for malware in the datacenter or motivated insiders to steal the enterprise crown jewels - sensitive data. The method of attack has been covered quite extensively to date - along with industry concerns.
More details on this attack are due to be revealed in October, but the net is that this attack leaves data vulnerable to compromise and without a huge amount of effort to get it. While it appears one version of Oracle was patched, prior versions still in popular use are not - no doubt the source of heartburn for many CISO's and DBA's right now. This creates a huge problem for enterprises who:
a) Need to stay compliant to regulations like PCI DSS, and,
b) Don't want to put their data at risk.
What's concerning about this case is that the vulnerability was reported as far back as 2010. That's a lot of time for attacks to have happened - and leaves a lot of open questions on how to solve the problem and avoid similar issues arising again. This isn't the first time a database has been compromised along these lines - but fortunately there are alternatives to relieve the pain - and risk - more easily.
What are the headaches this situation causes?
From a compliance perspective there's an immediate dilemma: Specifically, as of June 30th 2012, PCI DSS 2.0 requires a risk registry of vulnerabilities to be established and patches applied to critical issues applied within 1 month - the application of patches from vendors to fix them - especially when they are flagged as critical. A vulnerability that lets hackers access clear data probably falls into that category.
PCI DSS 2.0 Requirement 6.1 states:
6.1 Ensure that all system components and software are protected from known
vulnerabilities by having the latest vendor-supplied security patches
installed. Install critical security patches within one month of release.
There are statements in PCI DSS about extending this time period for less critical systems - but in this case, this is a high severity vulnerability. However, so far, it seems that no such patch exists for the older versions (e.g. 11.1) - that's a lot of databases, and a whole lot more data.
Cardholder data is one type at risk, but this vulnerability isnt picky about letting out all that nice attractive personal data too.
The second issue is that an attacker doesn't need to do much in order to get access to clear data - from insiders or external attackers where the database authentication interface is exposed. That's most applications using the database. That is billions of records. Billions.
Can it be fixed? Yes.
One popular approach to mitigate this in a more comprehensive way is data-centric security. The approach, using proven methods like NIST recognized FFX mode AES - Format Preserving Encryption, protects the data from capture, in motion, at rest, and up to the point of use by trusted applications. So even if the database itself is compromised the attacker gets nothing of value - patched or unpatched. The fact that the data is protected yet format preserving means database schema preserving too and in most cases applications function on FPE protected data work as before it was applied - reducing application changes to a minimum. Protected data can preserve referential integrity or not by policy control, and stateless key management means no complicated key storage and key management pain. Its also proven, with published proofs of security - essential for any safe harbor or compliance uses. Unproven, unpublished approaches are as risky as unpatched vulnerable databases.
So, by moving the data protection outside and independently of the database, enterprises are no longer at the mercy of relentless database vulnerability patching or the lack of a patch as their last defense against ever increasingly sophisticated attackers. A lot of very large enterprises have already embraced this approach - particularly as its can be applied from mainframe to mobile, and from enterprise to cloud - under one consistent policy control platform - at any scale.
Data-centric protection - reaches the parts other protection technologies cannot reach.
As has been proven time and again, trying to protect information by building walls around it that have lots of holes in them is no longer feasible - and waiting for patches that may never arrive is not a strategy for breach avoidance - on the contrary, its a homing beacon for malware. Proven and strong Data-centric security is now an accepted best practice to thwart these threats - and the benefits in reducing compliance costs and data breach risks are enormous. Lastly, the good guys running the databases can focus on the business of enabling the enterprise and gearing up for the cloud instead of wearing their patience thin on the patch treadmill and losing sleep at night over the concerns about unpatched, unprotected data.
Please don't hesitate to reach out to me at firstname.lastname@example.org if you want to learn of a refreshing and relieving approach to data breach risks like this - or take a look at Voltage SecureData Enterprise - https://www.voltage.com/products/data_protection.htm