Software Security Q&A = Jeff Williams  
 

In your consulting work with large enterprises, what do you find are the most common software security hurdles they are facing?
I’d say there are two. The first is buy-in for security improvement from upper management. Legislation and standards like Sarbanes-Oxley, VISA PCI, and the wave of disclosure laws have helped to build awareness about importance and create a more concrete path to failure consequences. The second challenge is more of a tactical culture shift among people actually involved in building the software. Most designers, developers, testers, etc. are very smart people who want to build great software that’s also secure, but many of them haven’t been exposed to security. One of the biggest challenges – and critical first steps – is building awareness of the consequences of failure and then empowering them to build higher assurance software through education and tools that make that process easier.

Can you point to any specific models you have seen where software security is an effective, integrated element of business operations?
Many organizations keep a tight lid on the specific methods they’re using to build the security of their software, but there are some models out there. Mike Howard and Steve Lipner have just released a book on Microsoft’s Security Development Lifecycle that lifts the veil on some of the process improvements they’ve made on security. Their SDL has been pretty effective in improving security quality but may be imposing to an organization that’s fighting for security budget. Still there are some great incremental takeaways there. Gary McGraw’s book, Software Security, also has some interesting information on security activities in the software development lifecycle. In working with large enterprises over the last few years, we’ve helped many take the first steps of security awareness which I believe is critical. Some organizations have rolled out training modules on software security, and as a result, they have been better able to leverage development environments, language features and source code scanners to produce code with fewer security related issues. For many of these companies, in-the-field metrics are only now starting to roll in, but the initial results show that organizations that have helped to empower their architects, developers and testers with security knowledge and tools are seeing marked improvements.

What do you consider to be the primary benefits companies gain when implementing automated source code review technologies?
Security needs to be a part of each stage of the software development life cycle, from requirements all the way down to deployment. That said, the largest volume of defects usually get introduced during development. Many organizations have tried to reduce this by establishing a secure coding baseline (such as a policy of which language constructs or libraries to use in specific situations) to reduce risk of common security mistakes and then enforce these guidelines using source code scanning tools. Source code scanning tools also help catch some of the low hanging fruit in code from a security perspective and can be pretty effective at highlighting potential issues before they turn into expensive vulnerabilities. They have the added effect of often changing developer behavior long-tem: when scanners draw attention to common developer security mistakes, developers start to think more broadly about how their applications might be abused and thus tend to write more attack resistant code.

Can you recommend any guidance or resources for companies that are just starting to establish software security initiatives within their development lifecycle or security programs?
Implementing a secure software development lifecycle doesn’t happen overnight. Moving toward a *more secure* development lifecycle can be done incrementally by adding a few process improvements. Start with the ones that are likely to give you the most bang for your buck. A critical first step is to educate management and stakeholders about security, its importance, and the consequences of installing vulnerable applications. Convincing managers that an investment in security is important usually involves looking at high-exposure breaches and hacks on similar applications or at other companies in similar industries. For any sustained effort, this management commitment is critical. The next step is to educate designers, developers, and testers about security. Training can be directed toward the influencers—the more senior developers, designers, and testers. Sensitizing them to security issues can be infectious in an organization and is likely to materially increase the security quality of the product. The process can be augmented with secure code reviews and scanning to weed out common developer security-related coding errors. This gradual addition of security into the process can have a drastic impact on post-release metrics, such as the number of security vulnerabilities found in the field. These results will reinforce the value of those process changes and encourage management to support further process enhancements.

Dr. Herbert Thompson is the Chief Security Strategist at Security Innovation, where he leads the company’s overall education and services strategy. Security Innovation is a world leading Application Security Services firm that provides risk analysis, risk mitigation and education services to global enterprises and technology vendors. The company helps organizations understand the security vulnerabilities in their software systems and facilitate the software and process change necessary to mitigate them. As the chair of the Application Security Industry Consortium, Inc. (AppSIC), Thompson also leads an association of industry technologists and leaders to help establish and define cross-industry application security guidance and metrics.

back to top

 
  Ounce Labs  |  100 Fifth Avenue  |  Waltham, MA 02451  |  www.ouncelabs.com  |  866-33-OUNCE