The correct way to treat these reports is to review them (after all, who knows...) and try to educate those customers who send you bogus reports: explain why they're bogus, why reverse engineering doesn't usually provide good leads, explain them what easier steps they can take for additional security, and maybe remind them about that EULA. This can be done on an individual basis, politely, and Oracle, who seems to employ half the salespeople in this world, certainly has the resources to do so. If they can call me every two months to remind me about their great offers, they can write the standard answer that almost every such report warrants.
But no, instead they chose to dump a load of shit in the form of this blogpost:
1. It's written in the kind of condescending tone that makes you want to punch your interlocutor in the face. Such as: " That said, you would think that before gearing up to run that extra mile, customers would already have ensured they’ve identified their critical systems, encrypted sensitive data, applied all relevant patches, be on a supported product release, use tools to ensure configurations are locked down – in short, the usual security hygiene – before they attempt to find zero day vulnerabilities in the products they are using.". Surprise, surprise: a lot of people who start reverse-engineering binaries are either a) extremely security-conscious people, who, yes, already do those things, or b) extremely good programmers who work for people who -- again -- already do those things! There are exceptions, of course, but assuming that everyone who submits such a report is one of those imbeciles who dreams of Matrix hackers but runs a company where no computer has an antivirus installed is naive.
Or: "there are a lot of things a customer can do like, gosh, actually talking to suppliers about their assurance programs etc.". This sort of crap belongs on a cocky teenager's blog, not on a serious company's website.
2. It's all the more insulting to whine about it when the subtle message you're trying to convey is that zero-day threats aren't that a big deal: "And in fact, there are a lot of data breaches that would be prevented by doing all that stuff, as unsexy as it is, instead of hyperventilating that the Big Bad Advanced Persistent Threat using a zero-day is out to get me!". Yes, it's no problem to state this when you're some random blogger. It is a problem to state this when you're CSO of the company famous for producing the one plugin that's recommended to be disabled by default.
3. Because the argument about the license agreement is childish. After explaining in detail how, even if you were right, you're getting a threatening letter about the license agreement, a requirement to destroy all proof of reverse engineering and so on, she goes on to throw this gem:
"The main reason is that, when I see a spike in X, I try to get ahead of it. I don’t want more rounds of “you broke the license agreement,” “no, we didn’t,” yes, you did,” “no, we didn’t.” I’d rather spend my time, and my team’s time, working on helping development improve our code than argue with people about where the license agreement lines are. "
Well how about skipping that debate and fixing your fucking code, eh?
To put it in the same line as her argument, there are a lot of things Oracle can do in order to reduce the amount of false positives they get, such as fixing their disastrous security track record, improving their communication with the security community (no, blog posts like these don't count as communication for the same reason why hanging out a "fuck you" banner outside your office doesn't exactly count as better communicating with your colleagues, either) and so on. If people had better reasons to trust Oracle, there would be a lot less effort of this kind, too.
4. The analogies being used are demeaning to anyone who doesn't work in sales. Like this:
> Q. But one of the issues I found was an actual security vulnerability so that justifies reverse engineering, right?
> A. Sigh. At the risk of being repetitive, no, it doesn’t, just like you can’t break into a house because someone left a window or door unlocked.
Someone missed their first tech evangelism class, where they use that analogy for exploting, not reporting vulnerabilities.
Is it also wrong to call someone and tell them they left their door unlocked because their dog ran into it and it opened?
The whole things reads like "you guys are like the worst customers ever. We're smarter than you, we have lawyers and we knowz securitiez. Now shut the fuck up."
Sales people are unusable for educating customers, and they're busy with using Licensing Breach Notices to boost sales of cloud services anyway (http://thestack.com/oracle-breach-notice-cloud-services-1007...).
I do agree with you that the blog post seems written in a bit condescending way (it's difficult for me to judge, as I'm not a native speaker).
And I do agree that some of the arguments are misleading - the fact that many breaches are caused by lack of basic security practices does not make zero-days insignificant. And the "assurance programs" guarantee nothing if you fix the issues poorly (nice example from DEFCON 22: https://defcon.org/html/defcon-22/dc-22-speakers.html#Litchf...).
What I perfonally find the funniest about the whole "reverse engineering prohibited" clause is that the bad guys don't give a shit - they'll reverse engineer it anyway, because no one will find out. So the only "victim" is the customer who accepted the licensing agreement, and it does not matter if the purpose was to lower the number of reports or protect the source code.
But I'm still astonished people are surprised by the stupidity of Oracle licensing terms. Bullshit like that blog post is actually one of the main reasons why I stopped working with Oracle products and went full open-source.
Because if they don't, stuff like this happens: they get blamed for any trivial data breach that happened through some of their programs -- even if the problem wasn't that it sucked, it was that the password was admin123.
It's not glamorous and we can all agree that, as long as we're talking about responsible users, it shouldn't be Oracle's job to do this kind of education. However, exploiting users' ignorance is an integral part of their business model; they're consciously targeting them -- it's up to them to deal with all the consequences that brings.