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

The 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-site scripting."

MG: Cross-site 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.

Posted by pschooff in Podcast | Permalink | Comments (0) | TrackBacks (0)

Virtualization is happening, and it's happening fast. Whether it's VMWare's inflated valuation, the recent acquisition of Xen by Citrix, or Microsoft actually shipping their Hyper-X technology EARLY (when was the last time Microsoft shipped anything early?), all you hear about is virtualization. The operational benefits of virtualizing servers are certainly apparent, but we are only now starting to discuss the security impact of having flexible computing resources that decouples the hardware enclosures from the computing environments. To be clear, there is still a lot of disagreement about what the real risks are relative to virtualization, so let me cover a bunch of the potential issues.

Hypervisor

The hypervisor is actually another operating system and thus needs to be secured like an operating system. If the hypervisor is owned, which is called hyperjacking, it's game over for all the servers that run on top of the hypervisor and given that virtual machines (VMs) can be moved dynamically between hypervisors running on separate machines, one jacked VM puts your entire data center at risk.

To their credit, VMWare and Xen are saying the right stuff and even spending some money to address the issue, as evidenced by VMWare's acquisition of Determina. But having been in the security business for a long time, I know nothing is totally secure. The good news is that there hasn’t really been a demonstrably successful attack on the hypervisor yet, but I wouldn’t bet that there won’t be. In any case, you need to be prepared for the inevitability of a hypervisor exploit.

The entire industry needs to keep pushing VMWare and the other virtualization players to ensure they have as effective a security research and quick response patching capability as the core operating system vendors.

Application Issues

To be clear, there isn't anything specific to virtualization that needs to be done within the application to make it more secure. But this gives me another opportunity to keep beating the drum for better secure application development practices. So make sure those applications are as tight as they can be because there is a lot more at stake in a virtualized environment. Remember, a vulnerable application running on the hypervisor could allow root access to OS, which in turn allows that VM to launch attacks against other virtual machines.

Operational Issues

Virtualization does complicate the software updating and patching process. Why? Becuase you are just dealing with a lot more machines to update as it’s so easy to just spin up another VM at will. So each VM needs to have a standard build, which should include some automated mechanism (meaning some kind of agent) for configuration management and/or patching. Trying to do this stuff manually will be a nightmare.

Virtualization also turns the network vs. host-based intrusion prevention debate on its ear. The reality is that it's hard to really determine what the "network" is in a virtualized environment. VMs running on the same machine will communicate with each other without communicating through the actual "network," so intrusion prevention devices will need to factor that in to remain relevant in an increasingly virtualized world.

One other point I'll make about virtualization security is that noise is going to become deafening in 2008. Every security vendor will be rolling out their virtualization "story" and it will become very confusing for customers. One option is basically to ignore it and that may be the best option. But if you feel compelled to try to understand what is going on, make sure to figure out whether the vendor is just running their stuff on a "virtual appliance" or whether they've done something specific for virtualization. There is a difference.

The bottom line for application developers is that virtualization is very similar to SOA. A lot of the underlying resources that drive applications like data and computing resources are virtual and therefore largely unknown. So part of building applications continues to be relying on "faith" that the data you are calling is the right data and that the requests that you are responding to are authentic and authorized requests. It would be counter-productive to build these security capabilities into the application logic like authentication and authorization because that defeats the purpose of the entire virtualization model.

The reality is regardless of whether the application is running on a real or "virtual" server, it needs to be built with proper input validation and protection against cross-site scripting and SQL Injection attacks. So from that standpoint, virtualization is more of the same, only a lot more (in terms of machines) and a lot faster.

Posted by pschooff in | Permalink | Comments (0) | TrackBacks (0)