Category: human factors

“The Phoenix Project” may be uncomfortable

The Phoenix Project as an important new novel, and it’s worth reading if you work in technology. As I read it, I was awfully uncomfortable with one of the characters, John. John is the information security officer in the company, and, to be frank, John does not come off well at the start of the book.

Before I get to the details, I want to talk about Gene Kim, the lead author. Gene got his start in security, having written the first free Tripwire program. Since then, he’s done key research in control effectiveness. He also accidentally demonstrated how far the complianciness industry has to go, as the COBIT standard hasn’t been updated based on his work, nor have they attempted to replicate it or refute it. Regardless, Gene gets operational information security very deeply.

So let’s talk frankly about John. John is a shrill jerk who thinks it’s a good idea to hold up business because he sees risk. He thinks of his job as risk prevention and compliance, and damn the cost to the business.

I’ve been there. Perhaps you have too. And if you’ve been there, John is an uncomfortable archetype to watch. Perhaps John is even treated too harshly. But as I said to Gene, pride goeth before the fall, and the fall cometh before redemption.

Me, I went through a lot of learning when Zero-Knowledge Systems pivoted. We had an amazing team, great technology, influencers and supporters out the wazoo, and we didn’t deliver on the goals. I spent a lot of time wallowing in what sells in security, what value propositions motivate people to buy, and how security is often a feature, not a value proposition.

Understanding where security fits in a business proposition gives me not only understanding but even sympathy for business leaders who listen to someone claim that if only the CSO reported to the CEO, they’d have a voice. That’s backwards. If the CSO has an understanding of the business, they’ll have a voice, and won’t need to report to the CEO. Also, the CEO is not the person with cycles to mentor a CSO to that understanding.

So if you’re outraged by how John is portrayed, I want to encourage you to ask yourself, are you outraged because it’s wrong, or outraged because it hurts?

The alcoholics say, the first step is admitting you have a problem. If you’re not there, maybe the first step is to go read the Phoenix Project and see if it hurts.

Infosec Lessons from Mario Batali's Kitchen

There was a story recently on NPR about kitchen waste, “No Simple Recipe For Weighing Food Waste At Mario Batali’s Lupa.” Now, normally, you’d think that a story on kitchen waste has nothing to do with information security, and you’d be right. But as I half listened to the story, I realized that it in fact was a story about a fellow, Andrew Shakman, and his quest to change business processes to address environmental priorities.

I also realized that I’ve heard him in meetings. Ok, it wasn’t Andrew, and the subject wasn’t food waste, but I think that makes the story all the more powerful for information security, because it’s easier to look at an apparently disconnected story, understand it, and then bring the lessons on home:

“Once we begin reducing food waste, we are spending less money on food because we’re not buying food to waste it; we’re spending less money on labor; we’re spending less money on energy to keep that food cold and heat it up; we’re spending less on waste disposal,” says Shakman.

That’s right! Managing food waste doesn’t have to be a tax, it can be a profit center, and that’s awesome. Back to the story:

Lupa’s Chef di Cuisine Cruz Goler spent a couple of months working with the system. But he ran into some problems. After the first week, some of his staff just stopped weighing the food. But Goler says he didn’t want to “break their chops about some sort of vegetable scrap that doesn’t really mean anything.” Shakman believes those scraps do mean something when they add up over time. He says it’s just a matter of making the tracking a priority, even when a restaurant is really busy. “When we get busy, we don’t stop washing our hands; when we get busy, we don’t cut corners in quality on the plate,” says Shakman.

That’s right, too! We can declare priorities, and if only our thing is declared a priority, it’ll win! What’s more, what’s a priority is a matter of executive sponsorship. The fact that the health department will be upset if you don’t wash your hands — that’s just compliance. Imperfectly plated food? Look, people are at a restaurant to eat, not admire the food, and that plate’s gonna be all smudged up in just a minute. In other words, those priorities are driven by either the customer or an external party. No argument that any internal or consulting party brings in will match those. They’re priority 1, and that’s a small set of requirements.

But for me, the most heartbreaking quote came after the chef decided not to use the system in that restaurant:

Despite the failure of LeanPath in the Lupa kitchen, Shakman is still convinced his system can save restaurants money. But he’s learned that the battle against food waste, like so many battles people fight, has to start with winning hearts and minds.

It’s true, if we just win hearts and minds, people will re-prioritize their tasks. To an extent. But perhaps the issue is that to win hearts and minds, we sometimes need to listen to the objections, and find ways to address them. For example, if onion skins aren’t even used in stock, maybe those can just be dumped on a normal day. Maybe there’s a way to modify the system to only weigh scrap on 1 day out of 7, so that the cost of the system is lessened. I talked about similar issues in security in my “Engineers Are People, Too” talk, and the Elevation of Privilege game is an example of how to make a set of threat modeling tasks more attractive.

Lastly, I want to be clear that I’m using Mr. Shakman and his company as a strawman to critique behaviors I see in information security. Mr. Shakman is probably a great guy and dedicated entreprenuer who’s been taken way out of context in that story. From the company’s website and blog they have some happy customers. I mean them no harm, think what they’re trying to do is an awesome goal, and I wish them the best of luck.

