The Evolution of Software Security Assurance. Part 3
Table of Contents
Standards and Compliance
Most people who perform software security assurance do it for one of two reasons. First, they might be motivated by desire to manage their risk, this is really an internally facing motivation – our business faces certain risks, we might lose revenue or customers, we need to take security activities to avoid those risks that we think impact our business. This is a very common motivation.
The second motivation is a compliance, or standardization, motivation: I need to comply with someone else’s rules about the systems that I’m building, the kind of software that I operate. PCI DSS is an example of an external compliance standard that the big credit card companies have put down on software vendors that want to process credit card transactions.
Interestingly, risk management is a bad motivation for software security. For the most part, humans are bad at managing risks. We are not good at identifying all the risks that might be out there, and we tend to focus on our own risks rather than risks that affect all society or the collective. For this reason, we think compliance will be a more important driver for software security activities and will be more valuable to mature organizations trying to partake in software security activities than a pure risk management approach.
The question that is inevitably raised here, however, is: what do we need to comply with? Just as we can’t make restaurants deliver safe food by testing every burrito that’s sold at the Mission, we can’t ask software organizations to comply at the “line of code” level with every piece of software that they write, because verifying and holding them to those standards is simply too great a task.
In an attempt to provide a more useful bar, something that organizations really could strive to comply and measures themselves against, a group of researchers led by Gary McGraw and Brian Chess has embarked on a project called “The Building Security In Maturity Model (BSIMM)”; and another group led by OWASP, with Pravir Chandra, has started a project called “The Software Assurance Maturity Model (OpenSAMM)”. Rather than setting out to measure the artifacts that software organizations build, both of these projects set out to measure the process that they use to build those artifacts: so, how do they instill security in their software development lifecycle; how do they bring these different activities, like threat modeling, code review and penetration testing to bear on those systems?
Software Security Today
Based on these projects and Fortify’s experience with our customer base, we find that organizations move through a few levels of maturity when it comes to a software security assurance program, and in particular leveraging these key disciplines that I’ve talked about today. In the beginning, we find that security team works alone. They leverage some technology, maybe it’s static analysis, maybe it’s penetration testing, usually it’s one of those two – threat modeling comes in more mature organizations; but they leverage some technology to start to point out security problems. They look at a small set of programs, usually the most critical to the business, and they find very specific vulnerabilities that provide after-the-fact value to the business. They find a problem, they fix it in the next release – security has gotten better, but the progress is very incremental and very slow.
Software security assurance journey
At the next phase, we find security begins to engage the development organization. And here we get the real acceleration of scale, where we have a large development organization; even if they only do a little bit of security, they are able to do it in a lot of places and affect a lot of systems. So we see the bar for security raised across a larger number of applications and across the organization.
And then finally in the last phase we see development really taking ownership of security. Security is now a requirement of the systems, the software that they build, the same as performance, reliability and functionality always have been. In this case, we find the bar set quite high for security across all software that the organization develops. Security is able to step back and take a more forward-looking role, the role of maybe a general in a war, looking at how we are going to allocate resources, what technologies we need to be thinking about next year or 3-5 years down the road, what we can do to really enable the development team to get security right every time they are faced with one of those critical decisions.
In the end, what Fortify and Hewlett Packard have found is critical to getting software security right is a combination of people, process, and of course technology. I come from a tools perspective, so the technology is really exciting to me, but I’ve found that the people and process side of this – how we make it all work, who we get buying from, how we train and roll out technology to our people – is even more important to making an effective software security organization than the technology that underpins that. I think, looking forward, one of the most exciting areas in software security assurance is going to be the convergence of threat modeling, penetration testing and code review together to provide more meaningful results, better prioritization, and overall more secure software.
With that, thank you very much! I hope some of you get to hear the full version of this talk when I deliver it, and I look forward to seeing you at another RSA.
Also Read:
Posted in: News
Leave a Comment (0) ↓