![Mike Bracken at Code for America]()
Last year our boss Mike Bracken talked at the Code for America Summit in San Francisco, and spoke about the need to strike a balance between usability and security. There is a point beyond which over-zealous security gets in the way, and puts people off using the technology that’s being protected.
We wanted to explore this in a bit more detail, so we asked out director of technical architecture, James Stewart, to talk us through the issues. We wanted to know: how much security is too much? How do you find the right balance?
In this short interview, James talks about taking a “measured approach” to security that looks at likely risks in context. New services must be secure and fit for purpose. It’s no use making something secure if that results in a service that’s unusable. In practical terms, that means making sure that everyone on a project is thinking about security and possible “misuse cases” – it’s not a job that should be hived off to a separate team.
To listen to the full interview (about 10 minutes), click the play button in the embedded SoundCloud widget below. Alternatively, you can download the audio directly from the Internet Archive.
Follow James on Twitter: @jystewart
Follow Giles on Twitter: @gilest
Transcript
Interviewer: Hello. Can you tell me who you are and what you do?
James Stewart: I’m James Stewart. By GDS standards I’m a long-time member of the GDS team, and I’m currently director of technical architecture.
Interviewer: What is a director of technical architecture?
James: It’s a new role that we’ve only introduced quite recently. It’s about establishing a new way of doing technical architecture in an agile, digital delivery kind of world, making sure that the way that we build systems is flexible; that we’re approaching things in a coherent way across government, and also taking responsibility for the products that we build at GDS and the platforms that we build; that they’re fit for purpose; that they can evolve as our user needs evolve. All that kind of thing.
Interviewer: For the benefit of the uninitiated, what is technical architecture? What does that mean?
James: Well, that really depends who you talk to, and the organisation that you’re working within. But generally, it is about taking a step back from the way that bits of code are being written, to think about the system as a whole, thinking about products as a whole, or platforms, and making sure that they’re fitting together in a coherent way; that they’re exhibiting whatever characteristics your organisation needs, and that you’re looking a little bit ahead. In agile, you’re always trying to focus on which value, which bit of value are we trying to deliver immediately? What are we trying to get to next? But it’s always important to be looking a little way ahead. Is this going to be flexible to the directions that we want to take it in? Is this coming together to meet the general requirements to meet user needs? Rather than just, does this piece of code work in a micro-perspective?
Interviewer: Fantastic. Let’s talk a little bit about security. When Mike Bracken went to the Code for America conference, one of the things he said was this:
The third one is security. I don’t mean Snowden security; I mean this pernicious view that security must come ahead of usability at all times. When I started in government, I was given a laptop that required 22 discreet pieces of information so that I could work it. I couldn’t send an email to all my staff, and why not? Because of security. We’ve just got to get usability ahead of security.
Two things arise out of that. What is the “pernicious view” that he’s talking about, and why do we need to get usability ahead of security?
James: It’s very common for people to take a very, very risk-averse approach to anything that they’re building. Whenever you’re providing a service or building a system that people have to use, there’s a set of risks around that, and that’s the case whether you’re doing it in government or doing it for something that you might use in your home. But you have to be thoughtful and careful about balancing risks.
Rather than listing out everything that could possibly go wrong with something that you build, and then protecting against every single one of those, think about what, would the outcome be if that thing went wrong? Think about how likely is it that that’s going to happen? And take appropriate steps to prepare for those situations.
People in general aren’t great at thinking through risks and thinking through things in that kind of measured way. We can get scared quite easily, or we worry about things which are what’s on our mind, not the sort of balanced, really think this through approach. Often in computing, in service design in general, in all of those areas, people have taken this approach of: “We need to make this secure because people are going to want to attack it, and therefore we need to lock it down in every way that we possibly can.” But that stops people using it, and it means that any efforts that you’re making to meet user needs are flustered; they’re blocked by the fact that people can’t use this thing.
If we want people to work with government online, to adopt Digital by Default, we need to make those services that people want to use, and that are simple enough for them to use, and we need to start with that. We need to start with: how are we going to make these services really great? How are we going to make them attractive to people? Then think about the risks around that in that context, and always driving back to: how are we making this fit for purpose and something that people will want to use?
That can often mean having to think outside the box around security; think about how you can, not just lock things down, but perhaps seek verification for something through a different channel. Rather than making it such that you have to enter lots and lots of pieces of information to sign into a system, that you use different channels for checking that information.
You know that somebody’s got a mobile phone. You could send a message to that; gives you a little bit of extra verification of their identity. Rather than asking them half a dozen extra questions, can we use these different tools at our disposal to balance the security and the usability of a service? It’s really vital that we do that, if we actually want people to use these services. People just aren’t going to use them unless they can.
Interviewer: How do you strike the right balance between those two opposing criteria; between the security and the usability? At what point does something become insecure because it’s too usable, or the other way round?
James: I think we have to not really set those things up quite in opposition. They’re often in tension, but they’re not necessarily opposed. You might find that you think that the best way to give people a great experience of a service is to put on one page on the web everything that you know about them. There’s a lot of risk associated with doing that. It means that somebody who’s malicious who’s just looking over their shoulder suddenly knows everything about them, and can use that to commit identity theft, so you probably don’t want to be doing that.
But actually when you look at it, putting everything that you know on one page is probably information overload for somebody as well. One of our design principles is: “Do less”, and it’s a really good idea to think about that throughout the whole thing. “What’s the real core of what we’re trying to do and what we’re trying to offer people? Let’s not decorate that with lots of extra information.”
That’s a really good starting point, is that: “Do less. What’s the real core of what we’re trying to do?” Then start doing real user research, and exploring, “What are the particular risks that we’re trying to protect against, here, and how do other people think about those? How do the users of our service think about it?”
A very common one is if you’re sending an email to somebody as part of your service, and you’re putting a link in that, that sets up a context where it might be quite easy for somebody to forge that email and send people a link that looks like it’s to your service, but actually it’s to their honeypot thing that will capture their credit card details and steal all their money. It’s called phishing. We have to really think about how we’re signalling to people whether this is a genuine email or not, and you can only really do that if you start sitting down with them, understanding: how do they read those emails? How else to they receive information? How do you give them confidence in the right things? A lot of it’s back to, work with the users as closely as you can.
Most people who use the internet much have received a lot of phishing emails, whether they call them that or not, but the things that pretend to be from HSBC or pretend to be from HMRC, offering you a tax refund, if you just give them every piece of information they could possibly want. People know there’s an issue there, and then they just want to make sure that they’re not really inconvenienced by what you do.
But generally there are all sorts of techniques, and you have to think about what could go wrong if this thing got exploited. How likely is it that they’ll be exploited, and then what do we do? Do you actually make sure that you always include a phone number; that people can call up to verify that this email was real? Or do you just offer them part of the information that they need, so that they can match that with what they already know about the way that they’ve used your service, and see that it’s genuine?
It’s one of the many things that we do that really lends itself to the cross-disciplinary way of doing things, that we want everybody to be building into their services. There are content issues, there are design issues, there’s technology, there’s just general service design; it all comes together.
All too often, it’s been the case that people have approached security as something that either people who deal with compliance and writing documents deal with, or that the techies deal with. It’s a fundamental part of the service; it’s not this separate thing that one team thinks about, and that email thing is a really good example of why that’s the case.
Interviewer: The whole team needs to be thinking about it from day one?
James: Yes. But making sure that they do it proportionately; that they don’t get paralysed by fears about security; that they’re just sort of conscious. There are some nice techniques, like one of our colleagues elsewhere in government talked about “misuse cases”. When you’re writing some user stories and thinking about your use cases for some feature that you’re building, also think about the misuse cases; think about how somebody might play with what you’ve built, or abuse it. That’s quite a nice technique.
