"Let's start at the very beginning. A very good place to start."
Maria's kind advice in The Sound of Music could have been written about the journey to build an effective application security program. That road is fraught with many hurdles and obstacles, and to an organization that hasn't been focusing on security, it might even appear as too distant and too complex of a program to even start. Sometimes things seem so overwhelming that it's hard to get going.
Other organizations may be willing to take the first steps, and that is a good thing.
"Companies need to experiment, make mistakes and stick with what works for them," suggests Jim Manico, co-founder of Manicode Security, which specializes in education on secure coding practices.
During the recent OWASP AppSec Europe 2016 conference held in Rome, experts discussed the "where do I start?" topic with nearly 700 attendees from all over the globe. Here are tips drawn from those discussions and conversations.
First steps for creating an application security program
"From a management perspective, organizations can benefit greatly by looking at OWASP's SAMM (Software Assurance Maturity Model) framework," recommended Matteo Meucci, CEO at Minded Security. "SAMM leads an organization through an operational assessment -- a series of interviews of the management team involved in the secure software development lifecycle (SSDLC) -- designed to look at how they manage threat modeling, how they perform security testing, how they conduct secure code reviews, how they manage the bugs through to resolution and more."
The SAMM toolset produces a graphical representation of the organization's capability for embracing an application security program. Using this dashboard, the company can then build a roadmap to become an even more mature organization for their SSDLC.
"SAMM is a great way for organizations to understand where to invest and how to improve," added Meucci.
Companies need to experiment, make mistakes and stick with what works for them.
Jim ManicoManicode Security
Organizations often begin their application security program by focusing on the testing of the applications once the software has been designed and built. However, many at the AppSec Europe conference agreed that looking for security problems at that late stage alone is not enough.
"Some orgs start with Dynamic analysis -- dynamic application security testing (DAST) -- which is just before release," said Amit Ashbel, director of product marketing at application testing firm Checkmarx. "This sometimes causes a delay for the release, and developers have to go all the way back to fix the problem. Instead, you should analyze the code in static form as it is being written. Dynamic analysis at the end should be the final checkbox with little to no impact on the project because the bugs should have already been caught."
Static and dynamic testing for application security
Manico had a different perspective on this either-or position, noting that "any sensible application security program should involve both static and dynamic testing." A dependence on either one could leave things sitting short on both ends, he said. "You do not do 'this or that,' you do 'all of the above' in harmony with tools that track all this activity," Manico added.
Meucci agreed that the either-or approach is risky.
"These projects typically fail," Meucci said. "They fail not so much in that developers don't have the time to go back to fix the vulnerabilities they find, but because they find a ton of vulnerabilities and don't know how to fix them," he said.
"The issue is two-fold," said Tony Luzza, director of international channel sales at risk analysis firm Security Innovation. "One, the CISOs (Chief Information Security Officers) are getting the application penetration test results too late in the development lifecycle, and two, they are bringing the findings back to a team that doesn't understand security, nor possess the skills required to fix the vulnerabilities," he added.
For organizations that focus their efforts on post-development testing, many hold a false assumption that they can find the vulnerabilities, prioritize them and, after fixing the defects, ship the software in an 'OK' state. That's not a recipe for success, and defects will almost certainly slip through. Why? Software teams are under tremendous pressure to ship the product by a certain deadline. It's all about the effort -- and reopening the project and running through the whole testing and release process again can be a huge nightmare, especially if the security flaws are widespread and require changes to the software architecture.
The best advice, according to experts: Test early and test often. Use static application security testing (SAST) during the coding phases and use dynamic testing to catch flaws that might have slipped through.
"Companies forget that it's not about saving money with one type of testing versus the other," Ashbel said.
But that's just the beginning. There's much more to do in order to build an effective application security program.
"Yes, do your SAST and do your DAST, but these are just a few elements of a mature and secure SDLC," Manico said. "Also consider security standards and requirements, architecture risk analysis, design risk analysis, DevOps infrastructure, security frameworks and libraries for developers. Consider developer training, test planning, center of excellence availability, evaluating of security metrics, test evaluation and other aspects of a mature and secure SDLC."
Stay tuned for more expert insight in part two of this series on building an application security program.
Next Steps
Read more on how to identify and address cybersecurity blind spots
Find out why vulnerability testing is crucial for open source web applications
