How to start building an enterprise application security program

“Let’s start at the very beginning. A very good starting point.”

Good advice from Maria in The sound of music could have been written about the journey to create an effective application security program. This road is strewn with pitfalls and obstacles, and for an organization that has not focused on security, it might even seem too distant and too complex a program to begin. Sometimes things seem so overwhelming that it’s hard to start.

Other organizations may be willing to take the first steps, and that’s 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 educating about secure coding practices.

At the recent OWASP AppSec Europe 2016 conference held in Rome, experts discussed the question “where to start?” topic with nearly 700 participants from all over the world. Here are tips from those discussions and conversations.

First steps to create an application security program

“From a management perspective, organizations can greatly benefit from reviewing OWASP’s Software Assurance Maturity Model (SAMM) framework,” recommended Matteo Meucci, CEO of Minded Security. “SAMM leads an organization through an operational assessment – a series of interviews with the management team involved in the Secure Software Development Life Cycle (SSDLC) – designed to examine how they handle threat modeling, how they perform security testing, how they conduct secure code reviews, how they drive bugs through to resolution, and more.”

The SAMM toolset produces a graphical representation of an organization’s ability to adopt an application security program. Using this dashboard, the business can then build a roadmap to becoming an even more mature organization for their SSDLC.

“SAMM is a great way for organizations to understand where to invest and how to improve,” Meucci added.

Businesses 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 application testing after the software has been designed and built. However, many AppSec Europe conference attendees agreed that looking for security issues at this late stage was not enough.

“Some organizations start with dynamic analysis — dynamic application security testing (DAST) — which is right before release,” said Amit Ashbel, director of product marketing at application testing company Checkmarx. “This sometimes causes the release to be delayed and the developers have to go back to fix the problem. Instead, you have to analyze the code in static form as it is written. Dynamic analysis at the end should be the last checkbox with little or no impact on the project as the bugs should have already been caught.”

Static and dynamic testing for application security

Manico had a different take on this alternative position, noting that “any sensible application security program should involve both static and dynamic testing”. A reliance on either could leave things hanging on both sides, he said. “You don’t do ‘this or that,’ you do ‘all of the above’ in harmony with tools that track all of that activity,” Manico added.

Meucci agreed that the either-or-be-risky approach.

“These projects usually fail,” Meucci said. “They fail not so much because the developers don’t have time to go back and fix the vulnerabilities they find, but because they find a ton of vulnerabilities and don’t know how to fix them,” a- he declared.

“The problem is twofold,” said Tony Luzza, director of international sales at risk analytics firm Security Innovation. “First, CISOs (Chief Information Security Officers) get application penetration test results too late in the development lifecycle, and second, they report the results to a team that doesn’t understand security, or own the skills needed to fix the vulnerabilities,” he added.

For organizations that focus their efforts on post-development testing, many mistakenly believe that they can find vulnerabilities, prioritize them, and, after fixing the defects, deliver the software in an “OK” state. It’s not a recipe for success, and flaws will almost certainly creep in. Why? Software teams are under tremendous pressure to ship the product within a certain time frame. It’s all about effort – and reopening the project and going through the whole testing and release process all over 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 detect flaws that might have passed.

“Companies forget that it’s not about saving money with one type of test over the other,” Ashbel said.

But this is only the beginning. Much more needs to be done to create an effective application security program.

“Yes, do your SAST and do your DAST, but those 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 training developers, test planning, availability of the center of excellence, evaluation of security metrics, evaluation of mature and secure SDLCs.

Stay tuned for more insights from the experts in part two of this series on building an application security program.