Last day to save $500 for SANS San Diego 2013

Brian Chess, Chief Scientist for Fortify Software

Introduction


Table of Contents

Brian Chess, Chief Scientist for Fortify Software

June 9th, 2007
By Stephen Northcutt



Brian Chess, Chief Scientist, Fortify Software, has agreed to be interviewed for the security lab for this special series in web app security and we certainly thank him for his time.

Brian, can you tell us something about yourself, what do you like to do when you are not in front of a computer, Apple or Microsoft, favorite language to code it?


I've got a one-year-old son, Simon. These days I spend most of my non-work time exploring the world with him. He just pulled his first practical joke. He got his mother to take a bite out of an apricot that wasn't ripe. He giggled for 30 seconds and then required that the whole episode be repeated about 10 times.

Apple. It's pretty on the surface, but then there's a real computer underneath. Most satisfying.

When I get a chance to code these days, it's usually Java. I know it’s not vogue to say this, but I think explicit type declaration and checked exceptions are both good things.


It seems like what got you on the map in terms of leadership in the industry is static analysis. I have taken a look at your Eau Claire webpage.[1] Can you explain just what you mean by static analysis and why that is important?


Static analysis is about analyzing code without executing it. It’s a great way to find bugs in a fast and consistent manner. Static analysis is particularly good for finding security problems because a tool can bring a lot of security knowledge along with it. If you're not a security expert, it's easy to stumble into security trouble without knowing it. Even if you are a security expert, everybody makes mistakes, and so it's critical to have safeguards in place to prevent a little mistake from becoming a big incident.


And, static analysis really must be important to you because you have written a book on the subject, Secure Programming with Static Analysis[2], with co-author Jacob West? How did the two of you break up the work, as I read the book how will I know what is your work and what is Jacob’s?


Jacob and I worked together very closely on the book. In the end, I think we contributed about the same amount, but it would be hard to go back and figure out who wrote what. If you find a typo, it's probably something I wrote. Jacob is too precise for typos.


Writing a book is hard, it just takes so much time, but now that it is done, what do you feel the biggest personal benefit for you is? How about for the community?


As with any writing project, the primary benefit to me is that now I know what I think about the topic! Seriously, until you've been forced to write your opinions down, you probably don't know exactly what you think. Communication brings clarity.

For the community, this is the first book that really lays out what static analysis is all about, why it's so important for getting security right, and how we can use it to change the security landscape. Some people have accepted bad software security as the norm, but we show that it doesn't have to be that way.


What can you share about the web app security market segment, growing, shrinking, becoming more sophisticated? How would you describe the typical customer for the Fortify product mix?


Web app security is growing from all directions. Everyone is putting more applications on line, and the bad guys are finding increasingly sophisticated ways to exploit common Web mistakes. At some point in the past, software security was dominated by the buffer overflow problem and the various ways attackers could exploit buffer overflow vulnerabilities to take over your computer. With the Web, gaining control of the machine isn't nearly so interesting as mining the database.

One of the great things about working at Fortify is that I get to see a lot of different kinds of code. We have customers who are exclusively focused on Web applications, but we also have customers who are mostly worried about putting bulletproof code into operating systems, satellites or consumer electronics. Some of the stuff I'm most proud of are the bugs we've found in electronic voting machines. It’s a fantastic mix of concerns.


This is a question I like to ask everyone in this space, one of the unique things about web applications is that one programming error can be referenced in hundreds of instances, often all of them Internet reachable. What do you think the number one error is; the mistake a programmer can make to guarantee a spot in the hall of shame?


The number one mistake programmers make, whether they're writing a Web application or some other kind of code, is to trust the input they receive. Trusting input leads to injection attacks (SQL, LDAP, XML, you name it), buffer overflow, cross-site scripting, and a host of other problems. In the Seven Pernicious Kingdoms, a taxonomy of vulnerabilities we published in 2005 with Gary McGraw, "Input Validation and Representation" is Kingdom #1. (You can get more information on 7PK at http://www.fortify.com/vulncat/).


