Click here to sign up for Mike's SOA Security Roundtable coming up soon!

In this month's Mike Rothman Security Report Podcast, Mike interviews Michael Gavin from Security Innovation about the importance and need for a secure software development life cycle (SDLC) to really build security into the application, as opposed to bolting it on. It was a pretty wide ranging conversation, as the two Michael's discussed:

- The leading SDLC methodologies
- The importance of getting the developers on board
- How Microsoft showed the world it could be done
- Whether an SDLC is compatible with agile programing methodologies

Michael Gavin is also subjected to the free association treatment, and you can hear his thoughts on cross-site scripting and static code analysis.

Listen to or download the 11:13 minute podcast below:

Download file

Transcript follows below with MR for Mike Rothman and MG for Michael Gavin.

MR: Hi! This is Mike Rothman. Welcome to another edition of the Mike Rothman Security Report brought to you by ebizQ networks. This week we're going to talk a little bit about software development lifecycles and specifically, the secure software development lifecycle. Because, you know, this is one of the things that's very difficult for a lot of security folks to get their arms around. You know, how do I talk to my engineers and developers about why it's important to maybe start developing software in a secure fashion as opposed to trying to bolt on security at the end or overcome a lot of issues that they may have once the code is written, tested and deployed.

You know, how do you deal with those engineers and most importantly ? because that tends to be, software tends to be the path of least resistance for folks today. So, I'm very pleased to have lined up Michael Gavin who works for a company named Security Innovation to be our guest this week. So welcome, Michael. You're there, yes?

MG: I'm here. Thank you very much. It's a pleasure to be here with you Mike. Thanks for having us on.

You're right? application security is a very hot topic now. That is the path of least resistance. If you follow the Semantic Internet threat reports that come out every half year? every single half year report of the last five semesters, if you want to call them that, has rated the software avenue as about 70 percent of the attacks that come through there. So you're right on.

MR: You bet. So we kind of jump into the topic of, you know, how you start building security into the software process, why don't you tell us a little bit about yourself and Security Innovation?

MG: Okay. I don't like to talk about myself that much, so I'll talk about the company instead. Basically we specialize in application security. We deal with how to build and deploy applications in a secure fashion. We're software engineers ourselves which I think is very important. One of the points you made in the introduction was that it's very difficult for security people to talk to software developers and engineering managers. And I think that's a big problem there because early on, most of the security folks were network security folks. There were very, very few of us application security folks types around.

And application developers speak a different language than security folks who speak a different language, than business folks who speak a different language, than network folks. And I think that the network security folks talking to the application developers about security and what was important to them is just a really bad match in terms of conversation.

So what we do is all kinds of consulting around application security and we do a lot of training around application security as well to help with that translation factor for the developers.

MR: Yeah. Well, that's great and obviously that's one of the reasons I wanted to get you on the show, Michael. Because, you know, I speak to a lot of practitioners out there and they have a hard time really explaining to the developers and the engineers why it's important to actually build security into the process as opposed to, again, bolting it on later.

So what are kind of maybe one or things that you do when you're training these folks in terms of, you know, making the point that it is important?

MG: Basically, I like to use the analogy of performance. I'm an old guy. So back in the late 60s and early 70s, people had been developing these programs on mainframes for a while. And the hardware wasn't accelerating quickly enough and the software was getting one more blow and slowing down. And everybody thought, "Well, we'll just deal with the functionality. Let's just build a program, get it working and then we'll worry about the performance afterwards." And then for four or five years they tried this. And that approach was doomed to failure. Because basically, with performance, once the design is fixed, there are just a small number of tweaks that you can apply in a number of different places but the design may prevent you from actually doing the things that would actually help you accelerate the performance the most. To make the program much faster.

Security is the exact same way. Basically, if you make certain design decisions without thinking of the security ramifications of them, you might paint yourself into a corner. So you can't really overcome those inherent vulnerabilities that you designed into the program. It's too late then.

MR: Yeah. So then, and I guess a lot of what you are alluding to is this concept of the, you know, secure software development lifecycle. So, you know, do you guys at Security Innovation have a methodology or a process or something that you work with clients on to help them get their arms around this and really make it a systematic part of how they develop software?

MG: Yeah, Mike. That's a great question. And there are a couple of different methodologies out there. Let's talk about Microsoft for a minute. They've done what was probably a very painful thing for a company to do. They said, "Look, we have to make security a very important core part of our business." And I think that's a key that a lot of companies don't actually understand at this point and we try to educate people about this.

You have to have management by and you have to have everybody on board with this for this to work. But if your application connects to any kind of resource of value or of sensitivity, you're going to get a black eye because someone's going to break into it and abuse that resource through your application and you're going to be blamed for it. So that's way developing the security is so important. It's a quality issue that really goes to the credibility and the reputation of the company.

