Slashdot Mirror
Oracle's Chief Security Officer Speaks Out
s0u1d13r writes "ZDNet Australia posted a special article from Oracle's CSO regarding the treatment and publishing of exploits and vulnerabilities by security researchers. From the article: 'There's a myth about security researchers that goes like this: Vendors are made up of indifferent slugs who wouldn't fix security vulnerabilities quickly -- if at all -- if it weren't for noble security researchers using the threat of public disclosure to force them to act.' An interesting read from the perspective of one of the largest software vendors accused of ignoring vulnerabilities by software researchers."
Sure, why waste time fixing bugs, when you can attack the researchers whose bug reports make you look bad? People are going to buy Oracle no matter what, so these bugs matter only by requiring the Marketing Department to talk tech, rather than spin the wonders of Oracle that make the Web a safe, peaceful utopia. If Oracle is going to deliver every American our government serial number, its Security chief has to play from the same denial playbook as the Department of Homeland Security to which they'll be charging those fat support contracts.
--
make install -not war
Vendors are made up of indifferent slugs who wouldn't fix security vulnerabilities quickly -- if at all -- if it weren't for noble security researchers using the threat of public disclosure to force them to act.
And... can you demonstrate otherwise?
Because using your formidable public relations abilities to attack messengers, while totally neglecting to use those same abilities to get word out about what administrators should do when flaws arise in your product doesn't really convince me you're interested in security (except to the extent that it effects marketing).
> Don't read the 'article' - don't post stories like this onb /. again please.
Eh? In all seriousness, I've come to expect no better.
The unofficial
In TFA she discusses two sorts: those who play ball, and those who don't. One of the continuing problems with IT security is the fact that the bright folks who can find or fix problems aren't always the ones who understand how really big, clunky corporations work.
The only goal in the article there is to do discourage people from doing the whole "I found a vulnerability, you have 5 days to comply" nonsense. Yeah, sure, it works great if you've got a 1-person operation with no legal team, and no multitiered support system in place to filter out the garbage.
There's some truth to that, yes.
But it's not always the case - and that's the point of this discussion. There are two additional scenarios that I have seen:
1. The "security researcher" discovers a vulnerability and either uses it to leverage a job offer or doesn't inform the vendor and attempts to make a name for himself by disclosing it.
This is the researcher's fault.
2. The vulnerability is reported and the vendor implements a fix days, weeks, or months later. Sometimes a patch might require significant testing and QA before releasing it. Corporate bureaucracy might slow everything down.
This is the vendor's fault, but is not always a matter of indifference.
In one of the deciding factors of my decision to start my own company was watching one of our clients delay a project over one year past the original deadline. It was urgent - privacy and security holes galore - but due to indecision, extended vacations, bureacracy, and plenty of other crap the project was never completed during my time there. I left 11 months past deadline. Apparently they launched it six months later.
Indifference? Nope.
Indecision? Inattentiveness? Incompetence? Yes.
Its not a question of vendors ignoring vulnerabilities. Vendors rarely ignore security issues. Its a question of:
* Inadequate security planning during the development process.
* Vulnerability reports that get stuck in tier 1 tech support instead of reaching someone who can fix them.
* Venders who allow marketing and other non-technical matters to improperly influence security oriented decisions.
If you've ever done commercial software development then you know exactly what I'm talking about.
The security researchers' solution is to instigate a marketing/public relations pressure on the vendors which compels technically reasonable handling of security matters. Its a counterweight to the other improper pressures, and a healthy one.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Whatever.. the same principle applies to nearly every mid-large enterprise in the world.
They don't prioritize security it high enough until something goes wrong. Sure, they may be working on a solution, but it's funny how much more quickly things get done when there's a virus/worm running rampant in your company or a web server was defaced. How many InfoSec departements didn't get the funding they needed until Sarbanes Oxley came around and threatened their CFO and CEO?
The same applies to vulnerability research and disclosure. Light a fire under their ass if you want it done fast.. and when it comes to the security of IP, you do.
Gee, could this be a paper-thinly veiled snipe attack at the author of the recent cisco flaw talk? The oracle people would love to throw their PR spin on this, making these security professionals out to be "those who play ball" and "those who make unreasonable demands based on a 5 day ultimatum".
Guess what, there was no ultimatum in the latest Cisco fiasco. They simply told him he was lying through his teeth, so he told them to go screw themselves and proved that he wasn't lying. I don't see how a time-based ultimatum was involved. They REFUSED to acknowledge the exploit. THAT is why he went public with it. Nice spin oracle, but totaly ignores the most relevant cause for the fiasco: CISCO refused to acknowledge an exploit, NOT CISCO refused to release a timely patch (they did release a patch, later).
Ummm, last time I checked, MOST corporate hacking was done from the INSIDE, NOT the Internet. K. Thanks.
For the most part, credible security researchers follow some variant of this document. Given that:
"1. You should be able to fix this in two days"
No, the document says you need to communicate with the researcher within five days. Microsoft has managed to get responses back to people within twenty four hours -- you can at least talk to people within five times that.
"2. The more notorious I am, the more business I will get"
Frankly, there are absolutely awful security advisories. (That "Monad can be used to write worms" garbage is probably the single most embarassing announcement in the history of our industry, though Secunia's DHS advisory that somehow implied a vuln in LibTiff was remote-critical was pretty bad too). If it's this bad when people talk, imagine how bad it can be from people who don't even try to have a public presence.
That being said -- burning vendors is good for nobody, and I have no particular sympathy for those who ignore the rules and just try to embarass people. But lets be honest -- both parties in the equation can embarass themselves, and the system that's evolved has managed to create the otherwise non-existent cost pressure to solve the problem.
How much money did Oracle make from calling themselves "Unbreakable"? Implies there was a rather significant market desire for what security researchers independently establish.
"3. I should always get credit for vulnerabilities I find"
If you release something you know is bad, and do it anyway because you figure the cost of releasing the product is less than the cost of fixing it -- well, the auto industry has a long and colorful history of doing that, and look at the legislative recall framework that evolved out of that.
Why hasn't similar legislation hit the tech world? Because the community of experts who would normally be calling for it has been otherwise co-opted. Good job, keep it up.
At some point, credit can be for forcing a fault to get fixed, not just for finding the fault. I've been in the large corporate environment -- hell, I've found remote roots in deployed products directly because of Oracle 8's broken TNS listener -- that *someone* in your organization found something is never, ever as compelling a reason to address the fault as someone *outside* the company finding something. Credit is more than just finding the flaw, it's finding it without sufficient internal documentation to know where to look. And the threat -- to be very explicit -- is if someone outside your organization, with no source code, can find the problem, so can a malicious attacker.
Security researchers represent hackers who behave as the malicious might but instead work with a vendor. There are inevitably tweaks necessary to the process -- but the process itself is critical, lest we experience its legislative opposite.
--Dan Kaminsky
OK, that is her pedigree. So? Here are qualifications for very talented people with whom I've worked.
Sr. Unix Admin: No degree, was a chef
Unix Admin: BS in Physics, worked in a slaughterhouse before college.
Sr. Systems Architect: No degree, was a chef.
Sr. SAN Admin: No degree, was in the USAF
Sr. SAN Architect: No degree, worked on environmental control units
Someone's education, military record, etc. doesn't prove or disprove that they can do a job. If you believe that, you're falling into the same trap as way too many corporate HR departments.
"It's too bad stupidity isn't painful." - A. S. LaVey
The article criticizes security researchers, which is aparently easier than spending energy on introspect.
And all that from a company that marketed its product as "Unbreakable" despite dozens of security problems every year.
Scum.
Instead of bad-mouthing the people who discover the problems, why not tell us what Oracle is doing to improve its response time to vulnerabilities? Open source software projects have an advantage in that they can just fix the bugs and make a new release while close source software projects have to additionally fix old versions or else offer free upgrades. Yes it is hard to respond rapidly, but it's necessary. The security researchers know this. But many closed-source software vendors are in denial. Bad mouthing security researchers won't help. Changing your release model to help get fixes out more rapidly will.
ROI on security work is invisible to the accounting department. my wild guess is her dept. is understaffed.
another wild guess (from having seen too much commercial software development) is that too many companies rush to ship working code trying to get first to market, or look good on deadlines etc.
> Don't read the 'article' - don't post stories like this onb /. again please.
Agreed. Just for good measure, a quote:
| In reality, many of the best researchers aren't the ones you hear a lot about, because discretion is their stock in trade.
Well, if they don't publish, you can hardly call them researchers, can you? I guess the author expects tame consultants that work for "credit" only. So: don't read the article.