The Irony Of Preventing Security Failures

Gadi Evron muses about the possibility that a successful security program might result in result in difficulty justifying future spending.

The Irony Of Preventing Security Failures, Gadi Evron, Dark Reading

But what if nothing happens because we stopped it? That may be the most dangerous option in the long term […] The obvious risk is that the security industry will be accused of crying wolf and not believed next time when something serious happens.

Roll back to 2001 and the hype surrounding Code Red. The lead story on major news outlets was the impending implosion of the Internet. The Internet didn’t implode. The hype went away. Slammer circa 2003 snuck up on the world, wreaked havoc, major corporate networks imploded, the internet hiccupped for a few hours. I’d like to think that Code Red was pretty good at culling out the incompetent sysadmins and raising the awareness of patching and hardening amongst the competent but clueless, and that Slammer was pretty good at culling out the incompetent IT departments and raising the awareness of the clueless CIO’s and executives.

Do we need to fear our own success?

Here’s a proposal. Simply allow your peers (or competitors) to continue to fail at security, and use their failure to justify continuing to spend money on your own success. You shouldn’t have too much trouble finding peer failures to use as your benchmarks. I’m pretty sure that the average executive can observe the impact of security events on peers and competitors compared to the lack of similar internal events and associate the difference with the level of competence and funding of the internal IT.

If corporate executives can’t figure that out on their own, I’ll bet we can come up with a couple of power points with impressive looking but indecipherable charts to help them out.

Secret Questions are not a Secret

Technology Review took a look at an advance copy of a study that validates what Ms. Palin already knew. Secret questions don’t help much: 

In research to be presented at the IEEE Symposium on Security and Privacy this week […] the researchers found that 28 percent of the people who knew and were trusted by the study's participants could guess the correct answers to the participant's secret questions. Even people not trusted by the participant still had a 17 percent chance of guessing the correct answer to a secret question. 

This is a fundamental and well-known problem. Putting real numbers on it should help those who are in the design meeting where secret questions get brought up.

To re-hash the secret question problem, either I answer the questions correctly and risk a 1 in 5 chance that a stranger will guess them, or I fabricate unique, nonsensical answers. If the fabricated answers are such that they can’t be reasonably guessed, then there isn’t much chance that I’ll remember what I answered, so I’m stuck writing them down somewhere and tracking them for a decade or so.

Obviously there are solutions that I can implement myself, like using a password safe of some type to store the made-up questions and answers. But what about the vast majority of ordinary users? How many of them are going to set up a password safe, figure out how to keep it up to date, replicate it to a safe location and not lock themselves out? Not many. They’ll have no choice but to write everything down.

I can image trying to explain to non-technical users that they need to have made-up answers to made-up questions, and that the made up questions and answers must be unique for each on line account, and the questions and answers need to be atypical enough that someone close to them can’t guess the answers even if they know the questions, and that instead of writing the questions and answers down, they need to store the made up questions and answers in a magic piece of software called a ‘password safe’, and they need to put a really strong password that they’ll remember and nobody else will guess on the password safe, and that they can’t write that down either, and they need to replicate the password safe data file to some other media, and if they forget the password to the password safe or lose the password safe data file, they’ll lose access to just about everything.

“Hey ma – here’s what I need you to do…download something called password safe…”

“I already have a safe….”

There’s got to be a better way.

Hijacking a Botnet – What Can We Learn?

The Computer Security Group at UC Santa Barbara hijacked a botnet long enough to grab interesting data. But if are keeping up with security news, you already know that.

Among the findings:

• Passwords tend to be weak (not new).
• Passwords tend to get reused across multiple web sites (not new). 
• Botnet sizes may be overestimated (interesting).