Why do you think the Cisco research dried up like it did?
There are a couple of reasons. The first is, a lot of this is not remote exploitation, and a lot of what the research is about in any community is, "How do you do it remotely?" IRM's [Information Risk Management's] research, Sebastian's [Muniz, a researcher with Core Security Technologies] research, and to a certain degree, Michael Lynn's research, although it had a slight remote variant, it's not stable remote. And that's where the real game is.
You have got to figure out a way to get it in without being on the console. And that's what most of the development's been around: how do you do it on the console -- at least for Cisco, anyway.
And the second thing is, you want it to work. You're not trying to knock it out because you need the network up so you can get to the end point. So I think we sort of get a pass because no one wants to monkey with the infrastructure that they're using. It's like screwing up the freeway while you're trying to go to a different city. That's kind of a goofy thing to do.
Microsoft has been very public about how they changed the company to make security a priority. What's the story at Cisco? How did the security program get built?
We were probably in the same space. Many companies, including our own, started with building stuff first that solved communications problems and then thinking about the safety of communications afterwards.
About five years ago, we were fighting the company, my team. Mostly in the information security business. We were the "no" organization, the ivory tower. That's a dangerous place to be because my take is we ought to be a consultative fulfilment arm, not an adjudicator.
So we changed a lot of it and we started injecting things, like "You're going to have expertise in your team. We're not going to be even in the middle, so that way you can invest the expertise for what you need and we're not holding you up or bringing you into a slower position."
The second thing -- that can't be underestimated -- is we were getting ready in 2002 to launch self-defending networks, which -- like it or hate it as a slogan -- effectively is a big bull's-eye on our forehead.
Like Oracle's unbreakable Linux?
In fact Mary Ann Davidson over at Oracle dropped me a note and said, "thank you very much for coming up with a slogan that takes the pressure off what we've done," [laughs] as if I had anything to do with the announcement.
And then third, we've really had a footprint grow. We got used in more and more places, and frankly for thinks we never imagined we'd be used for. We're transitioning health care communications, we're transitioning site-to-site communications for the military. We're doing all these wild things that 20 years ago we didn't think about at the time.
So did you do something like adopt a secure development lifecycles or change the way you built products?
We're not mature in this. We're in the awkward teenage phase. We're testing at the end of the development process and we're figuring out from that data how do you go backwards into the definition process. Now some definition happens anyway. So for example there are some baseline requirements of every product we built. However, I still say there's a lot to be learned. When you think you've got it right and you build it and you test it, the learnings from the test should benefit the next thing you build.
We haven't adopted a secure development lifecycle like Microsoft yet. We haven't nailed up equally on all product lines in a very consistent methodical measurable way, and that's why I say we're in that awkward teenage phase.