Discover PerformanceHP Software's community for IT leaders // September 2013
In software security, maturity is hard won
Enterprise security authority Gary McGraw explains why, after so many years, proactive software security practices still aren’t universal.
A dozen years ago, Gary McGraw and co-author John Viega wrote a book with a very simple premise: build security into software from the start, rather than sprinkling it on as an afterthought. A dozen years after the debut of Building Secure Software: How to Avoid Security Problems the Right Way, McGraw says there’s been a great deal of progress—but still not enough.
Not that McGraw hasn’t continued spreading the word. He wrote Software Security: Building Security In in 2006, and is CTO of security consultancy Cigital and a prime mover in the Building Security in Maturity Model. BSIMM assesses software security practices of leading global companies; its most recent reports cover about 70 firms with large-scale software security initiatives.
We recently posted a short discussion with McGraw about what IT leaders should expect their developers to know about security. Here, ahead of his keynote presentation at HP Protect 2013 (Sept. 16–19), Discover Performance asked McGraw to identify the top three best practices to secure your software, why it is that well-known security best practices still haven’t been fully adopted, and what to do about it.
Q: Is the typical large enterprise taking the proper steps to build secure software today?
Gary McGraw: Some are, and others aren’t. It often depends on the vertical industry. Among financial services firms, I’m aware of about 25 multinational banks with global reach that have large and very successful software security initiatives. There has also been quite a bit of progress among independent software vendors. Particularly noteworthy is Microsoft’s Trustworthy Computing Initiative, which culminates in Microsoft’s Secure Development Lifecycle (SDL).
So, in those two verticals, there are firms that not only know what to do, but they’ve been doing it successfully for years, and they continue to do so. But other verticals—like healthcare, retail, and hospitality and gaming—are not doing as much yet. Software security—the idea of building security in—is beginning to catch on, but it’s not as widespread as it needs to be.
Q: The idea that software needs to be built secure from the beginning, not tacked on at the end, is a pretty rational train of thought—maybe even obvious. Why are we still talking about this after so many years?
GM: Because we don’t have to just talk about it, we actually have to do it! I estimate there are probably about eight million active developers in the world. Even though they’re professionals, not all of those people know a lot about security or even think about security when they’re building systems.
We’ve built a lot of software for many years where we didn’t think about security. That means we have to go back and fix that software. Plus there’s lots of software that’s being created today. Only parts of that new software pile are being built properly.
That’s why I say that though we’re making good progress, we really need more adoption by a larger number of developers and a larger number of firms.
The good news is that computer security really is a very hot topic. Everybody realizes that we need to think about security! Developers are coming to realize that they have a key role in making our future systems secure. To put this in perspective, in 2001, I’d say we had just a handful of developers doing software security. In 2012, I know of at least 250,000 developers that are being directly influenced in software security by the work of BSIMM. Those are great strides, going from zero to 250,000, but we have to go from 250,000 to even more than that if we're going to have enough influence to change the way software is built worldwide!
Q: What are the best practices being used by those 250,000 developers who are building secure software and being measured by the BSIMM?
GM: Instead of asking developers to change their favorite software methodology—for example, extreme programming, the SEI Capability Maturity Model, Agile, the Spiral model, or the Waterfall model—to something else, you say, “Hey, you should put some security best practices into your existing methodology.”
In my book Software Security, I list seven software security best practices that I call “touchpoints.” The top three touchpoints are: Number 1, static analysis with a tool—that is, look at your code for security bugs. Number 2, architectural risk analysis—take a look at the design of your software and its architecture to find and eradicate flaws. And number 3, penetration testing—check your work at the end of the lifecycle.
People and firms are beginning to adopt these practices worldwide. They’re the three software security touchpoints that everybody should be doing.
Q: Are organizations still failing to do these things at all, or are they lacking the “secret sauce” that would make these practices successful?
GM: Sadly, many organizations are not doing those simple things. The global reach of HP can certainly help. When HP bought Fortify Software, they made a great technology for software security available through a global worldwide channel. There are many firms that can now get secure code review technology from HP that may never even have heard of Fortify. That’s a good development.
What we’re seeing is the adoption of the software security touchpoints, not only among firms that need to use the tool directly, but also among technology providers like HP. Cigital, which has about 275 people doing security all day, every day, helps other firms to get started in software security and then mature their initiatives as they proceed. We work to put secure code review tools in place every day.
Ultimately, we’ve made some progress, but we haven’t made enough progress. We all know what we’re supposed to do. Now we all need to do it.
Q: You listed three of the seven touchpoints in a specific order. Does the order matter?
GM: It does actually matter what order you adopt things in. Almost every single software organization inside a firm is going to be producing one software artifact in their SDLC for sure—code. Since everybody has code, they can use something like a static analysis tool to look for bugs in that code and eradicate them. That makes secure code review a very natural way to start adopting this notion of proactive software security.
However, there are two kinds of defects that lead to security problems: bugs, which are problems found on a particular line of code, and flaws, which are design problems. Here’s a simple example of a flaw: “forgot to authenticate user.” You can’t find that problem in the code because it’s an error of omission. It’s not in the code! And there are many, many flaws like this. In fact, if you divide up the world of security defects into percentages, bugs and flaws divide things up about 50/50.
Ultimately, we need people to develop technology to look for bugs in source code, using things like HP’s Fortify tool, and we also need people to spend some time thinking about how to eradicate design flaws in their code as well. Sometimes finding design flaws takes a little more expertise, and there’s no tool solution to that problem. So if we’re going to attack the entire problem, we need not only tools, but smart, experienced people. We need not only technology, but lots of knowledge to approach the entire problem.
Q: So static analysis helps us look for bugs, and then the architectural risk analysis is about making sure that flaws don't get introduced into the design. What about penetration testing?
GM: Penetration testing is kind of a sanity check at the end of the lifecycle. It’s not a very good best practice to start with, because, economically speaking, when you find problems at the end of the lifecycle, it’s very expensive to fix them. Just know that if you hire penetration testers and they break your stuff, if you don’t fix it, you haven’t done anything to improve security!
Q: What else must security executives do to build secure software from the outset?
GM: It’s good to remember that you’re not alone. There are many professionals that have been doing software security for many years. You can and should take advantage of the lessons that they’ve learned in software security. One way to do that is to join a community of like-minded people who are measuring enterprise security and working together to make it as efficient and effective as possible.
Now that we have 70 firms involved in the BSIMM, we have a way of measuring and assessing your firm’s progress in software security. BSIMM community participants are senior executives who often have hundreds of people that report to them and have sizeable budgets running in the millions of dollars per year. Those people are very serious about software security, about their own software security initiatives, and about measurement.
As we mature the field of software security, it’s important that we start to adopt rational scientific methods. The BSIMM is a data-driven tool that you can use to figure out where you stand with your software security initiative, and help to determine strategy going forward.
Q: What have you learned from these firms about the biggest pain points of software today? What is the impact of major technology trends, such as mobile and cloud computing, on how they build secure software?
GM: Cloud computing and mobile trends actually have a big impact. You can think of mobile and cloud as the most important flavors of software development today. So people want to know: “These tools that we’ve been using for our source code review—do they work for mobile platforms like iOS or Android?” and “How do I get these tools and techniques that I’ve been using in my normal code base to work for cloud-based services? What does it mean when I have a massively distributed system?” In the BSIMM community, we talk about those things explicitly.
Software is evolving, and it’s important that software security evolves right along with it. Fortunately, among the BSIMM firms there are a lot of extremely good technologists that are doing software security. And of course at Cigital we keep an eye on what’s coming next. In addition to reacting as things evolve, we try to influence the people that are building the new software frameworks that everybody uses, like Spring and Struts. In that way, software security evolves even as software evolves.
Q: So tools and processes are being updated to accommodate the new challenges?
GM: That’s exactly right. And some of them are tricky. If you don’t own all the code, how can you check it? If you have a cloud-based solution, what do you do about all the vendors that are providing pieces of your modern solution? How do you make sure that they’re doing the right thing from a software security perspective?
These are all matters that everyone in the software security community and in the BSIMM community really care deeply about.
Watch Gary McGraw's keynote at HP Protect 2013, "Bug Parades, Zombies, and the BSIMM: A Decade of Software Security," and get more insight and intelligence from the premier security event at Backstage with HP Software.