So what Microsoft did, was they said, "Look, we're taking a beating. Our competitors are going to eat us alive if we keep having all these security releases and hot fixes and whatnot. We have to get this under control." So they took a step back and they developed their own methodology. Gary McGraw and others, John Viaga published a number of books which have a slightly different methodology. The Department of Homeland Security has a methodology.

Basically, we work with our customers to help them to build security in throughout the entire software development lifecycle. We don't say you have to do it any one particular way. We try to be flexible with you and work around your particular processes, because everyone's processes are different. But help you to incorporate security considerations throughout the design. So early on, we talk about software security requirements. What assets are you protecting? How valuable are they? How much do you need to protect them? What kind of protection do you need? Do you need to have some kind of authentication mechanism or authorization mechanism? Is auditing important? Those kinds of things.

MR: Yeah.

MG: And right through, you know, secure design, threat modeling and attack surface reduction, making it harder for people to get into your code and then secure code rules and methodologies and secure code reviews and ways to check that in the development process and the testing process straight through to deployment.

MR: Yep. So an entire cradle-to-grave type of ---

MG: -- exactly.

MR: So if you could sit and pinpoint a couple of things that folks have pretty much screwed up. You know, what would those be? If there's one or two. Because, you know again, it's hard. If it wasn't hard, everybody would be doing it and we wouldn't even be having this discussion. So obviously, it's hard. So if you kind of in the next minute or so that we have left, if you can just kind of pinpoint a couple of things that folks screw up and they need to be wary of. I think that would be very useful.

MG: I wouldn't say that folks screw up. I think there are two issues. One is, we fail to convince developers that it's important enough for them to incorporate into their development lifecycle and to treat it just as much as they treat usability or performance or any other characteristic of their program. Developers are under a lot of pressure to get things out. So we have to help convince them to do this the right way.

The other thing that is really difficult is that everybody comes at it from the wrong end. Your natural inclination is to say, "Well, what's an attacker going to do now that I've built my program? How are they going to get in?" You try to beat them to the punch and you know, it's an arms race and then, attackers? there's a lot of them and they have a lot of time. So it's much better if you can start at the other end.

And the reason people don't is they don't know how to. It's much harder to automate the processes at the front end. But there are some methodologies there. There are some techniques, how to capture software security requirements, how to do threat modeling, those types of things that we can help teach people and people can learn elsewhere as well, that are really critical for people to start jumping into.

MR: And just one final thing. You guys work with all these new, you know, fangled agile types of development methodologies, you know, Scrum or extreme programming or any of these things. Because I know there are lot of folks that are a little wary of kind of adding a whole bunch of more structure because they are trying to move towards more of an agile and less structured ?

MG: Right.

MR: -- application development methodology.

MG: Yeah, that's a good question. One of the really nice things about some of the agile development methods is pure programming, right? Well, we advocate that you have someone who has some security expertise or raises security concerns as you go into the peer program. So you make it another part of the process. The goal isn't to slow it down or make it more cumbersome. The goal is to add security to each component, each step that you're making, in a way that works for you, that works sufficiently for you and allows you to do it.

MR: Yep. I think that's a great overview of, you know, kind of the secure SDLC, provides a number of different things. And you know, really points to Microsoft as a great case for how you can, it is possible, to turn your organization on a dime and really embrace the idea of secure coding up and down the stack. So with that, let's kind of transition into the little section I call "free association." We'll do it quickly.

So what I'll do, Michael, in terms of ground rules is, you know, blurt out a topic and then, you know, you just answer in a sentence or two and we'll see where it goes. The first I'll say is "cross-eyed scripting."

MG: Cross-eyed scripting. This is something that a lot of people didn't give much credence to early on. It's like, "yeah, that's a cute little vulnerability." But you really have to pay attention to each new threat as it comes out. Each new vulnerability or class of vulnerabilities because it really can lead to something more serious.

MR: Dealing with resistant developers.

MG: You know, as a consultant you don't want to get into an adversarial relationship. You really have to understand what their pain points are. You have to listen to them and understand where they are coming from and then try and figure out how to make this important to them as it should be because the results can be pretty damaging to their career.

MR: You bet. And one final one, static code analysis.

MG: Just like any other single item throughout the software development lifecycle. It's a great thing. It has a lot of limitations. Right? It's not a panacea. It's not the magic pill. There isn't any. You have to do a lot of work throughout a lot of different phases. Those tools are great. It's wonderful to have some automation on your side. They find a lot of things. They are not going to find everything. You can't rely on them strictly just by themselves.

MR: You bet. And with that, we will wrap up yet another edition of the Mike Rothman Security Report. Once again, I would like to give a deep thanks to Michael Gavin of Security Innovation for being our guest this month. And we will see you guys next time.

MG: Pleasure to be with you, Michael. Thank you.

MR: Take care. Goodbye.