"Software supply chain management is a national security issue," according to Joe Jarzombek. As the director for software assurance in the National Cyber Security Division of the U.S. Department of Homeland Security (DHS), he's in a position to know.
Speaking at the 2009 Open Web Application Security Project Conference in Washington, D.C., Jarzombek emphasized the need for the software industry to start building security into applications throughout the development lifecycle.
"We need to be collaboratively advancing strategies to mitigate software supply chain risk, not just patching software," said Jarzombek, adding that agencies need to get away from checkbox compliance to effective controls that reflect actual security.
"They are asking the right questions and want to solve the problem," said Web application security consultant and OWASP board member Dinis Cruz during the speech. "This vision is solid, but unless the visibility of an application's security profile increases, there is no incentive."
Improving compliance automation using SCAP
"Standards are the shared language that allows us to speak to Congress," said Jarzombek. "Tools alone aren't going to make it" as a measurement of security. In a conversation before his keynote, Jarzombek emphasized automated controls based on Security Content Automation Protocol (SCAP) as opposed to reliance on infrequent reporting required by the Federal Information Security Management Act.
He's not a strong supporter of new regulations. "What we can do is enforce the existing regulatory language that we have," he said, and focus on the desired end state: better cybersecurity achieved by raising expectations for product assurance.
The DHS is working to facilitate better standards, metrics and certification for application security. Standards include the Common Weakness Enumeration initiative, Common Attack Pattern Enumeration and Classification and Malware Attribute Enumeration and Characterization, said Jarzombek. He also shared two different websites for software developers to visit to find application security resources: Buildsecurityin.us-cert.gov and www.us-cert.gov/swa/.
Jarzombek said the agency is looking at ways that the buying power of both government consumer and cybersecurity purchasing can influence software security. "We truly do not know the behavior of the code that we have in our enterprise," he said, and suggested that there should be better sharing of penetration and vulnerability testing among agencies. Information on suppliers' business practices could be used to determine security risks posed by products and then shared with private industry.
Will stricter standards for acquisitions happen? "They could attempt to do that," said Brett Hardin, product manager at Qualys Inc. and co-author of Hacking: The Next Generation. "Look at PCI. If they'd come out on Day 1 and said that no one could accept credit cards online, no one would adopt it. You have to be strategic in the way you approach this. At the end of the day, it's up to the vendors."
Such measures are, however, already occurring elsewhere within the federal government: the Federal Aviation Agency just signed its first software assurance program last week. "That includes all new software and many existing applications," said Kimberly Baker, vice president of government markets at Veracode Inc. "It will be the first binary analysis of code at that level there."