Should security bugs be proprietary?

Should security bugs be proprietary?

Summary: Is timely disclosure -- an open source security process -- the key to a timely fix? Or do loose lips sink chips?


Cisco logoAfter an extensive hullaballoo Cisco Systems has gotten former ISS employee Michael Lynn to shut up about a security flaw he found in its router software.

Lynn said he found a buffer overflow in Cisco's software in April, alerted them to the problem, but they failed to fix it promptly. So he was ready to tell all at the Black Hat Briefings in Las Vegas this week, but Cisco won a temporary restraining order. ISS agreed to yank the presentation, but hours later Lynn quit his job and described the problem anyway, saying "I had to do what's right for the country" and that bad people were already working on exploits.

Cisco responded with more legal paper, and Lynn agreed to shut up.

The question for me is not, did Cisco have a right to do what it did? The question I have is, did Cisco in this case do right by Cisco?

Keeping bugs, especially security bugs, proprietary is a very touchy subject. Some folks feel spilling the beans lets the bad guys know what to work on. Others say spilling the beans is the only way to let good guys know what to work on.

I've previously discussed the famous graph showing that the risk from an exploit hits its maximum between its announcement and the creation of a fix. But that risk is rising from the time the exploit is discovered, and the risk never falls to zero.

Is timely disclosure -- an open source security process -- the key to a timely fix? Or do loose lips sink chips?

Cisco has delivered its verdict. I'm wondering what the truth is.

