Scout Brody, Ph.D. on Creating Security Systems Usable for All

State of Cybercrime

With the spring just a few short weeks away, it’s a good time to clean the bedroom windows, dust off the ceiling fans, and discard old security notions that have been taking up valuable mind space.

What do you replace those security concepts with?

How about ones that say that security systems are not binary “on-off” concepts, but instead can be seen as a gentle gradient. And where user experiences developed by researchers create security products that actually, um, work. This new world is conceived by Scout Brody, executive director of Simply Secure, a nonprofit dedicated to leveraging user interface design to make security easier and more intuitive to use.

“UX design is a critical part of any system, including security systems that are only meant to be used by highly technical expert users,” according to Brody. “ So if you have a system that helps monitor network traffic, if it’s not usable by the people who are designed to use it or it’s designed for, then it’s not actually going to help them do their jobs.”

In the first part of my interview with Scout Brody, we cover why security systems aren’t binary, the value of user interface designers, and how to cross pollinate user personas with threat models.

Transcript

Cindy Ng: Scout Brody has long been passionate about improving the usability of security tools. Rather than a tech and product only mindset, she advocates a human first or empathy first mindset. Processes such as user experience and human centered design can help improve the way humans and security technologies interact. As a former product manager at Google, she worked on projects such as 2-Step Verification and the Android operating system. Now she's an executive director at Simply Secure, a nonprofit dedicated to crafting usable and secure technologies, while making them available to everyone.

The cornerstone of your work, Scout, you say consumers abdicate their security and privacy for ease, convenience and because sometimes they're strong-armed to yielding all their personal information in order to download an app or use a piece of technology because that's how technology is being developed. And the way you describe how security and privacy technologies are being developed, that they're not binary concepts but gradient, and can you elaborate more on what that means?

Scout Brody: Well, Cindy, I think that as a security professional in our field we tend to think of things in absolutes and we tend to be constantly striving for the ideal. So if you're an I.T. professional working in a corporate environment, you are trying to do your utmost to make the settings as secure as it possibly can be because that's how you define success as a security professional. When it comes to thinking about security for end-users however, it's important to recognize that not everyone has the same definition of what security they need to meet their needs or what privacy means to them.

So one good example might be that you have, say you know a government worker who lives in Washington, D.C., and is very concerned they might have what we call in the security business, a particular threat model or they're worried about those people accessing their information, for professional purposes. They might be concerned about organized crime or foreign governments or all sorts of different things. And that's a very different threat model than someone who is a stay-at-home dad in Minnesota for example, who you know may not have those same concerns when he's going and posting adorable photos of his kids on Facebook, that that information might be compromised or used to hurt him or his professional life in any way.

So I think this notion that there is no one definition of what is secure but I like to talk about usability and design as being gradient in the same way that security is. So in security, although we tend to think of it as an absolute, when we get down to the practice of security, and we very rarely say "Oh, this system is secure." No, we say "This system is secure against threats A, B and C," it's secure in the face of a particular threat model. And similarly when you talk about a system being usable or useful to end-users, we have to say, "This is usable and useful to these users in these contexts."

Cindy Ng: I like what you mentioned about threat model and context. Can you provide us an example of how you would align a threat model alongside with the technology you have, what would that look like?

Scout Brody: Well, I think that it depends, I think I want to clarify that when you say design, we're talking not just about a system architecture design but we're really talking about the design of the entire piece of software, including the user-interface or as you like to say in the design side, the user experience or U.X. And a U.X. design, I maintain, is a critical part of any system, including security systems, even security systems that are really only meant to be used by highly technical expert users. So if you have an I.T. system that helps monitor network traffic, if it's not usable by the people who are designed to use it or that it's designed for, then it's not going to actually help them do their job, it's not actually going to be successful as a piece of software.

Re-emphasizing that design doesn't just mean architecture design, it may mean design also of the user experience. And I think it's really important when we're looking at the software design process to consider a partnership between the user experience designer and the software designer, including the security expert. So I think that it's important to look at the user experience from a security perspective and to look at the security from a user experience perspective, and that's one of the reasons that we advocate a deep partnership between security folks and user experience folks. That they collaborate on the design of the system from the beginning, but they try to understand one another's priorities and concerns and that they try and sort of use one another's language to talk about those priorities for the system.

Cindy Ng: And when you talk about U.X. design and then design in general, what is the business value of a designer and why is that partnership so critical? Because these days anyone can install Illustrator or Photoshop and start drawing or creating or you can submit a request online for any kind of artwork to be created and within 24 hours, 48 hours you get what you requested. What's the difference between the kind of design I'm talking about versus a partnership?

