Thanks everyone for joining us on The Security Influencers Channel. We're hosting brief and highly informative interviews with influential security leaders. Today, I'm thrilled to have Adam Shostack with us. Adam is a technologist, entrepreneur, author and game designer. (We'll talk about that a little bit.) He's a member of the Black Hat Review Board. He helped found the CVE.
He's the author of "Threat Modeling - Designing for Security." Lead designer of Microsoft's SDL threat modeling tool, version three and the game "Elevation of Privilege." He's also the co-author of "The New School of Information Security" and he co-designed "Control-Alt-Hack."
In this interview, we discuss the games that Adam has created what these games do to help improve security for everyone. He explains how the games help developers analyze security while having fun and they are also intended to help bring people into the security profession. We also talk about Agile and DevOps and how threat modeling fits in today's modern high speed development cycles. Finally, are there more security breaches happening today? Or is there simply more visibility into the attacks that are happening. Give the podcast a listen to hear Adam's insightful answers.
The following is a brief excerpt of our interview:
Jeff Williams: As software development accelerates, we've got Agile and even DevOps processes doing very quick release cycles. How does threat modeling fit into modern high speed development?
Adam Shostack: I think of threat modeling in those environments in two ways.
The first is threat modeling feeds into test driven development. If you'd like to be developing security tests for the pieces that you're building in this sprint, there's no faster way to figure out what those tests should be than to do a threat model. This doesn't have to be... sometimes people view threat models, they think big complex long project. It doesn't have to be. It can be an hour or two.
The second piece of integrating into Agile is when I talk to people doing Agile work, they talk a lot about the value of refactoring and understanding how the system is put together in a way that allows you to confidently add pieces to it in a way that allows you to confidently make changes to it. When I hear that, what I hear is that the importance of architectural consistency, the idea that everyone on the team shares a mental model of how the software is constructed, because without that, people are violating your data model. They're making calls to things that should be opaque to them.
And the same diagram that you used to say, "Here's the components and here's how they interact," can really feed into threat modeling. It can feed into other parts of security development activity. So a lot of times people talk about secure development in a waterfall model, because it's convenient as a model for helping understand how things plug in. But then they get very process heavy, with gates between the layers of the waterfall. Those gates are not necessarily what you want. Oftentimes the reason people move to an Agile model is because many of the process elements that people put in place don't seem to add enough value. A result of that is when the security folks put in these process heavy gates, they get thrown out in the move to Agile, not because they're not adding value, but because they're seen as process elements, not value elements.
Jeff Williams: Yeah. I heard Zane Lackey recently. He said something like, "Development organizations view delays as damage and route around them," which I thought was a nice play on censorship quote about the Internet, but I think it is true. So security ends up getting marginalized in those situations.
I like what you said about test cases and how to capture the output of a threat model as test cases in Agile and DevOps style development. I had a very good experience with that on the enterprise security API project at OWASP. We basically started with test cases and said, "Here's what the security controls have to do." They were incredibly empowering as we developed. It let us know that a change in our validation method was going to affect these other parts of the security controls that depended on it. I don't see a lot of people actually testing their security controls very well. They test that their applications are using the security controls, but they actually don't test the controls very well themselves at all.
Adam Shostack: All it really takes is one really good mistake. And you catch that good mistake... and I love the quote from Zane, because again, developers want to do the right thing. They want to build the high quality apps. If you give them ways to build the high quality apps, they work with you. And if you give them things that just need to be routed around to get their job done, they understand hacking. They understand working around controls.
Jeff Williams: Yeah.
Adam Shostack: We should take advantage of that and say, "Wow! You know, you're a natural hacker here. You're bypassing this thing that I set up. Awesome! How do we keep people outside the organization from doing the same thing to your code?"
Jeff Williams: I like that. That's a little judo move you just pulled. I like that. How do you see this? I want to dig back into this continuous real time application security. Is there a way that we can get away from these gates and really get developers doing their own security work?
Adam Shostack: We have to simplify. We have to make it feasible for people to go and do it. You want someone to go and do their own security work. What is it that you mean when you say that? I'll give you an example without naming names. I've been reading a web security book lately. It's a great book full of details, but I don't have a mental framework even with all of my work in security and even with work in web security, I can't keep all of these details in my head. If I handed this book to the person writing my new website, they would read it. They'd recall six or seven random anecdotes, but a lot of the issues relate to these very complex questions of encoding, right? You can encode all of these elements of a web page in so many different ways.
We can simplify that down and say, "Here's a library that gives you a canonicalized version of the strings that you're working with." If that library is fast enough and effective enough, then the developer doesn't need to know all of these little details. Again, one of the reasons I like STRIDE is that STRIDE, six things -- spoofing, tampering, repudiation, info disclosure, denial of service and elevation of privilege -- it's a framework. I use the "Star Wars" analogies to make it more memorable for people.
Jeff Williams: Yeah.
Adam Shostack: A developer can remember those things, whereas all of these little details about percent-encoding versus URL-encoding versus hash-encoding... I mean, I look at, for example, some of the great work people have done on cross site scripting cheat sheets. Cheat sheets are tens of pages long. How do I work with that and get my job done?
Jeff Williams: No, you're right. You really have to make a library for that to support folks. Then it simplifies the analysis process, right? Instead of asking, "Did you get every piece of input encoded correctly in every single place in your application?" All you have to ask is, "Did you use the security control?"
Adam Shostack: Uh-huh.
Jeff Williams: So it simplifies the threat model considerably.
Adam Shostack: Or even, "Is there any place where you're not, where you're working with a string that you're not calling a security control?" But yet it simplifies it and simplification is necessary.
Jeff Williams: Well, it's revolutionary. I used to give this talk about the railroad industry and what standardized shipping containers did to transform the shipping industry. They needed all these guys down on the loading dock that would unload random railroad cars and put it in another railroad car, because it wasn't all standardized. But once it was standardized on those containers, then you can just grab them off the boat with a crane and put it on the train, and everything's just super easy. People don't have to do it by hand anymore.
Adam Shostack: It's a great analogy.
To hear the rest of my interview with Adam, click here.