Category: data

Paper: The Security of Password Expiration

The security of modern password expiration: an algorithmic framework and empirical analysis, by Yingian Zhang, Fabian Monrose and Michael Reiter. (ACM DOI link)

This paper presents the first large-scale study of the success of password expiration in meeting its intended purpose, namely revoking access to an account by an attacker who has captured the account’s password. Using a dataset of over 7700 accounts, we assess the extent to which passwords that users choose to replace expired ones pose an obstacle to the attacker’s continued access. We develop a framework by which an attacker can search for a user’s new password from an old one, and design an efficient algorithm to build an approximately optimal search strategy. We then use this strategy to measure the difficulty of breaking newly chosen passwords from old ones. We believe our study calls into question the merit of continuing the practice of password expiration.

This is the sort of work that we at the New School love. Take a best practice recommended by just about everyone for what seems like excellent reasons, and take notice of the fact that human beings are going to game your practice. Then get some actual data, and see how effective the practice is.

Unfortunately, we lack data on rates of compromise for organizations with different password change policies. So it’s hard to tell if password policies actually do any good, or which ones do good. However, we can guess that not making your default password “stratfor” is a good idea.

ACM gets a link because they allow you to post copies of your own papers, rather than inhibiting the progress of science by locking it all up.

Top 5 Security Influencers of 2011

I really like Gunnar Peterson’s post on “Top 5 Security Influencers:”

Its December and so its the season for lists. Here is my list of Top 5 Security Influencers, this is the list with the people who have the biggest (good and/or bad) influence on your company and user’s security:

My list is slightly different:

  1. The Person Coding Your App
  2. Your DBA
  3. Your Testers
  4. Your Ops team
  5. The person with the data
  6. Uma Thurman
  7. You

That’s right, without data to argue an effective case for investing in security, you have less influence than Uma Thurman. And even if you have more influence than her, if you want to be in the top 5, you better be the person bringing the data.

As long as we’re hiding everything that might allow us to judge comparative effectiveness, we’re going to continue making no progress.

Ahh, but which Uma?
265446 1020 A
Update: Chris Hoff asks “But WHICH Uma? Kill Bill Uma or Pulp Fiction Uma?” and sadly, I have to answer: The Truth About Cats and Dogs Uma. You remember. Silly romantic comedy where guy falls in love with radio veterinarian Janeane Garofalo, who’s embarrassed about her looks? And Uma plays her gorgeous but vapid neighbor? That’s the Uma with the more influence than you. The one who spends time trying to not be bubbly when her audition for a newscaster job leads off with “hundreds of people feared dead in a nuclear accident?” Yeah. That Uma. Because at least she’s nice to look at while going on about stuff no one cares about. But you know? If you show up with some chops and some useful data to back your claims, you can do better than that.

On the downside, you’re unlikely to ever be as influential as Kill Bill Uma. Because, you know, she has a sword, and a demonstrated willingness to slice the heads off of people who argue with her, and a don’t-care attitude about jail. It’s hard to top that for short term influence. Just ask the 3rd guy trying to code your app, and hoping it doesn’t crash. He’s got eyes for no one not carrying that sword.

Fixes to Wysopal’s Application Security Debt Metric

In two recent blog posts (here and here), Chris Wysopal (CTO of Veracode) proposed a metric called “Application Security Debt”.  I like the general idea, but I have found some problems in his method.  In this post, I suggest corrections that will be both more credible and more accurate, at least for half of the formula.  The second half is harder to do right and needs more thinking.

Continue reading

Java Security & Criminals

Brian Krebs has an interesting article on “Java: A Gift to Exploit Pack Makers.” What makes it interesting is that since information security professionals share data so well, Brian was able to go to the top IDS makers and get practical advice on what really works to secure a system.

Sorry, dreaming there for a minute.

What Brian really did was go look at what attackers are doing in their commercial exploit kits, and discovered that Java exploits have surpassed Adobe exploits in ‘his’ sample.

I’m curious what you all think of the approach. What can we learn from attacker toolkits and marketing pitches? What are the limits of this?

Fines or Reporting?

Over at the Office of Inadequate Security, Dissent does excellent work digging into several perspectives on Discover Card breaches: Discover’s reports, and the (apparent) silence of breached entities.

I’m concerned that for many of the breaches they report, we have never seen breach reports filed by the entities themselves nor media reports on the incidents. For now, though, let’s start with what I found when I received one batch of their reports to NYS. Keep in mind as you read the summaries that we are only talking about the number of Discover card users affected by the incidents and for only two states. The numbers affected by each incident could be considerably higher, but since the entities themselves never filed breach reports with NYS or Maine, I have no additional information at this time. (“Staring into the abyss: how many breaches go unreported?“)

As much as I’d like to encourage security and punish failures, I’d like to first see us know how much is wrong so we can estimate progress over time.

Alex on Science and Risk Management

Alex Hutton has an excellent post on his work blog:

Jim Tiller of British Telecom has published a blog post called “Risk Appetite, Counting Security Calories Won’t Help”. I’d like to discuss Jim’s blog post because I think it shows a difference in perspectives between our organizations. I’d also like to counter a few of the assertions he makes because I find these to be misunderstandings that are common in our industry.

“Anyone who knows me or has subjected themselves to my writings knows I have some uneasiness with today’s role of risk. It’s not the process, but more of how there is so much focus on risk as if it were a science – but it’s not. Not even close.”

Let me begin my rebuttal by first arguing that risk management, at its basis, is at least ”scientific work”. What I mean by that is elegantly summed up by Eliezer Yudkowsky on the Less Wrong blog. To use Eliezer’s words, I’ll offer that scientific work is “the reporting of the likelihood ratios for any popular hypotheses.”

You should go read “Risk Appetite: Counting Risk Calories is All You Can Do“.

Counterpoint: There is demand for security innovation

Over in the Securosis blog, Rich Mogull wrote a post “There is No Market for Security Innovation.

Rich is right that there’s currently no market, but that doesn’t mean there’s no demand. I think there are a couple of inhibitors to the market, but the key one is that transaction costs are kept high by a lack of data about outcomes. Every one of the startups selling you a product will claim that it blocks “APT” and “Data loss” but none of them have compelling data about efficacy. None of us have great, broad data about what problems lead to breaches, and none of us have data about what solutions products effectively prevent those problems. None of us have data about how often the products are deployed and managed effectively.

So when the salespeople come in with their “$204 per record” and compliance demands and all the rest, there’s no good way to distinguish between it, and as a result, the market is a slog for both real innovation and snake-oil.

If someone could innovate to address these problems, say by collecting and analyzing data about what really happens inside a company, they might have a business.

More broadly, for a market to function, there needs to be supply which exists in plenty, and demand, which exists, and a way to link them. And there’s the chasm.

I’ll also point out that we discussed innovation a bit on pages 126-127 of The New School, where we opine that much security needs to be integrated into your infrastructure and thus will be purchased from larger vendors.