Scout Brody: Well my favorite analogy when talking to security folks about the importance of, you know, high quality in-house design, is to talk about cryptanalysis or cryptographic protocol design. We do not expect that a designer, a user experience designer or even an average sort of lay person software developer will be able to develop a secure cryptographic protocol. We don't say, "Oh but you know what, I have a terminal window, I've got a text editor, I can write my own cryptographic protocol, I understand prime numbers, I understand, like, the concept of factoring, so therefore I am totally qualified to write a cryptographic protocol." No.

We also don't say, "Oh well but there are freelance people on the internet that I can hire to write my cryptographic protocols for me, so I'm just gonna, you know, outsource this on this site here, I need a protocol that allows me to change it in this way under these parameters, "Hey freelance cryptographer that I met on the internet, that I found on a freelance website, can you design this for me?" No, absolutely not. And why is that? It's because we recognize the value of the expertise that goes into designing a cryptographic protocol. We recognize that there are deep concerns, deep nuances that come to bear when a cryptographic protocol is put into place. There are ways in which it can break that are very hard to predict unless you have a lot of background in designing and analyzing these protocols.

Although it's not quite as extreme when you look at U.X. design because there are certainly I guess probably more qualified U.X. designers out there than there are truly qualified cryptographic, you know, cryptographers. It is an important analogy to draw because we don't expect designers to do cryptography, why do we expect cryptographers or software developers in general to do design? I think that there is that sort of assumption that anyone can do design, anyone can pop open Illustrator and then come out with a user experience that is going to be workable. Or the expectation that you can just hire sort of a freelancer to come in and work for a two week sprint and put something out for your product, really underestimates the importance of the user experience design to the success of your product.

I think that you look at all of the ways in which systems fail, security systems in particular, because security's way of talking about this is, "Oh humans are the weakest link." And I say, "No, it's not that humans are the weakest link, it's that the user interface that you have created or the human policies that you have put in place are broken." And that they're not taking the human system into account in the way that you need to. And that's exactly what U.X. designers can help you do, is understand. U.X. designers and researchers, can help you understand the users that are going to be using your system and help you can put in place interfaces and human processes that will allow them to be successful in using your system.

Cindy Ng: You mentioned in a previous conversation we had about U.X. designers developing user personas, can you talk a little bit about why they're used in creating a product you might be building?

Scout Brody: Yeah, so user personas are a handy sort of reference that is created out of a user experience research process. So the idea is that ideally, you know, U.X. designers or researchers have the opportunity to go and spend some quality time talking to people who would ideally be users of the system that's being designed. So if you're designing a system for system administrators like I mentioned earlier, to do network analysis, you know, ideally you'd have the opportunity to go and actually talk to these people. You know, go see them in their workplace, experience the challenges that they face, the things that they're concerned about, the tools that they use today, what they like about them and what they don't like about them. And ideally you would have the opportunity to talk to a great variety of folks who do these things.

And on the upside of this research process, you would have all of this data about the various different people you talk to. And you go through a sort of informal clustering process to try and capture that data in a succinct way that the user experience designers can then move forward with their design, bearing all of that information in mind. And that sort of abstraction is called a user persona. The idea is that talk to 20 different system administrators from around the globe and you come out with four or five different user personas that sort of reflect the needs and challenges that those users face.

So you might have a user persona named Annabelle, and Annabelle is a very experienced system administrator who is overworked because she has too many meetings and gets too many emails and too many notifications, and is really looking for a system that will help her sort of cut through all of the noise and really identify the important signals. And then you might have a user persona named Jim, and Jim is a more junior system administrator who has the time to really go through and read all every single email notifications and understand what it means, things like that, and really wants to be able to have lots of detail at his fingertips. So these are two distinct sort of personalities that are based in the actual user research that you did that help inform your design and end up allowing you to have sort of a shorthand to bear in mind each of these different users' needs as you're going through the process of designing your system.

One really interesting and compelling idea that I've come across for the past couple of years is the notion of using user personas instead of cross-pollinating them with threat model. And the idea here is, okay you are a user experience designer and you have these different user personas that you're using to try and design a system that will work for a great diversity of users, can you also consider the possibility of having user personas for your potential attackers? So if you are working in partnership with your security professional who is working on a project, can you say, "Okay what are the threats that we think are facing our software?"

Okay, we expect that there is going to be an attacker who is sort of a script kiddie persona. That there is going to be an attacker who is a nation state actor. We expect there is going to be a criminal, you know, organized crime attacker. And what are the different capabilities of these attackers and what is our system going to do, both at the architecture level and at the user experience level, to try and be resilient to these things? And I think it's a sort of interesting way of bringing the expertise and the structure from the two different domains, security and user experience, and working together to highlight the needs and vulnerabilities of a piece of software you're trying to develop and process.