November, 2010

Hey everyone, Jeremy Dallman here. Last January we published our first two Quick Security Reference (QSR) papers covering Cross-site Scripting and SQL Injection. Since then, our goal has been to create more QSRs that give technology organizations the necessary information to quickly understand and address specific security threats from the perspectives of four important IT-focused job roles (business decision makers, architect/program manager, developer, and software tester). We also hope that QSRs will help organizations to begin establishing security practices that will serve as a framework for preventing and addressing future incidents.

Today, we are making available a new QSR addressing a security issue often discovered post-attack by IT and software development organizations: Exposure of Sensitive Information.

Accidental exposure of sensitive information is a common flaw criminals will look for when initiating attacks. This type of attack does not have a catchy acronym or get as much attention as some more popular classes of attacks. However, these flaws and the subsequent exposure of sensitive information are often canaries in the metaphorical software mine.

Failure to protect sensitive data and the inadvertent exposure of that sensitive information is a rapidly growing problem facing many software development organizations including mature ones. Attackers are finding ways to harvest valuable user information, launch direct attacks on systems, or use more sophisticated techniques based on accidentally exposed sensitive information. By better understanding these vulnerabilities that lead to inadvertent disclosure, one can more easily and efficiently deal with existing issues and implement ongoing solutions that help protect sensitive information and the users of that information.

We would encourage you to take a look at this QSR and think about where your organization’s sensitive information is stored, how that data is protected or used by your apps, and what practices you can put in place to protect the underlying infrastructure. Understanding the business risk, architecting a robust design, implementing practical defenses, and carefully validating their integrity are all vital practices you should be taking to ensure your business keeps singing.

Adam Shostack here.  At the end of BlueHat v10, I gave a 5 minute talk on Elevation of Privilege. I didn't have a slide deck, but rather a card deck, and so wanted to blog what I'd said and why it matters to those of you working to bring secure development to your organizations. Let me start with that.

Elevation of Privilege is a game for security. You can see the how & a bit of the why here. Now, it sounds strange to talk about a game for security. Security is serious stuff. We’re serious about it, and if you’re reading this blog, so are you.

As Michael Howard said in his keynote, security experts are often tremendously engaged and passionate about security. We know that we need to do it. Being serious about it doesn’t mean experts don’t have fun threat modeling. And when we bring some of the things we need to do to non-experts, they have a harder time getting into it. We need to bring security to developers and managers in ways which are understandable and engaging.

Games can help us make security activities more interesting and accessible.

So I want to talk a bit about why the game works and then how to make your own game.

First, why does a game help overcome cultural barriers?

• It looks cool, attractive and even fun. Bringing it out says this isn't going to be some security wonk telling you about something like cross-site integer overphlows for an hour after which the answer is to use anti-xss.
• It gives people new to threat modeling a structured way to explore (the suits) and a structured set of hints (the threats on the cards) to help them explore the various types of threats.
• It gives developers a way to learn about threat modeling that’s less, well, threatening.
• It gives people permission to disagree with each other and even their management by getting a threat out on paper "for the game."

And second, games are fun. You should make a game. Here's how I did it.

1. Define the problem. (EoP is an attempt to address a lack of "flow" in threat modeling.)
2. See if the problem you're solving can be addressed by a game. Work by Ross Smith of Microsoft indicates that there's two areas where games work well in the workplace. The first is games for learning new skills (where EoP fits). The second is what he calls "citizenship behaviors," things that support an organizational goal that take advantage of incidental skills. His work on "The Language Quality game" was of this sort. It gave our multi-national, multi-lingual workforce a way to see internationalized versions of Windows quickly and easily, and an easy channel for feedback. It then used leaderboards to encourage competitiveness and repeat play.  (There’s a bit more on the Language Quality Game in this Forbes article.)
3. Use an existing game as the framework. Existing games have worked-out mechanics, and some players will bring familiarity to the table. (This has been a benefit and a curse for EoP, which is basically the non-bidding variant of Spades. Some players get an aha moment very quickly, others more slowly.) Since I made EoP, I discovered the excellent "Art of Game Design: A Book of Lenses." If you're having trouble with the mechanics of your game, I highly recommend it.
4. Playtest, playtest, playtest. The original design for EoP had a tremendously complex scoring system, designed to align player motivation with the business goal. There were extra points for aces, for riffing on other people's threats, for playing an EoP (suit) card, etc. I simplified a lot after watching people scratch their head a lot in playtests.
5. Ship it! You've done the hard work, get it out there.

Making a game is fun, impactful and rewarding way to bring new ideas and new practices to your organization. If you’re having trouble rolling out secure development practices, why not try Elevation of Privilege or a game of your own?