Evan Schuman's StorefrontBacktalk

Davidson said that Oracle itself practices a strict “need to know” approach with its security information. “We use our own row level access control to limit access to security bugs in our bug database, and thus less than one percent of development has access to this information,” she wrote.

She also shared a global example of where Oracle was hurt by excessive security info sharing.

“One of the UK intelligence agencies had information about a non-public security vulnerability in an Oracle product that they circulated among other UK and Commonwealth defense and intelligence entities. Nobody, it should be pointed out, bothered to report the problem to Oracle, even though only Oracle could produce a patch,” Davidson wrote. “The vulnerability was finally reported to Oracle by (drum roll) a U.S.-based commercial company, to whom the information had leaked. Note: every time I tell this story, the MI-whatever agency that created the problem gets a bit shirty with us. I know they meant well and have improved their vulnerability handling/sharing processes but, dudes, next time you find an Oracle vulnerability, try reporting it to us first before blabbing to lots of people who can’t actually fix the problem.”

Oracle also dealt with the pragmatic side of security patches, which is that it’s most dangerous during the window after a patch has been publicly released and before everyone has had a chance to implement the patch. Davidson specifically argued that this policy from the PCI Council actually sharply increases that period of vulnerability.

The “current requirement for the widespread distribution of security vulnerability exploit details—at any time, but particularly before a vendor can issue a patch or a workaround—is very poor public policy. It effectively publicizes information of great value to potential attackers while not providing compensating benefits—actually, any benefits—to payment card merchants or consumers. In fact, it magnifies the risk to payment card merchants and consumers,” she wrote. “The risk is most prominent in the time before a patch has been released, since customers often have little option but to continue using an application or system despite the risks. However, the risk is not limited to the time before a patch is issued: customers often need days, or weeks, to apply patches to systems, based upon the complexity of the issue and dependence on surrounding programs. Rather than decreasing the available window of exploit, this requirement increases the available window of exploit, both as to time available to exploit a vulnerability and the ease with which it can be exploited. Also, why would hackers focus on finding new vulnerabilities to exploit if they can get “EZHack” handed to them in such a manner: a) a vulnerability; b) in a payment application; c) with exploit code. It’s the Hacking Trifecta. It’s fair to say that this is probably the exact opposite of what PCI—or any of us—would want.”

Davidson painted the picture of a conscientious vendor—which Oracle often actually is, for whatever that is worth—who tends to security issues quickly and professionally. But that’s not representative of the total vendor community. Given the seriousness of security, more information is often better.

Still, Oracle’s argument that current PCI policy is sharing such data with far too many people is quite valid. Perhaps the best resolution is not to spike the policy but to limit the group with access? Perhaps a small group of retail IT security folk, something akin to the U.S. government’s Gang of Eight—a group of congressional leaders who can be briefed on covert actions when wider congressional disclosure would be too dangerous.

Oracle argued in its full post that it has been trying to convince the PCI Council to abandon this policy for an extended period but that the Oracle questions “have gone, to date, unanswered.”

A legitimate reason is the nature of the PCI Council. Given the number of people involved, it’s a body that can’t move very quickly. More to the point, the people who need to approve such a change are the very same ones who receive that information now and would be deprived of it if the provision was stricken.

Put another way, this request is saying to the PCI decision-making groups: “We don’t trust you. Change the rule that says we have to tell you everything.”

The argument that “this is the right thing to do” is a lot more effective when it’s not directed at people you’ve just insulted. Gosh, I can’t envision what could possibly be holding things up.