When Did Security Pros Forget the User?

When did we forget about the users? At some point, it seems to me that the security community simply forgot about the users. I want to know why.

Many people believe—perhaps with good reason—security is simply an inhibiting function, preventing our users from doing what they feel they need to. They say they want to do something; we tell them no.

Sure, we security folk know that’s an unfair generalization, and the reality isn’t all that bad, but at the very least it’s a common perception of what the IT security department does. We tell them no.

But that’s not the way it should be. We can do better. Let’s take a moment to learn something from software developers. They often make use of a simple process called use cases. We stand to learn something useful from the use case process.

First, let’s consider an example of failure to consider use cases, although this failure has nothing to do with computers. While traveling on business last week in London, I experienced a men’s room washbasin with two water spigots: a hot and a cold one. No big deal, right? Well, the two spigots dispensed their water separately, about 6 inches apart from each other. So, how does one wash his hands with warm—not hot—water?

Do you rapidly move your hands from the hot to the cold, in hopes that the average will somehow be to your liking? Do they expect us to fill the sink with some hot and some cold, and then wash our hands in the resulting pool of warm water? That must be what they intended, but what ends up happening is that you either wash with scalding hot, or with ice cold. Crazy, and all because no one considered the use case when “designing” the washbasin.

A more user-focused way of designing the wash basin would have been to consider how a user would want to wash his hands—under a single warm water flow—and design a single spigot accordingly. Pretty straight forward stuff, right?

So where’s the security lesson?

I’ve had two recent experiences that made me sit up and take notice of how the designers clearly “got” the use case and made a secure and user-friendly experience. The first was with my Apple iPod Touch, and the second was with my Apple Airport Extreme.

When I configured my Touch, it automatically looked at my email server settings and replicated them on the Touch. Not a huge accomplishment, you say?

Well, I use IMAP and SMTP, like many of us do, but on my server, I only allow SSL encrypted IMAP and SMTP traffic, and the SMTP service only accepts authenticated connections. With most email clients, if they support this configuration at all, it takes some custom configuring via an “advanced” button or some such.

But, much to my shock and awe, the Touch grabbed these configuration oddities and set things up exactly as I wanted them, without having to do a thing as the user. Voila – my Touch email client was configured as securely as the email client on my Mac is.

First try. Amazing.

Next came the Airport Extreme. I was replacing an older Wi-Fi router that was clearly on its last legs. (It kept dropping connections and losing some of its configuration settings randomly, but was kind of sort of functional otherwise. Clearly on its death bed.) In the configuration wizard for the Airport, I was asked if I was replacing an existing router with the new one. I’d never seen that question before, and I went ahead and selected “yes.”