We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

The Mike Rothman Security Report

Peter Schooff

What You Need to Know About Source Code Analysis: Mike Rothman Talks to Brian Chess

Vote 0 Votes

Learn more about secure coding from SearchSecurity.com

*** Editor's Note: Don't miss a single important development in security by getting ebizQ's weekly security newsletter delivered straight into your inbox. Just check Security Update and leave your email right here.

In this month's Mike Rothman Security Report podcast, Mike interviews Brian Chess of Fortify. Brian shares his wisdom about what's important relative to static code analysis, including some guidance on balancing scalability and precision. The flexibility of the rule set (especially to support legacy applications) is also a point of conversation, and then Brian really delves into the killer for most code analysis initiatives - ease-of-use. Overall, it's a good intro to what's important in Source Code Analysis.

During free association, Brian talks about PCI 6.6 and balancing code review with more active defenses like Web Application Firewalls. And speaking of fire, you'll get to hear a great analogy about how you can learn a lot about application security by taking a firehouse tour.

Listen to or download the 14:42 minute podcast below:

Download file

MR: Hello, this is Mike Rothman. Welcome back to the Mike Rothman Security Report hosted by my friends at the ebizQ Network. This month we have another great, great show, great guest and really an important topic. And this month we're going to talk about the idea of how do you select a Source Code Analysis project, program, solutions, setup tools, etc.

Because, again, I think that people are really finally on the development side starting to understand that there's a lot of leverage, there's a lot of benefit to eliminating security issues earlier in the development process and QA, certainly earlier than having to do a patch to deploy software, have to update websites and web applications. And to talk about this topic this month, I've enlisted a friend of mine named Brian Chess of Fortify Software. Brian, you there with me?

BC: Hi Mike, thanks for having me.

MR: Great. So Brian why don't you kind of start off and talk a little bit about Fortify and kind of what you do for a living and then we'll jump right into kind of some of the things that we need to watch for when we're looking for Source Code Analysis program or solution.

BC: Sure. Okay. So I'm one of the founders of Fortify. We got started about five years ago with the idea that we were going to help people try to build and maintain more secure software. And we're going to that with a set of products. Initially, a lot of security people are interested in tracking assessments and after they get a handle on -- oh, we got some security problems here, they get interested in remediation.

And, of course, the Holy Grail is just prevention, how can we help people stop introducing security problems into the code that they create. So at Fortify we do that with a set products. And the first one we're going to talk about today is Static Source Code Analysis.

Trying to look through code without running it and identify things that could be vulnerable or weak about the code. We also make software testing tools and tools that try and help people defend programs as they run. Okay. So we'll talk just a little about Static Source Code Analysis, in particular.

This is a topic that's near and dear to my heart because it's what I did my PhD on. And I did an engineering PhD and, of course, the real proof in engineering is well, can you actually build it and does it help people. So I think sort of, as Fortify is my real proof to the world that the academic that I worked actually does have practical merit.

MR: Well, and that's actually a great segue to kind of get into some of the challenges that an organization is going to have and face and when they start thinking about Source Code Analysis. And obviously, you guys been in this space for a number of different years.

When you sit down with a developer, when you sit down with a set developers and you say, listen, these are some of the gotcha's that you have to worry about when you start thinking about Static Code Analysis and kind of really looking into that source code. If you had to pick a handful of them, maybe two or three, what are the big gotcha's that these developers really have to worry about when embarking on this journey?

BC: Well, I'll try to pick a couple of things about the analysis capability itself that I think are probably the most important things to look for. And the first one I'll -- let me start off with maybe the most obvious and that is the algorithm that you use in order to go through the code and look for problems with it. And if you're any academic realm, this is it; this is 100% of the games.

You got to have some new algorithm that you can show people is the best effort. And usually that comes in at least two dimensions, scaleability and precision. So scaleability means the ability to look at a really humongous amount of code all at once and that's important, particularly, for security because security is all about context.

