Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security Businesses IT

Oracle's Chief Security Officer Speaks Out 112

Posted by Zonk from the talking-the-talk dept.
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."
This discussion has been archived. No new comments can be posted.

Oracle's Chief Security Officer Speaks Out More

Oracle's Chief Security Officer Speaks Out

Comments Filter:

  • Rubbish as usual (Score:5, Interesting)

    by tyroneking ( 258793 ) on Sunday August 07, 2005 @02:06PM (#13264910)
    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.
    Don't read the 'article' - don't post stories like this onb /. again please.

    • Re:Rubbish as usual (Score:3, Insightful)

      by Gherald ( 682277 )
      > 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.

    • Re:Rubbish as usual (Score:1, Insightful)

      by Anonymous Coward
      ...but fails to mention that systems that are used for such reporting are usually never exposed to the evil internet....

      Ummm, last time I checked, MOST corporate hacking was done from the INSIDE, NOT the Internet. K. Thanks.

      • > Ummm, last time I checked, MOST corporate hacking was done from the INSIDE, NOT the Internet. K. Thanks.

        Really? Where does one "check" this?
        • > Ummm, last time I checked, MOST corporate hacking was done from the INSIDE, NOT the Internet. K. Thanks.

          > Really? Where does one "check" this?

          No - you don't! Because it is not published anywhere. I lost count on 70's and 80's before I got tired of the whole business - internal fraud is huge but hidden, if you are a smaller player, you are fired and if you high enough you are either promoted or retired but no word ever gets out - bad publishity for company. So - as someoneone already said - old stuf

    • Re:Rubbish as usual (Score:5, Insightful)

      by Donny Smith ( 567043 ) on Sunday August 07, 2005 @02:47PM (#13265093)
      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.
      • I think you mix up two different things together. The Oracle Database (RDBMS) was marketed as "Unbreakable" and honestly, it more or less is within the terms. The products that had so many vulnerabilities are Oracle tools, like Oracle Reports or Oracle Forms and they are pretty notorious for being shaky with security. But they were never marketed as "Unbreakable".

        Oracle is pretty large software company, thats like saying that Microsoft Windows are unstable because your Age of Empires have bugs and crash.

      • Agreed.
        And I don't get her example about how they need to analyze risks, and therefore holding the patches.
        If they find that this particular version's got a bug, put the patch on the net while analyzing other versions at the same time.
        At least those who are really diligent can choose to patch the system.
        Heck if they're worried about update costs of the customer, let the patch to be removable. Someone could patch the program now, and then if there's a better one, they can install that instead.
        The fact is tha

    • Re:Rubbish as usual (Score:2, Insightful)

      by thsths ( 31372 )
      > 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.
    • Sounds like you've never worked at any company that actually develops stuff. It does take time to investigate the problem, fix it, figure out what's affected, roll up the patches, and issue them to customers once in a while. If you issue dozens of updates per month or don't test your patches thoroughly, nobody is going to install them.

      What's worse, a hacker bringing down your system, or an untested patch for a potential vulnerability bringing down your system? Security fixes cause just as many problems
      • Sounds like you've never worked at any company that actually develops stuff. It does take time to investigate the problem, fix it, figure out what's affected, roll up the patches, and issue them to customers once in a while. If you issue dozens of updates per month or don't test your patches thoroughly, nobody is going to install them.

        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 some

        • I think that the parent hit on something here. Lots of issues are "Fixed in 10.2" and may be waiting out there in the "10.1.0.5" patchset that is due to ship in Jan 2006. Its the backporting the one-off patches (not patchsets) to a current release that cause fear of ending up in Opatch hell having to file yet another iTAR with Oracle Support. -yet another patching fool
      • Cool - I don't disagree with what you say, but I do disagree with such a crappy article by the Oracle CSO. She doesn't make a serious attempt to address any of the points you mentioned or talk about what her department does.
    • it contains some quite preposterous statements as well

      The myth is that researchers are always entitled to credit.

      Then she goes on the state 'in so many words' the credit is given not based on it being deserved but based on how they feel about you personally.

      In reality, when a researcher puts customers at risk by releasing exploit code for a vulnerability before the vendor has had a chance to fix...

      She confuses the researcher with the company that released the flawed product.

      The reality is that not all resea
    • Glad you feel that way, but you have to admit, it was rather ballsy that she wanted to even take a stab at an 'interview' after her company got its arse kicked by independant research companies. I don't think this is rubbish, I think it's important that if you are a security researcher, independant or otherwise, it's important to understand where some of these high level execs stand, they ultimately make the decision regarding patches and press releases. I will definitely continue posting these types of a
      • This was NOT an interview, this was a poor quality press release / moan piece. Once again I have to repeat that this was low on detail and provided no information on what her department does - or even any reasonable discussion about her points.
        Knowing where high level execs is useful, but her poorly expressed opinions cannot represent what anyone would call a sound example of corporate policy or SOPs regarding patch releases.

        It wasn't ballsy, it was just balls.

        I'm sure you do a good job posting articles to

  • But that's true, at least for extensive vulns (Score:5, Interesting)

    by melted ( 227442 ) on Sunday August 07, 2005 @02:06PM (#13264911) Homepage
    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.

    • Re:But that's true, at least for extensive vulns (Score:5, Informative)

      by gclef ( 96311 ) on Sunday August 07, 2005 @02:34PM (#13265033)
      The problem is, a few of the recently-released ones had lag times measured in *years*. Oracle can whine all they like about unrealistic deadlines from researchers, but a few years is far too long to sit on something.

      My reference for the years comment:
      http://www.red-database-security.com/advisory/publ ished_alerts.html [red-databa...curity.com]

      They waited over 600 days for Oracle to patch some vulns. There's no excuse for that.
    • But that's true, at least for extensive vulnerabilities that can require a lot of effort to fix and/or test! As an Oracle customer, I don't care how bad they got it. I pay a butt load for a product and I expect it to be solid, robust, and secure. Part of that security is the timely remediation of security problems. Have you seen Oracles track record on fixes. It's measured in quarters and years!
    • In the most simplistic form software developers don't want disclosure due to bad publicity, and the security researchers want disclosure for good personal publicity.

      But this is all simplistic. I think the reality is that software developers mostly try to make good software, but there is a pressure to add features rather than allocate resources to creating an internally good product. I have seen it, and I have been guilty of this. In this way having an external force pushing the software development pro

  • Deparment of Homepage Security (Score:5, Insightful)

    by Doc Ruby ( 173196 ) on Sunday August 07, 2005 @02:07PM (#13264918) Homepage Journal
    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.
    • I know that Oracle takes al security issues very seriously. All bugs related to security issues are treated special and gets the attention needed. Some of the bugs are inherintly complex and touches many areas.

      The Oracle database is probably one of the most complex pieces of software anyone will ever come in contact with. The source code is extremly complex. The implications of bugs can be enormous (imagine you withdraw $100 from an ATM but due to a bug, you account is showing $1000 witdrawal) or the spac
      • Yes, Oracle takes security problems seriously. That is one reason why they are used for so many essential services. Another reason is that those people providing the services buy Oracle based on the buyer's impression of security. Which is why Oracle has their exec making PR about how they're doing a great job (which they generally are). The problem is that the exec is treating the researchers reporting bugs as the enemy, rather than as free workers contributing research to Oracle, which improves Oracle sec

      • Re:Deparment of Homepage Security (Score:5, Interesting)

        by fimbulvetr ( 598306 ) on Sunday August 07, 2005 @03:22PM (#13265230)
        This is bullshit.

        Oracle does _not_ take vulnerabilites seriously. I agree that the oracle database is extremely complex, and the implications of bugs is enormous, but it's not inherently complex. Because of this, claiming that they don't release patches because it's complex is bullshit. Oracle does not need to be as complex as it is.

        First, the complexity:
        I've been running Oracle just as long as I've been running both Mysql and Postgres (I know what you're saying - oh, he's one of those guys:)), and I know that the features oracle offers can exist without all of the useless bloat oracle tacks on. Mysql can replicate, instantly, to who knows how many databases. Oracle Dataguard is limited to 9. I can restore databases in seconds using postgres, oracle takes all damn day. Mainly because you have to have your ducks in a row with: Arch files, redo files, tnsnames, listener files, spfiles, pfiles, oratab, oracle home, etc. Oracle databases are extemely difficult to get running on a different system. Even exports (exp/imp - what _should be similiar to an sql dump) don't work across OSs. Oracle offers no native sql dump command, instead you have to figure out how to get TORA working. Oracle offers sqlplus, an old, broken command line client that requires unsightly scripting to even start the database.
        Oracles documentation is very similiar to their product: Disconnected. Nothing fits. Everything (kind of) works, but noone knows how to put it together, save the people who killed what must be hundreds of thousands of brain cells by doing it by trial and error. Oracle requires java, and lots of it. Oracle requires an oracle database to monitor other oracle databases. It's wise to put this on a seperate installation/box. Doesn't seem to make a lot of sense. Now I have twice as many exploitable boxes, not to mention more to backup, administer, etc. Oracle requires an insane amount of diskspace compared to other databases.
        I'm not arguing for mysql/postgres vs. oracle - I'm just trying to say that Oracle does NOT need all of the bloat it currently has. The company could stand to do a complete rewrite of it.

        Now, the security:
        Here's a perfect example of what I mean:
        http://www.red-database-security.com/advisory/publ ished_alerts.html [red-databa...curity.com]

        The first 6 vulnerabilites are 600(!!!) days old!
        Here's a perfect example of their lack of motivation.

        http://packetstormsecurity.nl/0507-advisories/Orac le9R2-unpatched.txt [packetstormsecurity.nl]

        Basically, a vulnerability was disclosed months ago, and oracle fixed 10.x in July's update, but completed ignored 9.x. To quote TFA:

        'We contacted Oracle about this issue and Oracle
        confirmed it, when we asked why there is no fix
        for 9iR2, Oracle said:

        "Our development teams neglected to do the backports.
        We are working on creating those backports now."'

        Leaving production systems unpatched until October! (Assuming oracle doesn't 'neglect' to do it again.

        In short, quit reading the marketing bullshit and wake up.

        • Re:Deparment of Homepage Security (Score:5, Informative)

          by IdleTime ( 561841 ) on Sunday August 07, 2005 @03:51PM (#13265376) Journal
          I'm sorry but you are way off the mark here. I'm sorry that you don't know your job, but don't blame Oracle for your own incompetency.

          Using streams replication there is not limit (practically) on the number of servers to replicate to.

          Restore and recover takes a long time? Use archivelog mode, unless you have physical corruption that spans multiple disks, there is no need to restore the whole database. restore the corrupt file and roll forward. Unless your last backup of the file was months ago, the operation is done in minutes. Please don't spread stupid remarks that have no foothold in reality. L:earn to use the product rather than display your own ignorance.

          Oracle Dataguard has nothing to do with replication. Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions.

          Starting a database is simple: sqlplus "/ as sysdba"; startup... How difficult is that?

          I don't mind critique of Oracle, but at least get your facts straight!
          • I'm sorry but you are way off the mark here. I'm sorry that you don't know your job, but don't blame Oracle for your own incompetency.
            I don't know what gave you the impression that I didn't know my job, or that I was incompetent with oracle, but it's quite clear that you're no stranger to making assumptions.

            Restore and recover takes a long time... This depends on what you're talking about. I was talking about worst case...You've got some arch files, some redo files, some dbf files and a new disk you need to
        • Lol - amen to that brother!

          As a fellow Oracle database sufferer, I feel your pain.

          Oracle is all about the money - if they can get away without patching (security holes or bugs), then they will. Roll on Open Source where they fix it "because it is the right thing to do" !
  • I think the security researchers look at a vulnurability and would say that it needs to be patched, a minimal change of the form 'if exploits then avoid error', a relatively easy change. Their priority is to keep the application from being vulnerable to a flaw without breaking the app.

    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

  • No, a "myth" is something that ISN'T true (Score:2, Insightful)

    by Anonymous Coward
    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 i

  • "security researchers" is a broad rubric (Score:5, Insightful)

    by DingerX ( 847589 ) on Sunday August 07, 2005 @02:20PM (#13264972) Journal
    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.

    • Re:"security researchers" is a broad rubric (Score:5, Insightful)

      by dbarclay10 ( 70443 ) on Sunday August 07, 2005 @03:22PM (#13265233)
      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.

      You miss the entire point. You could be referring to one of two "really big, clunky corporations." Either the "really big, clunky corporation" that needs to upgrade all their vulnerable equipment, or the "reall big, clunky corporation" which actually has to provide the fix. Let's do the last one first:

      • My job is to provide services in a secure, cost-effective, and effecient manner
      • It's my responsibility to choose the components I will use to do my job
      • That means that (unlike the recent Oracle vulnerabilities), I require that fixes for reported vulnerabilities be provided in a reasonable time-frame, fully-tested and audited
      • A "reasonable timeframe" is measured in hours, days, or - very occasionally - weeks. Not months or years (such as the recent Oracle fixes)
      • You may say "that will increase the cost of the products" - no it won't. The relatively minor increase in ticket and support contract price is dwarfed by the price of a security breach
      • Whether the vendor is a "big, clunky corporation" or not is irrelevant - all that matters is if they can meet the requirements set out by their customers (of which I am but one, and trust me, more and more customers are demanding reasonable security-fix practices - of which "sit on it for a year or more" isn't one)
      Or, if you're talking about the "really big, clunky corporation" which can't manage to perform critical upgrades at a time appropriate for the business:
      • That's their choice and their problem. That some yahoo idiot corporation can't expend the resources to secure their infrastructure isn't my responsibility.
      • Note that near reporting periods, I don't touch critical infrastructure either. My choice. I implement what workarounds are safe to put in place, and I make a calculated risk. By refusing to act on security-related reports in a timely manner, Oracle took that choice away from me.

      To sum up: Oracle waited YEARS to fix some of these bugs. I don't care why they were unable to fix them. They got caught with their pants down, after the people who reported them decided that "okay, by now, somebody who'll use these vulnerabilities to actually attack people has probably found them" and subsequently released (limited) details required to inform Oracle's customers of the possibility of vulnerabilities.

      Now they're trying to blame those people, who actually gave me the ability to make reasoned decisions? The gall. A year ago I wasn't in a position to choose which software we used in our infrastructure, and now I am. Oracle's failure to act upon vulnerability reports, and their subsequent attempt to disparage those who allowed me to do my job, has lost them any possibility of future sales while I'm in charge (until, of course, they actually change - and confirming that change will require me to actually audit their own practices, which I doubt they'll ever let me do).

      The saddest part? We're a software development firm which gets to dictate to some really big customers what database engine they use. We're talking about tens of thousands of licenses, easy. Whereas we were previously looking at MySQL, Postgres, and Oracle. Now Oracle is just totally ruled out.

      • A "reasonable timeframe" is measured in hours, days, or - very occasionally - weeks. Not months or years (such as the recent Oracle fixes)

        Does your company do any type of quality assurance? How the hell can you do proper QA in a few hours, unless it's a trivial fix?

        • Does your company do any type of quality assurance? How the hell can you do proper QA in a few hours, unless it's a trivial fix?

          That's why I said "hours, days, or - very occasionally - weeks"; not all fixes are trivial :) And yes, we do get trivial fixes in and tested within a matter of hours.

          That said, many commercial software companies (such as Oracle and Microsoft) can't even manage to get trivial fixes done - even given months.

          There are two types of QA: preventative and exhaustive. We do a but

          • And I don't see why anybody would consider using our own software, either.

            I'm having trouble parsing this sentance. Could you help me out?

          • The front-end is a box which takes in telephone calls. Our regression testing actually makes hundreds of automated phone calls when a new release is being tried out - and the results of each of those calls is checked down to the source-class level.

            You do realize that your program is trivial compared to something like Oracle?

            Luckily the code is written well enough that there hasn't been more than one or two non-trivial fixes, and the bugs they fixed weren't themselves critical.

            It's nice when you can do that.

    • 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.

      While I can understand the difficulties of beurocracy (I work in a doozy of one), I have little sympathy. Those who would take advantage of these vulerabilities will likewise care little about the politics of big, clunky beurocracies. What they care about is exploiting the systems they find vulnerable. And, even bet

    • 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.

      Not everything happens slowly in a large corporation. If a company finds out that a flaw in their billing procedures is causing the loss of $3m per day, that flaw will be fix

  • Cry me a river sweetcheeks (Score:3, Funny)

    by Anonymous Coward on Sunday August 07, 2005 @02:26PM (#13264992)
    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!

  • It amazes me.... (Score:1, Flamebait)

    by cyberkahn ( 398201 )

    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.
    • And how exactly do these qualifications and experience preclude her from being a top class manager leading a team of security experts?
      • It helps when you have been actually in the trenches. Erwin Rommel probably was a much more effective Field Marshall as he had extensive experience "working his way up" in his respective field. If you read his book Infantry Attacks you will see how the young Lieutenant thought outside of the box during World War I and then later applied those lessens learned when he was a Field Marshall. My worst experience in IT was working for an IT director who didn't have day one experience in the IT field. I am not say

    • Re:It amazes me.... (Score:4, Insightful)

      by Metzli ( 184903 ) on Sunday August 07, 2005 @02:44PM (#13265084)
      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.

  • Not a question of ignoring (Score:4, Insightful)

    by Spazmania ( 174582 ) on Sunday August 07, 2005 @02:30PM (#13265018) Homepage
    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.
  • 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 rese
    • How true you are and how infuriating it is. SOX, HIPAA, GLBA, etc. are the only reasons that many places have any security funding at all. Security is an afterthought. People will open the checkbook wide for triage after the problem occurs, but too many senior managers are unwilling to do any prevention.
  • 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 i

  • Why all the references to Black Hat? (Score:3, Insightful)

    by sunborder ( 905852 ) on Sunday August 07, 2005 @02:36PM (#13265046)
    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).
    • There were a few talks at Black Hat this year regarding Oracle. I only attended one of them (Cesar Cerrudo's talk), but the presenter slammed Oracle pretty hard. If the tone of the others was even remotely similar, it wouldn't surprise me if somebody lit a fire under her ass, asking why everyone in the security community thinks Oracle sucks.

  • Lets go over this (Score:4, Insightful)

    by Effugas ( 2378 ) * on Sunday August 07, 2005 @02:44PM (#13265078) Homepage
    For the most part, credible security researchers follow some variant of this document [wiretrip.net]. 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

  • If the truth is that your security sucks... (Score:4, Interesting)

    by ikekrull ( 59661 ) on Sunday August 07, 2005 @02:50PM (#13265114) Homepage
    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.

    • Bad Engineering? I guess YOU can say this because of all your accomplishments. Do you even know what the vulernabilities are? They are so insignifigent that they will of course be pushed back while other more signifigent issues are addressed. Even if those issues are getting a new piece of functionality out the door. It is a business. Oracle is not a perfect company, but consider the other giants of the industry. Yes, they are trying to dominate the industry. At least they are doing it by making the

    • "And so they should. Its still sort of a free country, and Oracle has no right to control people speaking about their poor engineering."

      More to the point, there are unlimited opportunities for anonymous public disclosure of this sort of information. The idea that the option exists to suppress it is based on a completely flawed premise.
  • 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

  • maybe just over worked (Score:3, Insightful)

    by pixel fairy ( 898 ) on Sunday August 07, 2005 @03:12PM (#13265200)
    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.

  • Us vs. Them (Score:4, Informative)

    by adturner ( 6453 ) on Sunday August 07, 2005 @03:39PM (#13265303) Homepage
    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 te

  • 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 t

  • 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 fi

    • s/cisco/cisco|oracle/g

      The red cloud of outrage obscured my vision. Man I'd like to send that guy into space wearing a puffy suit to make some repairs using a sharp pair of kitchen scissors. He might have to pause long enough to use his brain for once rather than reciting monotonously from the gospel of the Needy 500.

  • >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 crimin
  • 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...

    (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

  • In reality, when a researcher puts customers at risk by releasing exploit code for a vulnerability before the vendor has had a chance to fix it, it's ridiculous to expect the vendor to say, "Thank you for putting our customers at risk." I've never had a customer ask us for exploit code or exploit details, though they do want enough information to do a risk assessment.

    Excuse me?! The security researcher did not put anybody at risk -- you put your customers at risk, when you wrote that code.

    I firmly bel

Slashdot Top Deals

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Close