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."
Nothing but a very short, low-on-detail slagging off of independent secuiryt researchers with totally nothing about how she does her job and what her department does. She does touch on some good points, such as clients not wanting to implement fixes during critical reporting periods, but fails to mention that systems that are used for such reporting are usually never exposed to the evil internet. /. again please.
Don't read the 'article' - don't post stories like this onb
But that's true, at least for extensive vulnerabilities that can require a lot of effort to fix and/or test!
Let's see, you're a development manager and you have a crazy schedule forced on you from above by some idiotic VP. Now this guy from product support comes along and tells you about this horrible flaw that will require you to shut down all development for two weeks, slip the schedule and have your best people fix it. Then you shut down testing for a month and have your best testers test it. Then there's a pain of pushing out a patch and notifying the customers and bad PR associated with that.
I can easily see how some of the less obvious vulnerabilities would be simply brushed off using "no one is ever going to find out" line of reasoning. Now if you know that someone has already found out and he will make it public in about a month, sure as heck you're going to issue a patch, even if this means slipping the schedule by a month (or in case of Windows by two years). Because if you don't, script kiddies will rape your customer and he will never give you another dollar.
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
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.
What a little cry baby.. so worried about someone getting too much credit. It's crystal clear she CAN'T STAND being pushed around by people that didn't follow all the rules like she did. Well too bad toots, it comes with relasing holes in your products, not from evil researchers.. got it? Good!
And IMO, whilest it may be true that NOT ALL vendors are made up of indifferent slugs who wouldn't fix security vulnerabilities quickly if it weren't for security researchers, it's true for most!
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.
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).
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
Then people are going to point it out.
And so they should. Its still sort of a free country, and Oracle has no right to control people speaking about their poor engineering.
Theres ways to do this that cause Oracle more inconvenience than others, but Oracle would be the last company to dump its inflated pricing if I said to them it wasn't ethical or caused me inconvenience.
If the problem exists, accept it, and fix it as quickly as possible. Oracle are just upset that when they are informed of vulnerabilities they get exposed to more legal liability than if they can claim they didnt know anything about it.
I gots ta ding a ding dang my dang a long ling long
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.
Background: I used to be a member of the product security response team for a large networking vendor. Among other things, I used to talk directly with security researchers who'd find vulnerabilities in our products as well as work directly with our developers to get them fixed. Hence, I have a pretty good idea of what really goes on.
Mary Ann makes some good points. Some (very few in my experiance) security researchers do make threats and unrealistic demands on vendors. Releasing a patch in our case often ment touching over 20 branches of code for various hardware platforms and customer special builds. Obviously, we not only have to research the issue, determine a fix which wouldn't cause other problems, apply the patch, but then QA them including appropriate regression tests.
All this takes months and may cause us to slip schedules (which may negatively impact revenue, but we do it anyways, because it's the right thing to do). Most people when I explained this too understood and as long as I kept them updated (every couple of weeks or so) were more then happy to wait- as long as I could report progress or showed how we were going to work around a problem.
But, Mary Ann is also failing to take responsibility for the failure of many vendors (including Oracle IMHO) to take security problems seriously. Some vendors take years to fix problems (Oracle recently took 700+ days to fix a single vulnerability that an outsider found and was nice enough to keep quiet about, David Lichfield last year canceled his Blackhat talk b/c Oracle didn't fix the problem in time). Obviously, there are those who are willing to bend over backwards to help out Oracle and other vendors, but it's a two way street. Vendors who get a bad reputation in the security community about not working with security researchers are then treated worse by the community.
Most of the security researchers who contact the vendor really try hard to do the right thing and are willing to bend over backwards to help out. Contrary to what Davidson says, it was my policy to ALWAYS give credit to the researcher if they found the issue before we had made a patch available, even if we had found it first. If the person was willing to give us a mailing address, also would also send them a small gift as a thank you for notifying us first rather then going straight to iDefense or full-disclosure. A little common sense and treating others as you would like to be treated goes a long way.
Of course there are those who do try to blackmail vendors. I had one guy in France demand we fly to Paris (from California) on under a week notice, wear certain clothes so he could spot us on a certain street corner with a written job offer for the world's lamest "vulnerability" or he'd go public. Obviously he had watched too many James Bond movies and we told him to fuck off. He ended up going public and we had to deal with it.
Personally, I think Mary Ann Davidsion just made her life more difficult. By painting such a negative picture of the security community she has only perpetuated the image that Oracle doesn't want to work with security researchers and that they're better off selling their bug to iDefense or 3Com. At least then they're guaranteed to get credit for their work.