A company can begin to inject security into its software development processes only after conducting an analysis of what is currently in place, according to Chris Eng, senior security researcher at Veracode Inc. In this video, Eng said the easiest way to start is with static analysis testing to get a measure of the common mistakes that developers are making. Firms can also add security awareness training for developers, he said. The interview was conducted Wednesday at the SOURCE Boston 2011 security conference.
Editor's note: This news story is part of SearchSecurity.com's "Eye on" series that brings together various perspectives on security topics throughout the year from SearchSecurity and its sister sites. In the month of April the series examines secure software development.
Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact email@example.com.
Secure software development: Getting started
Chris Eng: Sure, well, there are a lot of things that you can do starting all the
way at the very beginning of the life cycle. You can do education. You can
do design reviews, threat modeling, teach about secure coding, all the way
through actual testing and static analysis, dynamic analysis, penetration
testing. All of those things are part of a comprehensive SDLC.
A lot of times the easiest things to start out with are testing, just
because it disrupts the development type of the lease. You don't have to
change what developers are doing day-to-day, but it gives you a baseline
for figuring out where you're at. You take a product that's already
shipping or about to ship, you want to pin test or maybe a static analysis
of it and just figure out what's in there, and that kind of tells you how
much are good offers, or what are the common mistakes they're making. Then,
you can build from there and figure out what the next steps might be.
Q: So, that kind of self-analysis is kind of an important piece, just to
know your processes?
Chris Eng: You have to have a baseline. You need to know where you're starting
from. Just like from an educational perspective, you want to know how much
do my developers even know about security before I put some MBOs on their
plan that says you have to code securely. Is that even fair, unless you
know that they actually understand what they're supposed to be doing and
what you expect them to be doing.
So, setting a baseline just by understanding or having them take an exam or
go through an e-learning sort of scenario, figure out where their
gaps are, give them the requisite training and then tell them, 'OK, you're
accountable for secure code.' It's kind of unfair to do that without giving
them the time and giving them the resources to do so.
Q: Are there any particular methodologies or frameworks that companies can
rely on, and where do you think they can go for maybe, a starting point
Chris Eng: Well, I don't think there's any one answer for that. The SDL is
differently applied in all sorts of different places, and it depends on
what your development methodology is as well. For a waterfall type
development, that's going to be very different from an agile.
A good starting point for somebody who's never done any of this before is
to look at Microsoft SDL. They have a lot of resources around what they do
and what the different phrases are in their SDL. That applies more to a
traditional development cycle because they're producing projects with long
maps. You can have these distinct stages where you're doing threat modeling
and data flow diagrams. Then, you have multiple iterations of different
types of testing.
If you have more of a modern project that's doing a lot of iterations with
Agile or Agile-like, then you really have to adapt your security process to
account for that. If you have six or eight week sprints, you're not going
to be doing a full threat model and a full manual pin test every cycle.
There's not enough time for that. You have to target it more maybe, threat
model only the new features that are going to be released. Do a very
targeted pin testing, making sure that you are doing code reviews, a
security critical part to the code.
You have to bite it off in little chunks as opposed to making this one long
project. It all depends on how your company or your business unit is set
up, the development life cycle, and what security processes you used to