Topic: Cisco

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Cisco isn't the problem in this case

    The problem is the judge who issued the restraining order.

    Cisco is certainly within their legal rights to merely ASK for one. I don't see how any judge could justify their logic in granting one though.

    If Ford Motor had a problem in one of its cars (let's even say it's not a lethal problem, let's say it's just a problem with the default CD player), would it be illegal for me to talk about it openly? Would a judge be able to justify a restraining order in that case?
    Michael Kelly
    • ISS, not CISCO, looks to be taking the legal action

      [i]Cisco is certainly within their legal rights to merely ASK for one. I don't see how any judge could justify their logic in granting one though.[/i]

      According to

      [i]Richard Forno, a security specialist and author, said in an e-mail that he received a cease-and-desist letter from lawyers representing Internet Security Systems.[/i]

      ISS -- who [b]owns[/b] the research -- was the one taking legal action. It looks like CISCO did ask ISS and ISS agreed.

      Note: I agree 100% that CISCO has no legal standing in preventing the publication (unless it had violated licensing or contractual agreements) since CISCO did not own the research. ISS does ow n the research and does have legal standing.
    • CISCO is the problem. If your Ford had

      a problem where someone's well being were at risk, they would be forced to recall.

      In this case, the well being of billions is at risk. And CISCO takes a walk in the park!
      • Mr. Kelly is looking at things from a legal perspective ...

        I believe that Michael Kelly is referring to the legal maneuvering as the "case". If I recall correctly, he has a legal background (lawyer?) and is looking at the tug-of-war between the researcher, ISS, CISCO, and of course the judge from the perspective of someone with a legal background. From a legal perspective, Mr. Kelly's position is that the judge errored in siding with ISS in gagging the researcher.

        [i]forced to recall.[/i]

        Yes. CISCO needs to fix the problem. Does it warrant a [i]recall[/i]? One of the ZD-net articles (forgive me for being too lazy to look it up) stated that it could only be exploited from within a company's internal network. Therefore it is not in the same category as one that can be exploited from the outside.

        If I'm wrong on that last part (i.e., if it can be exploited from outside the internal network) then that would change things significantly.
  • my 2?

    As critical as Cisco infrastructure is for our day-to-day communications, they should be crediting external people that spot problems with their infrastructure, the router software in this case.

    Allowing them to keep people in the dark will only lead people to search for alternatives (which I'm sure Cisco would not want that to happen), though the problem there would be to find a suitable substitute for Cisco Systems' infrastructure, costs and whatnot.

    I'm not against Cisco keeping their software for themselves, but at least acknowledge there's a problem with their current software and start working ASAP in a solution for it. If this guy was correct and there's already people working on an exploit for this issue, the more critical this is! Cisco should have a patch available ASAP to prevent this to happen, since too much of the Net's infrastructure depend on theirs... Then again, was it wise to let this single company rule the Network infrastructure, just like we let Microsoft rule the software one?
  • cicso was not fixing the problem

    this is a test, lets see how fast they now fix it
  • Who owned the research?

    The researcher was being paid by ISS to do the research. ISS [b]owns[/b] the research -- not the researcher.

    If we decide that the researcher should be congratulated for stealing ISS?s property and set the precedence that the company that invested the money into researching the flaw doesn?t own it then there is no incentive for ISS to research future issues.

    Yes, CISCO may have bullied ISS into not publishing. But it is ISS?s decisions to publish or not -- and if ISS had decided to publish, I would be the first to congratulate them.

    I?m being paid to develop an internal IT system by a company. I do not have the right to walk away tomorrow and publish all of the source code or research that I?ve done for the company.

    If I?m a lawyer working for a client, I do not have the right to publish all the research results that I find (especially if it?s damaging to my client). And if I did, I should be disbarred so that future clients know not to trust me.
  • I think

    QUOTE from Bruce Schneier's article:

    Cisco's customers want information. They don't expect perfection, but they want to know the extent of problems and what Cisco is doing about them. They don't want to know that Cisco tries to stifle the truth:

    Joseph Klein, senior security analyst at the aerospace electronic systems division for Honeywell Technology Solutions, said he helped arrange a meeting between government IT professionals and Lynn after the talk. Klein said he was furious that Cisco had been unwilling to disclose the buffer-overflow vulnerability in unpatched routers. "I can see a class-action lawsuit against Cisco coming out of this," Klein said.

    ISS didn't come out of this looking very good, either:

    "A few years ago it was rumored that ISS would hold back on certain things because (they're in the business of) providing solutions," [Ali-Reza] Anghaie, [a senior security engineer with an aerospace firm, who was in the audience,] said. "But now you've got full public confirmation that they'll submit to the will of a Cisco or Microsoft, and that's not fair to their customers.... If they're willing to back down and leave an employee ... out to hang, well what are they going to do for customers?"

    Read the whole article here:


    I am just glad I am not depending on a company that would cloud the truth instead of being honest and working hard to fix the problem.

  • And what if they don't admit the problem exists?

    In the past I reported a bug in the old MS Mail program which allowed me to read any users mail and send mail as that user. I had demonstrated the problem to others at the University as a test and yet no matter how many times I talked to the MS Manager and explained how to reproduce the problem they claimed it did not exist. The exploit was accomplished because part of the authentication was done locally and part was done with the server. If you dropped your network connection and attempted to log on with the target users credentials (failed) and then put yourself back on the net and gave it your own credentials (which matched the local cache) it was happy to give you access to the target account. Since the exploit did not involve ANY code and ANYONE could accomplish it in a few minutes if it was fully described, the publication would have led to catastrophic failure of the email security for everyone then on MS Mail. My choices were to 1) publish and mess up all the systems/users for sure and give one idiot at MS what he deserved while giving MS a black eye it might deserve or 2) keep my mouth shut and fume for years about the idiots at MS and the terrible situation we would all be in if it got out before they moved to Outlook/Exchange.

    For the Net and our country to be truly safe from the kind of economic disaster inherent in similar problems, oversight above the proprietary corporate (myopic) vision by a Homeland Security or equivalent is required. To provide a solution path around the accidental roadblocks of corporate bureaucracy or occasional idiots we need someplace where this kind of problem can be reported in a confidential/secure way.

    BTW - I did leave out a specific piece of information in my description so if any old installations are out there you are not immediately at risk. But get off that system now!
    And in case it was not obvious, I have kept my mouth shut about this for many years - until today.