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
"There's a truth 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."
A software engineer working to maintain the codebase at a company however will say that a whole new layer of protections need to be added to the application to safeguard against this kind of attack, requiring a significant effort to refactor code and maintain the maintainability of the software.
Thus the security researcher expeects a quick fix while the company sees a maitainence nightmare in the making. It is not surprising the two groups disagree on how to handle these vulnurabilities.
Companies are made of largely human developers under severe budgetary, time, and red tape contraints while being run by monkeys. Only the threat of being spanked in the realm of public opinion causes such difficulties to be bypassed to allow generally decent people do their jobs.
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).
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.
I can 0wn her?
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!
That someone with the following qualifications leaps to the position of CHIEF SECURITY OFFICER.
Ms. Davidson has a B.S.M.E. from the University of Virginia and an M.B.A. from the Wharton School of the University of Pennsylvania. She has also served as a commissioned officer in the U.S. Navy Civil Engineer Corps, where she was awarded the Navy Achievement Medal.
There's another myth out there that's not true. It goes something like, writing software is hard, if you don't give me your money you can't do what you want because no one will write high quality software to do it. The people who spout that line are busy filing absurd business method patents because there are actually lots of people happy to get things done without their help. As for the quality of what the liars put out we have stories like melted's:
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.
And so, closed source is a model that does not work and never did. I don't feel sorry for people who work for idiots and don't think others should do as they say to make their lives easier. The tragedy is that people work for idiots and then those idiots make life harder for the rest of us.
Friends don't help friends install M$ junk.
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.
I am surprised that so many people don't realize that computer security is a business. It is in the best interest of the researchers or security companies to release advisories for the sake of PR. It is a form of advertisement for security guys, that is why they want to produce reports. When you work on a security exploit, you want to release it not for the sake of making things less secure; but to show off your work and knowledge.
Imagine you worked on a problem for a month an then told you can talk about it. The fact they are giving vendors some time to fix the problem shows how responsible they are. This is there livelihood and there are not going to wait for ever to make money. Oracle doesn't want to fix it because it cost money, but for everyday the researcher or security company waits; it will cost them.
Nothing more, For me to say; About my life, A life of dreams....
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).
The reason this came to be is that big companies ignore these all the time. In fact, code was developed to prove to the companies that the opening was real.
How real is this? Well, in the early 90's I worked at HP Ft. Collins. I know of one opening in HP-UX's networking. The manager of the group was told that the fix was going to involve some major work (something like 16 man months, IIRC). The manager than asked who knew about it. Well it was discovered in-house, so we assumed that maybe 6-10 of us. Manager said to let it go. Basically, she said that 8.0 would cover it and we could assume that everybody would upgrade to it.
BTW, for those of you who say how terrible HP was for that, well, I saw similar things at IBM and I have heard of similar things at Sun (somewhat recently in fact). And of course, the biggest cheat of all, is MS. Just look at their record and you will know that security has never been job #1.
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
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
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.
A CISSP?
y 2003/tc20030529_1659_tc111.htm
A cursory google search reveals that she's been working in the secure-systems group at Oracle (albeit in a Product Marketing role) for 12 years. I'd say that's fairly substantial.
http://www.businessweek.com/technology/content/ma
I'd say YOU lack sufficient "credentials" to post on her lack of sufficient credentials since you obviously didn't look for any sense of her qualifications save for the two-sentence bio provided in the grandparent.
What a lamer.
"Oh, but we're innocent, somebody framed us!" Tell it to the hand 'cause the face ain't listening.
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.
No; bugger off.
Jesus, ease up, Sparky.
When attempting to view the article, my privoxy crashes. After restarting privoxy I tried again - same result. After the next restart I simply attempted to access the homepage at http://www.zdnet.com.au/... Same result, you guess it. Is this just a problem of my privoxy installation or do other people have the same problem? And if, got anyone an idea if that's simly due to a privoxy bug or an intended part of my ZDNet viewing experience?
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.
First, he talks about demands for fixes within 15-day or 30-day periods. Sorry, wrong. The behavior that causes so many people to push for full disclosure is vendors not even
As for tying seceurity releases and disclosure to financial quarters, sorry but no. That's not the vendor's call to make, it's mine. If the problem's severe enough I may have to overrule procedure and test and implement the fix regardless. But the vendor can't decide that for me, and I can't decide it for myself if the vendor's not telling me "for my convenience".
Because if you don't, script kiddies will rape your customer and he will never give you another dollar.
As Microsoft and Cisco have demonstrated, script kiddies raping your customer does not have any bearing whatsoever on whether the customers give you more dollars
At the risk of repeating the sentiments of everyone else: Vendors are MANAGED BY 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. As opposed to developers, who would never put them in in the first place if it weren't for time-to-market pressures. Oracle is in no position to talk since half their patches don't even work on half the software baselines they're supposed to apply to.
Did anyone else notice that she repeated herself?
There were two phrases in there: "because discretion is their stock in trade" and "not all researchers are noble-minded, and not all vendors are indifferent slugs" that got repeated, word for word! The phrases are so trite that I wonder why she bothered to repeat them.
The thought I have is that she desperately wanted to fit those phrases in somewhere, so she put them into the article in various places, but then she forgot to proofread again and remove the redundant uses. They sound pretty forced, like they're supposed to be persuasive even though they haven't really got any content to them.
The other option that springs to mind is that she thought if she repeated them, they'd stick with the reader and influence their opinions somehow.
The whole thing would have come off better if her writing style had been more mature and adult-sounding.
...even when all the parties involved cooperate in the most good willed manner. And I know it form first hand experience.
Let's say a researcher found a bug in quite commonly used open source network protocol lib. The bug has been sitting there for about four years, despite public availability of the code and widespread usage. Maybe the black hats know it, maybe they do not: no single hacking incident has been reported (yet) involving the lib in question. Now the reseracher contacts the maintainer, and a fix is available and tested, in under 3 days. One of the vendors of the involved apps, privately contacted, decides to go public without coordinating with the rest of the community: they publish the disclosure and the fix. The lib maintainer is forced to publish the upstream fix ASAP, and give it as much publicity as possible. So does the rearcher. All other app vendors react wonderfully quickly, and realase patched versions within 1 to 2 weeks.
You'd think all is fine with this, the speed and coordination of the Good Guys - Open Source Model having been proven yet one more time? WRONG! /.
After yet two more weeks, one quite high profile website gets hacked because of not having applied the patch to the app running the site, and its admins get a lot of bad press and foul mouthing on
And yet, rant all you want about incompetent programmers and idiotic sysadmins, it had not happpened in the previous FOUR years, and would possibly not have happened at all without the work of the security researcher!
Moral of the story is: sometimes events take an unexpected twist. Do not blame corporations/vendors for not always doing the 'right thing' asap: the implicatons could be more subtle and far reaching than what is apparent.
there is no use denying that.
Ha! Too high a position to imagine a woman in? :)
It is tough to put out a real product. It is tough to get it into customer's hand and provide the support. It is a lot of work to make sure the fix does not break something else for some customers.
I have worked for companies that do this well and companies that do not do it well.
When a company gets large, often the ratio of engineering to talking about engineering gets very small. A patch that inolves 2 lines of code can take countless meetings of people from many departments. It can be a many week ordeal to do a very small change.
I find it very easy to believe the software vendors intend to be fast with the patches. I find it easy to see that they are peddling as fast as they can. I can also see that they may not be delivering the patches, and think that what goes on in their organizations is perfectly normal!
Religion is the main cause of atheism.
Now that takes talent to be the first post and be modded redundant.
But on another note, Oracle (among others) really is accused routinely of being slow on vulnerability fixes. What I would like to know is how many people think this is possibly because of one of three factors.
A) Their code is all undocumented spaghetti code
Or
B) They are taking the time to research and do it right
Or
C) They really are just blowing it off because it's not making them money so why put money into it
What do others think about this? How do the rest of you feel this is either true or untrue?
wow it takes talent to comment on something so fucking old.. be a fucking flame-baiter.. and a dick-sucker all at one time.
congradulations, you win the prize! you're modded a fruit-cake.
While Cisco finds the vulnerability "in house" and sits on it for gawd knows how long, the "researchers" are out there finding vulnerabilities with no guidelines from Cisco *ahead of time* that "oh, we know about that one, so it doesn't count".
His wife must love him, he believes in telepathy. Somehow the researchers are supposed to know which defects Cisco has already found in house and not waste their time finding those ones again.
Translation: we don't give a rat's ass how much time these people invest finding these defects, and mostly we would rather they all went away.
Oh, and by the way, the stock in trade of these people is to make Cisco look good. Those who don't make Cisco look good are the bad guys. And Cisco deserves this, because we charitably give out credit when people find bugs we didn't tell them not to bother finding.
>Vendors are made up of indifferent slugs who wouldn't fix security vulnerabilities quickly -- if at all
Well, maybe some vendors aren't but I know for a fact that some are. A couple of years back we reported a vulnerability to Opera and never heard from them afterwards. I mean, not a single word. It seemed that the whole thing disappeared into a black hole. Indifferent slugs, exactly.
The general tenor of most of the posts is that big evil corporations don't have their user's interests at heart.
Researchers on the other hand do; but these (at least some) are the people that release exploits.
And I see those exploits flood into my inbox, swirl around my system pollute the web I visit.
Releasing exploit code frequently results in some degenerate somewhere making use of the release exploit to do real damage. How releasing an exploit can ever be seen as the action of anyone but an insane criminal is beyond me.
Researchers who release exploits should be shunned by everyone, they are being irresponsible in the extreme.
Take a real world example, I find that a door to a 'secure' building is unlocked and unguarded. Do I find the building owner/responsible person and tell them or do I erect a sign saying 'Unlocked door, cool stuff inside'. I take the former course of action because the later course is a criminal act.
Oh and my system, its a simple desktop running windows; attacked not infrequently because of security researchers and their vainty.
Ok, for the first time in my life, I'm almost in favor of limiting it. Perhaps any person who wants to publish or have their comments published should be forced to submit to an IQ test to verify they actually have one. I'm not asking for much -- an IQ of 79 will do much better then this...
//As a result of her BS.
///Yes, this is personal.
(True, it may not help with much but at least it may have kept this dolt from having her blatant lies published, perhaps forced someone to check up on her track record of a 2yr turnaround or at least got her fined for idiocy later...)
/Has been hacked.
Mod me up, mod me down, flame me, praise me -- whatever you do, you help prove I exist...
I firmly believe that if software vendors wish to keep their code secret from the people whom they expect to use it, then they should be obliged at the very least (1) to offer a performance warranty on the software, and (2) to place a copy of the source code in escrow with an approved agency. In the event of any dispute, then the Courts would have the power to order the source to be unsealed, and appoint experts to examine it in order to settle the dispute.
Open Source software {the only kind I will use; if you are not prepared to show me the code, then I am not prepared to allow it on my system} would not be affected by these requirements. The source code -is- a warranty. Likewise, by supplying the source code with every copy of the software, the escrow requirement is taken care of {since everyone who has the software already has a copy of the source code}. The analogy would be with goods supplied in kit form requiring to be built by the purchaser.
{And by the way, I use MySQL -- and a lot of glue scripting to take care of the "missing features" like stored procedures and subqueries. They only slow down the DB engine when they're not being used, which is most of the time. And even if the unthinkable happens and the server's power fails mid-transaction, someone can always deal with it later. It's not likely enough to be worth worrying about till it happens.}
Je fume. Tu fumes. Nous fûmes!
That description does not match reality.
I've been in the FreeBSD security team and worked as a security consultant; I've been on "the inside" for hundreds of these issues (as we got heads up for a significant fraction of the vulnerabilities that can affect Unix based systems).
In my experience, the people that take the time to do full re-engineering to avoid classes of security errors (think OpenBSD) are generally also the fastest to respond to quick fix issues.
And the quick fixes generally are the way to go. As you do the quick fix, you also check around the code to see if there are more of the same kind of vulnerabilities and whether these should be fixed at the same time. If the program in question has REALLY bad security, these can be many and indicate that a larger fix (adding a security layer, doing a complete audit) is necessary before doing a release of the fix for the first issue, because inspection show that there are many more of the same type of issue. This occurs quite seldom, though.
Of course, when it happens, things may take time. Most of the time, though, things seem to take time just because there is no pressure, though. And the ones that take the most time are the ones with the worst (not best) security record - and it isnot because they fix security bugs "more broadly", but seems to be just because the team/company in question does not prioritize security.
Eivind.