When Did Security Pros Forget the User?

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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.”

Before I knew it, the Airport Extreme installer had found the settings—including the security settings, WPA2 key, etc.—from the existing router and the settings that were already on my Mac. Next, the Airport rebooted and was up and running with the old router’s SSID, WPA2 key, and such.

Wow!

No, this isn’t intended to be an advertisement for these two Apple products, really. My point is that someone (at Apple) clearly understood the use cases associated with these two devices. I’d seen this sort of thing many times with other aspects of software and product configurations, but rarely when it comes to security-related features.

You see, with use case analysis, you create a storyboard describing how the user could/should make use of a product, application, etc. You describe how the process ought to work. Then, you look at each use case and build it into the software design.

We’re not talking rocket science here, but applying this process to security features and settings can go a long way to making our users’ lives easier—and more secure at the same time.

Without even trying to do things securely, my Touch and my Airport Extreme are both configured to operate in a secure state. Turning on the secure mode email and Wi-Fi settings didn’t even require me to check a single box, press a single button, or any such action. Both products installed securely the first time, because the software designers understood the sort of use case that mattered to me.

When did you last encounter a product that made things that simple to do the secure thing?

My experience is that this sort of thing is all too rare these days, and that shouldn’t be the case. We ought to be making things simple and easy to be secure. We shouldn’t require our users to know the difference between, say, WPA2 Enterprise, WPA2 Personal, WPA, and WEP. Leave that knowledge to the security techies, and make it easy for the user to make the secure choice.