How to develop software the secure, Gary McGraw way
A comprehensive collection of articles, videos and more, hand-picked by our editors
In this interview conducted at RSA Conference 2011, Gary McGraw, chief technology officer at Cigital Inc., a software security and quality consulting firm, explains how more organizations are embracing software development processes to improve the code they are producing. Using the right tools and procedures helps eliminates serious vulnerabilities and reduces the risk of successful attacks, McGraw said. The noted software security expert is helping develop the third iteration of the Building Security In Maturity Model (BSIMM) , which documents how major software firms incorporate security controls into the software development lifecycle.
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 firstname.lastname@example.org.
Secure application development processes improving, expert says
Robert Westervelt: Talk a little bit about some of the innovative
technologies that are out there, that relate to secure software
Gary McGraw: I will do that. I think things really started at the
end of the software lifecycle, if you think about automation of
software security. Look at the early days of black box testing
tools we had AppScan, that got bought by IBM, we had SPI
Dynamics, that got bought by HP. Those were black box,
end-of-lifecycle, ' Oh Darn, we really had a problem, bad
distometers'; pretty important technology. The next thing
that came along were white box static analysis tools that actually
get into the code and tell you where your problem is in the code;
bug finders. Those bug finders include Fortify, Ounce, Clockwork,
Coverity, and there was a round of acquisitions there too. IBM
bought Ounce. HP bought Fortify, that means the breadth of the
market that can be addressed by these tools has gone up
significantly. Now it is getting into the broad middle-market to
small, medium sized businesses that can get access and use
these tools. Very, very cool.
The next big thing is going to be automating architectural risk
analysis and threat modeling. We all know that is a difficult
thing, but if you look at what Microsoft has done over the last
five years in their approach to threat modeling, things have
changed a lot since 'Writing Secure Code' and 'Writing Secure
Code 2', the book written by Mike Howard and Steve Lipner, and
the book by Window Snyder called 'Threat Modeling', and Frank
(Swiderski), I cannot remember Frank's last name. Those books
Described Microsoft's first few iterations at threat modeling. Guess
what? That is not how they do it anymore. They needed to figure
out how to make this thing scale. They made a lot of progress at
Microsoft, and they even have some tools that help you automate
it. Mostly they help by giving you a list of flaws to look for
and helping you think about how to describe your system slightly
more formally, from a data flow perspective.
I believe that the room for startups there, in terms of
innovation, has to do with that, figuring out flaws and writing
those flaws down so you can consistently apply them to your
design, then being able to do a better job with dependency
analysis, so that the dependency analysis is a little bit more
thorough, that you are guaranteed that you can get coverage and
find some number of problems. Threat modeling is still a
difficult thing, still takes smart people to do it, but it is
just like software architecture. That is a difficult thing,
takes smart people to do it. That does not mean we do not do it,
and that does not mean we despair about it. I think there is
tons of room for innovation there, and I expect to see lots of
growth in little companies and startups there, over the next
couple, three years.
Robert Westervelt: We are talking a lot about new software, the
creation of new software. There is a ton of legacy software out
Gary McGraw: Tons, yes.
Robert Westervelt: The attackers are finding the vulnerabilities in these
legacy applications. Are we getting any better on fixing those
vulnerable applications, that vulnerable software?
Gary McGraw: Yes.
Robert Westervelt: The one company that comes to mind is Adobe . . .
Gary McGraw: Yes.
Robert Westervelt: . . . coming out with Reader X and trying to put
Sandboxing in there.
Gary McGraw: Adobe has made a ton of progress in software security
in the last year and a half or so. In fact, I was telling you about how
we re-measured some firms that are involved in the B-SIM; one of
those firms happens to be Adobe. I can assure you that they
have made great progress, in terms of the objective measurement
of their software security initiative over the last year and a
half, ever since Brad Arkin really took over the leadership of
software security at Adobe.
They have a huge problem to solve. Reader is a big, gigantic
thing with all sorts of crazy guts and kitchen sinks, it reminds
me of Common Lisp; there is stuff in there and you say, 'Why is
one of those in there? Why don't you remove that?' They say, 'We
are not so sure what happens if we rip that out. What is going
to happen to this? The whole Reader might just fall apart.' I
think they are taking some steps towards getting a secure
version of Reader. One of those steps is the Sandboxing idea.
The real question from a technical perspective is, 'Is
Sandboxing at the user level? Like putting a wrapper around that
program in user-land, sufficient for security?' Some people
believe that you need to have an entire virtual machine image
that you run something like the Reader in. That would be what,
say Invencia, does.
Robert Westervelt: Exactly.
Gary McGraw: There is some debate about, how much is secure enough.
The cool thing is that the Adobe of three years ago, they really did not
have very much of a handle on software security. The Adobe of
now, they know that they got a problem, and they are seriously
working to solve it; you love to see that in our field. You like
to see companies step up, take responsibility, and say, 'We know
we have an issue, we are going to work on it, and we are going
to earn your trust.' I think Adobe is doing that.
Robert Westervelt: Is there a lack of skilled security professionals involved
in software development right now? Can you talk about what you
think the state of the job market is, for this area.
Gary McGraw: The job market, actually, is pretty d** good. If you have
software security skills, there are tons of jobs for you that
are open right now. We have hired about 25 people at Sigital
over the last, I would say, 8 months. We are growing very fast
and demand for our consulting services is high.
Robert Westervelt: What kind of people?
Gary McGraw: Finding the people can be a challenge. Software
security people need to be software people first and security people
second. That is, if you already understand software and you have been
coding for many, many years, I started coding when I was 16, you
can learn about security and you can become quite a proficient
software security guy. It is not impossible, but it is much
harder to start as a security person with a CISSP, and then try
to learn about software development, think about how software is
constructed, and become a software security person that way. I
would much rather find software guys and make them into software
security guys, than find security guys and make them into
software security guys.
That said, there are a lot more people that have some amount of
clue in software security than there used to be. We talked
about the University systems doing a slightly better job than
they were before; in fact, we have kids who come out of school,
who understand what Static Analysis is, they understand that
software issues often lead to fundamental security problems, and
that bugs and flaws lead to these security issues that we have
to deal with now. That is a pretty big scene change, from even a
decade ago. A decade ago you would say software to the security
guys and they would shake their heads and say, 'Oh, those
developers ruined, broken stuff. They are ruining my network.'
You would go to the developers and you would say security, and
they would say, 'We hate those security people. They turn off
all our privileges. We cannot get anything done. We can't even
run our compilers admin, what heck?'
I think that the gap where there was nobody in the middle is
gone away now, and that there is a whole class of people that
number in the thousands, of software security professionals. In
fact, if you look at the software security groups among the 33
BCM companies and you add them all up, you are talking a couple
thousand people doing software security everyday for a living,
and that is pretty cool. That is a lot more than you would
think. I think there are these pockets of professional activity.
Places like Microsoft has a hundred people in their core
software security group, and 400 people in the satellite, that
is 500 people working on software security. Pretty darn cool.
Robert Westervelt: Bug bounty programs, I do want to ask about that. What is
your take on those particular programs? Microsoft refuses to
support a bug bounty program.
Gary McGraw: Good for Microsoft. My view is that it is much better for an
enterprise to pay for QA, by having professional testers and QA
people and security testers, than it is for them to not pay for
QA and have a bug bounty system where they hope that their QA is
outsourced to whoever happens to be on the internet.
Robert Westervelt: It is a financial issue, then?
Gary McGraw: It is not just a financial issue, it is a responsibility issue.
The irresponsible approach is to expect your customers and users
to test your code for you. The responsible approach is to take
that on yourself and to do it, to hire QA, hire pen testers,
hire Sigital to do some white box security testing, that sort of
thing. That is a much superior approach than just a piece meal,
'Our users are going to debug it for us.'
Robert Westervelt: The flip side of the coin though, is that the independent
security researchers that discover these flaws are trying to get
companies like Microsoft to patch them quickly, or quicker.
Gary McGraw: Microsoft used to have a willy-nilly patch process years ago
and it took forever.
Robert Westervelt: Of course, that has changed., and it took forever.
Gary McGraw: Now there is Patch Tuesday, and we can make fun of it all we
want, but it really makes the job of patch management and patch
distribution much easier for professionals. I do think that
Microsoft and other responsible companies react pretty well
these days when a vulnerability gets discovered by and large.
Back in 1996 when I was poking holes in Java with Ed Felton, we
could not get anybody to pay attention unless we involved the
press. But we were not doing that for fame and glory reasons, we
were doing that for, that was the only way to make Microsoft pay
attention, and Sun, and Netscape, remember, there was a company
called Netscape back then. Things have changed a ton since then,
I mean, huge amounts in the intervening 15 years. Now Microsoft
has its own internal bug finding guys, they have an entire
process by which you take a bug and it goes through an entire
release process, to get fixed and patched properly. That is
I think that people that complain about response time, they have
no idea what they are talking about, they do not even, they were
not even alive 15 years ago, so I do not think they understand
how things have improved, in one case. In the other case is, if
you would like to be paid professionally to find bugs, get a job
finding bugs; work for Sigital, ICEC, Microsoft or Adobe. There
are people who do this professionally every day, and it is
pretty amazing what you can learn when you are inside of an
enterprise doing software security. Much different than sort of
the lone wolf consulting, typical OWASP guy view of the world.
There is a professional class of software security people that
is pretty sizable, a few thousand people, and that is great. I
think that is very good progress for the field.
Robert Westervelt: This might be a little touchy subject with you because you
got relationships with people at Microsoft and people at Google.
Gary McGraw: And I didn't disappear in a puff of logic.
Robert Westervelt: There have been Google researchers that have been coming
out with vulnerabilities . . .
Gary McGraw: Aimed at Microsoft, yes.
Robert Westervelt: . . . aimed at Microsoft, and Microsoft has done the same
thing back to Google. It seems like, how responsible is that?
Gary McGraw: That is very childish.
Robert Westervelt: What is your take on the whole thing?
Gary McGraw: My take is that it is a really bad idea.
Robert Westervelt: What else is going on here? Is this just part of the
Gary McGraw: It is just jockeying and positioning; it is beyond the browser
war. It is the war of the future of software and the future
platform and who is going to own the Cloud.
Robert Westervelt: This is not just going to be Microsoft and Google going
back and forth.
Gary McGraw: Oh, no.
Robert Westervelt: Companies are going to be doing this, you think?
Gary McGraw: I hope not, I do not think it is a hugely common
phenomenon, and I would discourage it. I do not think it is the
best way to go about it. If you think about it, we are all in glass
houses, and smart people who live in glass houses do not work on
throwing rocks, they work on improving the thickness of the
glass in their house. It reminds me very much of cyber war, to
tell you the truth, Rob. The cyber war guys, some of the warrior
class in the United States want to spend a lot of money on cyber
weaponry, the F22 equivalent in cyber, that is offense if you
will. I think it is much better for us to think about defending
ourselves, to think about building secure systems so that it is
much harder to carry out cyber war, it is not just, and you
cannot do it with a pea shooter. Once again, we all live in
glass houses, so we have to be responsible citizens inside of
that glass house.
Another thing that has happened with the BCM Project is some
very large organizations have decided that one measurement does
not make sense for them. For example, at Bank of America we have
done 9 BCM measurements because they are 8 major divisions. You
think about Bank of America, retail banks, country wide, all of
the things that role up into what Bank of America is now. It
turns out, those divisions, fairly major divisions, all needed
their own BCM measurement. Now we can compare the progress among
the divisions at Bank of America, and at the highest levels, do
some strategizing and do some planning about software security
at a big, gigantic firm. We have done the same thing at McEsson,
and there is another firm, that I cannot name, that we have done
the same thing. Sometime for doing multiple measurements inside
of a firm, is another distinction to say, BCM 3 work or BCM 2.
Robert Westervelt: We are hearing a lot about mobile apps now. How is that
going to affect the software development lifecycle process? Does
it have an effect on it? Does this mean we have to go back to
the drawing board?
Gary McGraw: It is an opportunity to do things right, if you think about it.
Mobile platforms are just like what PCs were, maybe in better
shape, back in the '80s, except some mobile platforms have
kernals and everything, and multiple modes of user. The thing
is, to the extent that apps are written by organizations that
have a software security clue, that is an opportunity to get
things right. To the extent that people are just writing any old
app and throwing it against the wall to see if it sticks, we
might have a problem. I can assure you that every single vendor
of mobile platforms, every single operator like Verizon, for
example, and every single ship manufacturer, for example the
Qualcomm guys, are thinking very carefully about software
security. Qualcomm has been a member of the BCM project for 2
and a half years, and they have quite an extensive software
security group. There are, in fact, people that have been
thinking about software security from the very beginning in
Mobile security is going to be a challenge for many, many
reasons, but I think that we can leverage and take advantage of
the real progress that we have made in software security. You
and I have talked about this; I may be the only optimist in all
of computer security thinking that we are actually making
progress on this problem. Things are not going to get totally
solved tomorrow, but I think we are doing a better job in
software security in 2011 than we were in 2008.