ORLANDO – Initiating a secure software development program can be a sizable challenge for any enterprise information security team, but according to a software assurance expert, the best first step doesn’t involve taking stock of what developers are doing, but instead examining what they’ve already done.
Helping everyone elevate their skills without making it too personal is a measurement strategy that has worked for a long time in the software quality community.
Michele Moss, Booz Allen Hamilton
Speaking Monday at the (ISC)2 Security Congress, Booz Allen Hamilton Lead Associate Michele Moss told conference attendees enterprises must understand the scope of their software security challenges with existing applications before identifying the right ways to address current and future software development.
“With new technology today, like cloud technology, applications and databases are constantly moving from one server to another,” Moss said. “If you conduct a vulnerability scan or a secure code review of things that are in production, by the time developers get around to fixing them, those application servers and databases may be moving around again.” Worse yet, she added, the same flaws may appear repeatedly across an application infrastructure because developers aren’t correcting them.
Moss, who co-chairs the Software Assurance Working Group on Processes & Practices for the U.S. Department of Homeland Security, said the process of measuring an organization’s software security posture should start with a software assurance process reference model, such as the one used by DHS, and the use of a “yes/no” checklist to determine which secure software development best practices an organization currently follows. The DHS model then maps to a number of more detailed software assurance systems, such as BSIMM and the CERT Resilience Management Model, which security teams and developers can use to identify, prioritize and address vulnerabilities in existing production applications, as well as those still being built.
When it is time to address secure software development, Moss though warned against overwhelming developers with new processes. She said with the same static code analysis tools many developers commonly use, it’s possible to compile quantifiable data on the flaws being found, how many are being fixed, and whether the same types of flaws occur over and over.
It’s also important, Moss said, to demonstrate some “quick wins” early on in terms of identifying and correcting high-priority security flaws in important applications. That way, Moss said, key stakeholders understand the value of a software assurance program and can be more easily persuaded to make an ongoing financial commitment to sustaining it.
Moss also warned against measuring individuals because the goal of a secure software development initiative should be to decrease coding flaws that attackers can exploit, not raise an organization’s turnover rate among development staff.
“Working to increase the security of the code takes time,” Moss said. “There may be certain individuals who get it faster than others, and some for whom security isn’t necessarily their strong point, but helping everyone elevate their skills without making it too personal is a measurement strategy that has worked for a long time in the software quality community.”
As a way to encourage developers to want to accept responsibility for secure software development, Moss strongly encourages security teams to expose developers to the Rugged Software Manifesto, a grassroots campaign led by Joshua Corman, formerly of The451 Group and now director of security intelligence at Akamai Technologies. Rugged emphasizes the importance of software in the modern world and challenges developers to aggressively ensure their code is secure.
“The first time I saw this, I got chills,” Moss said of the manifesto. “It’s a great way to look at and scope the challenge.”
Attendee Brandon McCauslin, a software developer with Chantilly, Va.-based IT services firm Trusted Concepts Inc., said it’s important for developers to receive more training on secure software development, especially on how to avoid flaws that enable the most common attacks like cross-site scripting and buffer overflows.
“Most of my fellow developers think of security as just another function,” McCauslin said, adding that it’s a function that often loses out to functionality, usability and ultimately project due dates.