You can't really look at one line of code -- most of the time you can't look at one line of code and tell whether it's okay or not. You have to relate it to all of the code around it because the code around it might be what's protecting it. And of course, you got have precision too.

You can't just look at big bunch of code and say, oh, there's a problem in there. You better say precisely the problem is on this line and when there's an error interaction between these four things, then that's a security problem.

And so the outcome of good scalability and good precision is good prioritization of the problems with the code because not all problems are created equal. You know, there are little nit-picky things where you could do it a little bit better and that's good. You really ought to have an analysis capability that can point out all the little problems.

But what people want upfront is all the things where they could be had today. The kind of thing that somebody's going to be able to come in, find, and exploit easily. And so you got to prioritize on the look of issues that analysis algorithm produces in order to get that ranking right, that prioritization correct. I kind of lump that all under the academic side of things, the algorithms --

MR: Yep.

BC: -- that you might use. So that's item number one. I'll tell you the one that really takes just as much time and effort though is coming up with the rule set that drives the analysis capability. In other words, what are all the possible things that could wrong with the code? And so that defines not only the specifics of the vulnerabilities but how do other pieces of code interplay in order to define a vulnerability.

When I was in school, I could probably name have a dozen kinds of things that could go wrong with code, like buffer overflow. In other words, writing outside of array bounds that let someone take over a computer. And I possibly could've named that and maybe something like cross-site scripting where somebody can put their code on your webpage and essentially run any code they want in your user's browser.

I could've named a couple of those things but it turns out that the list gets really long when you start looking at more and more programing languages, when you start throwing in languages Java Script or PHP, or reach back to a language like COBOL. And so now you get actually literally hundreds of types of mistakes you could make and you got to write those all down in rule set to feed to your analysis algorithm to figure out what's essentially wrong with the code. And the rule set is just as important as algorithm.

MR: Yep. Now whose responsibility is it to build that rule set? Is it the kind of provider that you're looking for the tools? Is it the kind of developer that has to look and say, well, these are the things that are appropriate for my environment? Who bears the burden of that responsibility?

BC: Well, certainly the provider of these type analysis capacities should ship a good rule set that, for instance, finds things like buffer overflow or cross-site scripting because those are generic problems everybody has got. Now, the more interesting kinds of problems that you might encounter in your code could be specific to your particular program. And no providers are ever going to be able to give those to you because they don't know what your program is supposed to do.

MR: Right.

BC: So the ability to add rules to the system, to have programmers define their own rules, I think, is a pretty important one, often is an underutilized one. And it makes since that people when they first get started with Static Analysis they want to find the generic stuff.

As they get more mature, they can start adding rule sets on their own. I'll tell you what I've begun seeing lately, at least at Fortify, is people have started giving us rules. So for instance, CERT, wrote up a set of Fortify rules for their secure coding standards and then gave it to us so that we could distribute it to all of our users.

So this idea is that we're going to be sharing rule sets that accomplish different purposes; I think there is a lot of future there. So rule setting is item number two on my list.

MR: Okay. Good, number three?

BC: And when I was doing this stuff in academia, just did not even understand one iota of it and that is ease-of-use. And that's number three on my list for this reason. I guess this message is mostly geared to any security people in the audience and so here's my message to security people.

Programmers are never going to be security people. They've already got a job and they got a job writing code. We can't expect them to understand every kind of vulnerability out there up to the minute, completely have their knowledge of the security space; it just ain't going to happen.

And that means we always have to be transferring security expertise to non-experts. And if we don't that in an approachable fashion, then why would non-experts give us the time of day?

MR: You bet.

BC: So from a Static Analysis to the guy to do a good job of bridging that gap, bring expert security knowledge to non-experts. And it's a hard job for any kind of automation to go in there and look at your code and then to convince that there's a problem in code you just wrote because that's not something you want to hear -- as somebody who writes code.

MR: I think one of the key aspects of this whole progratic thing and those are great kind of tips in terms of what's going to help people understand what's important about Static Code Analysis. But it also bears at least a little bit of discussion around the whole program that's required to make this kind of initiative work because, again, you're going to be dealing with -- I won't call them hostile subjects.