The Questions Not Asked on Passwords

So there’s a pair of stories on choosing good passwords on the New York Times. The first is (as I write this) the most emailed story on the site, “How to Devise Passwords That Drive Hackers Away.” It quotes both Paul Kocher and Jeremiah Grossman, both of whom I respect. There’s also a follow-on story, “Readers Respond: Password Hygiene and Headaches.” The latter quotes AgileBits somewhat extensively, and perhaps even ironically, given that I had to publicly disagree with them about how securely they store passwords.

These are solid stories. That people email them around is evidence that people want to do better at this. That goes against the common belief of security folks that people choose to be insecure and will choose dancing pigs over security.

But I think, for all that, there’s an important question that’s not being asked. How much help are these?

If I follow all nine elements of advice from Paul and Jeremiah, how much more secure will I be? If I’m only going to follow one, which should it be? If I take different advice, how does that compare? And are users rationally rejecting all of this as too hard?

First, we need to get a bit more specific about the problem. Is it account compromise? Is it password failings leading to account compromise? Does it include backup authentication mechanisms? I’ll assume it’s unauthorized people being able to spoof the real account holder, and think of this as ‘shared secret’ authentication, thus including secret question backup auth systems, in large part because they’re vulnerable to exactly the same threats as passwords (although the probability and effectiveness of the attacks probably differ).

There are a number of threats to shared secret authentication schemes . I think we can categorize them as:

  • Finding (the post it attack or divorcing spouses)
  • Online Attacks
  • Offline Attacks (including password leaks)
  • Phishing

Password leaks are a common problem these days, and they’re a problem because they enable offline attacks, ranging from lookups to rainbow tables to more complex cracking. But how common are they? How do they compare relative to the other classes of attacks?

So to break down the important question a bit: At what frequency do these threats lead to compromised accounts? How effective is each piece of advice at mitigating that threat? What’s the effort involved in each? Without knowing those things, how should we assess the efficacy of the advice we’re giving?

My stock answer to all questions (more breach data!) does’t really work as well here. Unlike breach disclosures, where we’re talking about IT departments, some of these questions are informed by fairly private information.

I’d be interested in hearing your thoughts, especially on how we can get data to evaluate these questions.

Running a Game at Work

Friday, I had the pleasure of seeing Sebastian Deterding speak on ‘9.5 Theses About Gamification.’ I don’t want to blog his entire talk, but one of his theses relates to “playful reframing”, and I think it says a lot to how to run a game at work, or a game tournament at a conference.

In many ways, play is the opposite of work. Play is voluntary, with meaningful choices for players. In work, we are often told, to some extent or other, what to do. You can’t order people to play. You can order them to engage in a game, and even make them go through the motions. But you can’t order them to play. At best, you can get them to joylessly minimax their way through, optimizing for points to the best of their ability. And that’s a challenge for someone who wants to use a game, like Elevation of Privilege or Control-Alt-Hack at work.

One of the really interesting parts of the talk was “how to design to allow play,” and I want to share his points and riff off them a little. Bold are his points, to the best of my scribbling ability.

  • Support autonomy. Autonomy, choice, self-control. As Carse says, “if you must play, you cannot play.” So if you want to have people play Elevation of Privilege in a tournament, you could have that as one track, and a talk at the same time. Then everyone in the tournament has a higher chance of wanting to be there.
  • Create a safe space. When everyone is playing, we agree that the game is for its own sake, and take fairness and sportsmanship into account. If the game has massive external consequences, players are less likely to be playful.
  • Meta-communicate: This is play. Let people know that this is fun by telling them that it’s ok to have fun and be silly, that you’re going to go do that.
  • Model attitudes and behavior Do what you just told them: have fun and show that you’re having fun.
  • Use cues and associations. Do things to ensure that people see that what you’re doing is a game. Elevation of Privilege does this with its use of physical cards with silly pictures on them, with each card having a suit and number, and in a slew of other ways.
  • Disrupt standing frames A standing frame is all about the way people currently see the world. Sometimes, to get people into a game frame, you need to
  • Offer generative tools/toys. A generative tool is one that allows people to do varies and unpredictable things with it. So a Rubik’s Cube is less generative than Legos. Of course, pretty much everything is less generative than Legos.
  • Underspecify. So speaking of Legos, you know how the Legos they made 30 years ago were just some basic shapes, and now and then a special curvy piece, while today it seems like every set has a stack of limited use, specialized pieces? That’s under-specification to over-specification. The more you specify, the less room you have for playful exploration.
  • Provide invitations. Invite people to come play, both literally and metaphorically.

The other element of his talk that I thought was really interesting with regards to Elevation of Privilege was how he discussed Caillios‘ ludus/paidia continuum. Ludus is all about the structure of games: these rules, these activities, these scoring mechanisms, while paidia is about play. Consider kids playing with dolls. There are no rules, there’s unstructured interaction, exploration and tumultuousness.

In hindsight, Elevation of Privilege uses cues to bring people into a game space, but elements of the game (connecting threats to a system being threat modeled, rules for riffing on one another’s threats) are really more about playfulness than gamefulness.