According to Gartner, enterprises are getting better at defending traditional network perimeters, so attackers are now targeting the software supply chain. This has made third-party software – including commercial and outsourced applications, third-party frameworks and open source code -- the new perimeter for every enterprise. Last month, I had the privilege of moderating a session on exactly this subject in the FS-ISAC panel, “Improving software security through vendor transparency” with Reeny Sondhi, Director of Product Security Assurance at EMC Corporation; Steve Lipner, Partner Director of Software Security, in Trustworthy Computing Security at Microsoft Corporation; Jim Routh, CISO of Aetna and Chair of the FS-ISAC Product & Services Committee; and John Martin, Information Security Program Manager for Boeing. This panel session was inspired by the RSA Conference session, “Evaluating the Security of Purchased Software: Can We Find Common Ground?” where we had a lively discussion about the need for understanding of software developers' product development process and how consumers of this software should work with software suppliers to understand what security controls were taken into consideration during development. In this panel session, we took this concept a step further by inviting two purchasers of enterprise software, Aetna and Boeing, to participate in the discussion with software suppliers. Jim Routh, the CISO of Aetna, also chairs the FS-ISAC Working Group on Third-Party Software Security which produced the paper, “Appropriate Software Security Control Types for Third Party Service and Product Providers.” John Martin leads the Boeing program for COTS Assurance. We knew this panel session would be contentious beacuse large software suppliers are reticent to submit to ad-hoc security testing requests made of their products. But Jim Routh through the FS-ISAC whitepaper controls, and John Martin, Boeing, have both pushed for better understanding for the security of third-party software from their software suppliers. This includes the use of static binary analysis for testing of third-party applications.
“If you want to understand the security of acquired software, you can’t just go home when they don’t have a [secure development] process. A binary static scan is probably your best bet.” ~Steve Lipner, Microsoft
However, what resulted was a good solid discussion, with both software suppliers acknowledging the need for binary static analysis for less mature software suppliers: i.e. those software suppliers that do not have the resources to set up their own secure development process that could be in compliance with ISO 27034-1. As Steve Lipner put it, “If you want to understand the security of acquired software, you can’t just go home when they don’t have a [secure development] process. A binary static scan is probably your best bet.” I recognize that binary static analysis is not the only method available for validating the security of software products. However, we are attempting to create a partnership with software producers to improve software security and thus protect private data. This is not an adversarial relationship, we all want to have secure software, we all want to protect our customers data and we all want to do this as easily as possible. When addressing software suppliers with less mature programs, binary static analysis is the ideal place to start. It helps build a secure development program and is a great way to offer Intellectual Property protection, while still providing the security attestation that consumers of software need to see in order to manage risk.