Salient Statements (no judgement yet)
- Customers are worried about breaches.
- Reverse engineering vendor code to find vulnerabilities is not the most effective way to protect your organization.
- The Oracle EULA prohibits reverse engineering.
- Customers break this provision in the EULA enough for the CSO to be aware of it.
- Oracle has a “robust” software assurance program that obviates the need for third-parties to find vulnerabilities.
- A high percentage of the reported issues are false positives or already discovered internally.
- The reverse engineering clause in the EULA isn’t about keeping security researchers out; it’s about intellectual property.
- Bug bounty programs are not an economically advantageous vendor investment.
Good Risk ManagementJennifer Granick (@granick) recently pointed out in her Black Hat keynote that human beings are pretty bad at risk management, citing that we’re afraid of sharks but not cows, while cows actually kill more people than sharks. Davidson’s point that spending time finding vulnerabilities in Oracle’s code isn’t the most effective means of securing your organization seems demonstrably accurate at face value, but implies that there’s a real-world tradeoff going on, i.e. researchers are spending time on reverse engineering instead of other security measures that are more effective. I won’t declare that the opposite is categorically true, but it seems dubious that there’s a one-for-one tradeoff here. It’s more likely that this reverse engineering is being done by dedicated security researchers paid to do just this kind of work, or as an extra-curricular activity. That, frankly, draws out the question of how this time is being funded by the market and why. We might legitimately ask ourselves as an industry why we have so much third-party security defect discovery going on.
Vendor Software Assurance and TransparencyThere’s a common claim that this research is required to ensure secure software in the market. The counter-argument put forth by Davidson is that Oracle does this work already, and that only Oracle can do it effectively because of their inside knowledge of the code. I actually really like this point. It’s true that the original vendor can perform more effective software assurance than an outsider. The problem is that most simply don’t. While Oracle may claim they are an exception, the reality of this fact is demonstrated by the continuous publication of newly discovered vulnerabilities. Customers can actually make a difference here by following Davidson’s advice and asking about software assurance programs when they make a purchase. Sticking a question about how the vendor ensures security of their developed code in every RFP you issue will make a material impact. Still, if we assume that Oracle does actually do an exceptional job on software assurance, then the impact of security defects found by reverse engineering should be minimal, right? It’s not, and that, in part is because of ....
Low Quality Defect ReportingSteve Christey Coley (@SushiDude) gets the credit for sparking this paragraph:
If you’ve ever worked in a tech support or QA role, you are intimately familiar with the impact of low quality defect reporting. “It’s broken” simply doesn’t cut it, and neither does cutting and pasting an error message with no context or reproduction. With a customer-base the size of Oracle’s, triaging and responding to security defect reports might very well be a significant time-suck. In fact, it really must be for the CSO to spend time penning individual letters out to customers. Is it appropriate for a vendor to reject a low quality defect report and ask for more details? Doesn’t that apply to security defects as well, or is there a requirement for a higher standard of care?
A hidden story behind recent Oracle news is the avalanche of low-quality vuln reports. Growing pains of an entire discipline?— Steve Christey Coley (@SushiDude) August 11, 2015