Security > 140 Conversation with Brian Chess

Here is part one of a conversation with Fortify's Chief Scientist Brian Chess. We discuss software security automation, deployment, and practical ways to improve the efficacy of software security programs. Brian has worked in the software security field since software security was just a wee young sprout, and now that software security has a seat at the grown up table, I wanted to get his thoughts on how the field is progressing.

 

GP: There are some recent studies of average chess players with a good process and computers, being able to beat chessmasters far above their ability, computers’ analytical ability extend the player’s competence. In most software security groups one of the biggest challenges is to scale. The software security team is typically a single digit percentage of the size of the development staff. How does automation on static analysis help these teams? What ways can software security teams scale out to maximize their impact on the development organization?

 

BC:  I wasn't a particularly good math student when I was a kid.  All through grade school my mother (a math professor) would tell me "you'll get better at it."  It turns out she was right, but not because I needed more practice.  She had figured out that I wasn't a reliable performer when it comes to the repetitive stuff--working a page of long division problems, for example.  Instead of practice, I just needed to get to the math classes where there was more concept and less grinding.  By the time I hit calculus, the balance tipped.

 

Computers are good at grinding.  In 2011 people are still a lot better at making intuitive leaps.  So the challenge for any team that needs to protect a big frontier is to find ways to let the computer do its thing and free them up to do theirs.  On the software security front, there are two big jobs to organize:

 

1. Standardization.  Get your development teams to address the same security needs in the same way every time.  Help them share the best solutions.  Kick and scream when they decide to do things their own way.  It's a heck of a lot easier to figure out when someone is not using the standard solution than it is to figure out exactly how an attacker is going to outwit their homegrown hairball of a protection mechanism.

 

1. Automation.  Check all of the code for all of the dumb security mistakes programmers can make.  That means static analysis and dynamic analysis.  When you get good at standardization, you can rely less on having the automation find vulnerabilities and switch over to having it look for places where standards aren't being followed.  We're never going to automatically find all of the security problems in a piece of software, but we can take on some of the more tedious and error-prone work and give the security team more time to work on problems where humans do best.

 

((Part 2 of the conversation is here))