Pain Comes Immediately – Secure Development Takes Time

Tuesday, April 17, 2012

Alexander Rothacker

B451da363bb08b9a81ceadbadb5133ef

I recently came upon a blog post by Adrian Lane of Securosis titled ‘Pain comes instantly – fixes come later’, in which he comments on yet another blog post ‘Pain comes instantly’ by Oracle’s CSO, Mary Ann Davidson.

Anything ‘Oracle security’ always gets me curious, so I went ahead and worked my way through both articles. Let’s just say one of them is a rather lengthy read.

The core point of Mary Ann Davidson’s post is an objection she has with some rules in the PCI PA DSS Vendor Release Agreement. According to her post, the VRA requires a vendor of an approved product to ‘tell all’ to PCI about any known security vulnerability and associated security breaches ASAP to PCI — including specific details of a security breach, exploit information and technical details of the vulnerability, and whether or not there is any mitigation or patch available.

Now, once the PCI council has this information, it can distribute it to all PA-QSAs and the exploit details are thus widely available to a community of people that’s too large to be guaranteed to keep that kind of secret.

She has a valid point here, and Microsoft’s recent MAPP debacle does show that a secret is not a secret once too many parties know about it. Once exploit information is widely available, even to a supposedly vetted group of people, it has a good chance of becoming  public and someone  is very likely going to use it to their advantage. Payment systems are an especially interesting target for hackers and organized crime, since they provide access to easy money.

So far so good. Now to the parts that I find interesting and where I disagree with her.

For starters, Oracle has only three products that are vetted by PA-DSS and that would fall under the aforementioned agreement. All three are part of the E-Business Suites Retail In-Store line of products. Oracle’s flagship database product is expressly NOT a payment application for the purpose of PA-DSS. It only falls under PCI-DSS when part of a third-party custom payment system implementation, but in that case does still not fall under the VRA. Thus, I’m surprised that this is worth creating such a ruckus by Oracle senior management.

My next point is, when reading the PCI VRA section 2(a)(iii) and (iv), it is not quite as cut-and-dry as described in her post, but leaves enough room for interpretation that a PA-DSS vendor could keep the juicy details of a vulnerability under wraps well until a proper patch is made available, at which point (and in most cases) a skilled hacker would be able to devise an exploit from analyzing the patch anyway. I also fail to find language in this section stating that PCI will pass any exploit information on to any and all QSAs or even the smaller community of PA-QSAs, but they could probably be more clear on how that data would be disseminated.

Personally, I have always felt that once a patch to a vulnerability is released, the vendor should give as much guidance as possible to its customer base so that they can make an informed decision on how to mitigate the vulnerability — may it be a workaround, such as disabling some functionality, configuring compensating controls like activity monitoring, and of course properly prioritizing the deployment of patches.

I think Microsoft has really stepped up to the plate and their security bulletins clearly show the way. They are full of useful information for security practitioners and system administrators, giving detailed guidance on the impact of a vulnerability, how to apply the fix and how to temporarily mitigate it. Oracle, on the other hand, has always been rather tight-lipped about vulnerability fixes and the information included in their quarterly Critical Patch Update information is of limited use.

Another great point was discussed in Adrian Lane’s post. Oracle is not always the quickest when it comes to turning around fixes reported to them by third parties. TeamSHATTER has reported well over a hundred vulnerabilities to Oracle in the past seven years. While some of them have been fixed expeditiously, others have taken their sweet time. Sometimes well over a year.

PCI-DSS, as well as PA-DSS, has some guidelines on coding practices and code review, especially addressing issues related to prevention of code injections, buffer overflows, XSS and other common attack vectors. Researchers are frequently finding vulnerabilities for all of these coding issues in Oracle products — including new product lines, not just older products that suffer from code that predates modern secure coding practices.

If there is one change that I think would be worthwhile for PCI to consider, that would be a requirement for all PA-DSS certified products to produce timely fixes to vulnerabilities reported to the vendor. I think a six-month maximum turnaround would be a desirable timeframe.

Cross-posted from TeamShatter

Possibly Related Articles:
12514
General
Information Security
breaches PCI DSS Compliance Databases Vulnerabilities Patch Management Secure Coding QSA hackers vendors
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.