Brian, the security market continues to change, new threats evolve, what are the hottest trends right now in attacking web applications and what can we do to prevent them?


Attackers are beginning to figure out what they can really do with cross-site scripting (XSS) vulnerabilities. They used to use them for defacing a site, then XSS became the weapon of choice for better phishing. Now people are using XSS to build intranet port scanners, worms, and vulnerability scanners. Yikes!

The cross-site scripting problem might just be shaping up to be the next buffer overflow. We know what the problem is, but it's so ingrained in the way we write code for the Web, it's hard to make it go away. Keeping cross-site scripting out of your code takes a systematic and process-driven approach to security. If you're relying on the fact that your programmers are very clever or highly motivated, eventually someone is going to slip up.


On your website there is an advisory for Javascript Hijacking.[3] Can you give us an explanation of this? Also, it appears to be an attack against AJAX.[4]


JavaScript Hijacking is the first attack technique that specifically targets Ajax applications. It uses the fact that many Ajax frameworks have started transmitting data using Javascript-formatted messages, but Web browsers don't apply the same protections to JavaScript as they do to HTML, so they leave open the possibility that an attacker can read confidential data without authorization.


What advice do you have for someone in the security field to stay current on web app security, what is your favorite newsgroup, mailing list or other information source? I know you speak at events on a regular basis, where does a software developer go to get the inside scoop on application security?


For Web security, OWASP (http://www.owasp.org) is a great resource. For staying up-to-the minute, I like the Secure Coding mailing list (http://www.securecoding.org/list/). My favorite security shows are RSA and Blackhat, and both are increasingly focused on software development.


What haven’t I asked, this is your chance to grab the bully pulpit[5], a platform from which to persuasively advocate an agenda, and drive home your number one point that you are trying to make as a thought leader in the industry?


I've got two messages, one for security people and one for software developers.

To the security crowd: we can't do this alone. We need to engage the people who are building the software and get their help in making it secure. The tricky part is that we can't turn everyone into a security expert. We need to help non-experts make good security decisions.

To software developers: the world has changed. Security wasn't part of the job before, but it is now. It's hard, but it's not impossible. We have to build secure systems so that people can trust the software they use. Bad security adds to the coefficient of friction that slows down the adoption of technology. It's not an exaggeration to say that the continued expansion of the digital age depends on us being able to tame the software security problem.


Thanks for taking the time Brian!


Thanks for having me!

--------------------------------------------
1. http://www.vantuyl.com/chess/EauClaire/
2. http://www.awprofessional.com/bookstore/product.asp?isbn=0321424778&rl=1, http://www.awprofessional.com/bookstore/product.asp?isbn=0321424778&rl=1, http://www.awprofessional.com/bookstore/product.asp?isbn=0321424778&rl=1
3. http://www.fortify.com/index.jsp
4. http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1249966,00.html
5. http://www.c-span.org/guide/congress/glossary/bullypul.htm
<< Thought Leader Home
top^
<< Thought Leader Home

SANS CDI 2013 - DC

Latest Whitepapers

Building and Maintaining a &quot;Certifiable&quot; Workforce
By Robert J. Mavretich

How Can You Build and Leverage SNORT IDS Metrics to Reduce Risk?
By Tim Proffitt

Daisy Chain Authentication
By Courtney Imbert

Latest Tweets

NEW #SANS Survey: Security Analytics & Intelligence 2nd [...]
October 1, 2013 - 6:30 PM

Tips on how to convince your boss to let you train online wi [...]
October 1, 2013 - 6:23 PM

#2 Tip on how 2 convince your boss 2 let u train online: Fle [...]
October 1, 2013 - 3:00 PM

Contact Us

(301) 654-SANS (7267)
Mon-Fri 9am - 8pm EST/EDT
info@sans.org

"It has really been an eye opener concerning the depth of security training & awareness that SANS has to offer."
- Michael Hall, Drivesavers

"Because of the use of real-world examples it's easier to apply what you learn."
- Danny Hill, Friedkin Companies, Inc.

"The perfect balance of theory and hands-on experience."
- James D. Perry II, University of Tennessee