The following post was co-authored with Steve Lipner from Microsoft and originally posted on the SAFECode blog.
Customers frequently ask all software developers – including SAFECode members – how they can be confident in the security of the software they acquire. We are well aware that acquired software can introduce new vulnerabilities into IT environments and that risk managers need a method for assessing the security of the IT products they procure and the impact those products may have on the organization’s risk posture.
Experience has taught us that software security comes from the developer’s adoption of a secure development process. We talked about this at length in our December 2012 blog post.
We know that the maturity of secure development practices varies among technology providers. And our experience has taught us that methods for assessing the security of software developed by less mature organizations can be counterproductive when applied to assess the security of software developed by organizations with mature secure software development methodologies. Those methods often generate “false positives” and are unable to detect software design flaws that can create severe exposure for users. They distract the developer from attention to real security issues and secure development tasks and create a risk that IT suppliers may “develop to pass the test” rather than applying the most effective software security methods.
As we’ve thought about the challenge faced by customers who want to gain confidence in the security of acquired software, we’ve concluded that there are three approaches for assessing the security of acquired software. The appropriate application of those approaches depends on the maturity of the technology provider developing the software.
The first approach is best suited for software built by organizations with little secure development expertise. It involves using testing tools such as binary analysis or other product testing techniques to detect security flaws in product code. This approach can be effective as a way of detecting simple security flaws and can provide a customer with a limited degree of confidence in a product’s security. But because the tools have little or no understanding of the software they are scanning, they will not be able to detect security design flaws. In addition, the lack of tuning to a developer’s code base may result in a false sense of security, extra work for the developer and tester or both. The narrow scope of this approach combined with the potential wasted effort required on the part of the developer can make this approach suboptimal when applied to software developed by organizations that have a secure software development process.
The second approach reflects the principle that secure software comes from the application of a secure development process and focuses on security artifacts from the product and the organization developing it in order to assess their maturity. Examples of such artifacts include:
- Public documentation on the developer’s secure software development process.
- Public documentation of the developer’s vulnerability response process.
- Guides to secure configuration and operation of the product, including steps for minimizing product attack surface.
By reviewing such documentation and guides, the customer can gain confidence that the developer has made a public commitment to secure development and has considered risks and mitigations appropriate to the technology and market being addressed.
The final approach consists of relying on developer conformance to emerging international standards such as the ISO/IEC 27034 series and IEC/ISA-62443. Developer conformance to these standards indicates a more formal commitment to secure development and a well-structured management approach to integrating security into the software development lifecycle. These standards are relatively new and their adoption is still low. However they represent the appropriate long-term approach by which developers will assure customers of their commitment to secure development and the effectiveness of their secure development process.
