After winning the attention, and hopefully the backing of executives, as we covered in The Challenge of Starting an Application Security Program, it becomes much more straightforward to win the funding needed for the right tools, services, and training needed for secure application development.
Now comes the heavy lifting: actually putting a secure software development program in place.
“I hear lots of questions about how to go about rolling out an application security program,” says Chris Wysopal, founder and CTO of Veracode. “It’s not as straightforward as many think. Some experts say that all they need to do its get their security and development teams communicating. That doesn’t always go well.”
What causes many application security programs to go sideways from the beginning? Experts say security managers often, and inadvertently, end up creating an adversarial environment from the beginning. This is generally caused by security teams listing tons of new requirements for development teams – without properly aligning these requirements with business objectives or allowing for more development time for additional code checks.
“Coming in with a bunch of demands, essentially sticking your thumb in the eyes of the developer, is not going to make them your friend,” says Pete Lindstrom, research director at Spire Security. “The outcome will be that they don’t respect your interests or what you are trying to accomplish.”
“This speaks straight to the psychology of the developer,” says Wysopal. “You don’t want to call the baby ugly because it just starts off the conversation on the wrong foot.”
What most experts advise is making the subtle shift from software security to software quality by making secure development part of the Quality Assurance (QA) process. “When you bring the QA team in as the middlemen, they see both sides of the equation. They understand testing and they understand dealing with developers. So you get better traction with your initiative,” Wysopal says. “A lot of your success depends on getting buy-in from the development teams. Working with QA is something we’ve found that works.”
Caleb Sima, CEO at Web application security firm Armorize, agrees. “That can take us back to executive sponsorship, and the ability to ensure that security objectives are established as another quality issue,” Sima says. “It can be as simple as making a list of defects that can’t be in an applications, and have QA enforce a requirement that software doesn’t ship with those defects.”
Also, experts say, to build a sustainable application security program requires that developers be equipped with the proper tools, which could include application security assessment and QA tools, and additional resources. “Expect developers to acknowledge that they’d shoot to achieve the new requirements, but they’re likely to ask for more time and resources because you just changed the requirements on them. And they may need additional time to build to those new requirements,” Wysopal says.
Sima adds that beyond establishing new development standards, training is likely to be necessary at most companies. “The successful program will include training at multiple levels of the organization about effective application security. You want your developers armed with the latest knowledge on how to code secure software, and how attackers exploit weaknesses. This awareness building shouldn’t end with your developers. It needs to include your quality and assurance testing teams. They also need to know how to properly identify potential security defects,” Sima says.
IT management should also be trained on the importance of application security, and how to operate an effective operation, Sima adds.
Also, the successful launch of the program depends on putting measurable objectives in place from the start. For example, partners may require – for shared applications – that they don’t ship with security defects associated with the OWASP Top 10. Also, if there are applications that support the storage, transmission, and processing of credit cards they can’t have OWASP Top 10 vulnerabilities either. These become compliance requirements, which makes it straightforward to make them baseline requirements for all applications over time.
“That feeds well into the reasoning that security is just another requirement and not meeting security objectives is a defect. That is really one of the most effective ways to get development teams to handle secure development,” Wysopal says.