But as you just said, Brian, at the end of the day most developers really don't want to know that they have security problems, it's not going to help them hit their delivery dates. And in most cases, the security folks may not have the political pull to actually keep a project behind or delay a project because of big security holes.

So again, a lot of this ease-of-use to me also gets into kind of making sure that the groundwork and the foundation has been laid so that this kind of change can actually take place in an organization, which is something that a lot of people don't really think about.

BC: So for the first year or two at Fortify, I really kind of grumbled a lot about the oh, those darn developers they don't care about security. And then somewhere in midstream I had this revelation that programmers actually think security is pretty cool, and it is. I mean it's really neat to think about how somebody might take advantage of a piece of software and contort it to do something it was never intended to do. And then there's, of course, there's the James Bond aspect --

MR: Right.

BC: -- getting into the secret files, or espionage, or thinking about how can you keep the bad guys out, that's all pretty cool stuff. The problem is that most people in software development process are told either subtly or not so subtly security ain't your problem, it ain't your job, go back, more features, I need them tomorrow. And at that point, first start thinking about, okay, well, how am I going to sweep all this other stuff under the rug?

Like, okay, well, if security ain't even suppose to be job, then if somebody tells me there's a security problem, I'm going to try and figure out I can weasel my way out of it. And so really, the problem with security usually start at top of the organization. It's very rare to encounter somebody who just will tell you explicitly, no, security that doesn't matter to me.

Usually, it's a little more subtle, like, oh yes, security that's really important but you can't have any extra time to work on it. It's just suppose to sort of come for free. That's the kind of a more subtle message that, hey, don't really pay attention to that stuff. And that's when you start having conflicts between the security folks and the people who are producing the functionality.

MR: Yep. So now let's kind of move into my favorite part of the show which is what I call free association. So I got two things I want to talk about today. I'll blurt them out. I know it's going to hard because we all certainly love the sound our own voices but if you can keep it to a couple of sentences. The first things that kind of come off the top of your head that'll be great. So let's start with PCI 6.6. Yeah, again, two or three sentence on 6.6.

BC: Oh boy, a horrible conflict. Its these two concepts that are really great which is you ought to look at your code, review your code. And this other concept that's really great which is you ought to actively protect your application like with something like an application firewall. But then they put this "or" in the middle. It shouldn't be an "or" it should be an "and". You should look at your code and build the right thing "and" you should actively protect it when it runs.

MR: You bet. That's perfect. That's exactly where I come down on the issue as well. And now that we're kind on the topic of web application firewalls, just give me another little bit on how kind of Static Code Analysis and really whole 360 approach that you guys take is really kind of complementary to what you should be doing with a web application firewall.

BC: Well, I mean we're right back on that same topic. If you think about how do you protect a building against fire? Well, you make sure that it's got emergency exits in it and that's something you design into the building, which also puts the sprinkler system in it. And that's an active defense against fire.

If there's a fire, the sprinklers go off and they try and put it out. And that's the exactly the same sort of thing that we're advocating with Fortify 360. In other words, take a look at the source code and try to wring the vulnerabilities out of the system, but also actively monitor that so you know who's attacking it, when they're attacking, how they're attacking. And that's how I see those two sides of the equation getting together.

MR: Yep. That's perfect. That's a great analogy. I hadn't heard that one before but, of course, I'll be happy to steal it as I do most of my great work. So with that, I want to thank Brian Chess from Fortify. Really appreciate you coming on the show today and writing some of your gospel as well sharing some of your wisdom about Static Code Analysis and the, obviously, on PCI and how to make the code review and the active defense or application firewall aspect of things works.

So thanks again, Brian. And with that, I will sign off another successful, at least in my own mind, version of the Mike Rothman Security Report here on ebizQ Network. Have a great month and we will be back next month with another show. Take care.

ebizQ is proud to bring you Security Incite's Mike Rothman, who podcasts and writes on application security and related topics.

Recently Commented On

Monthly Archives