How We Took Our Application Security Program From 0 to 60 in 12 Months

Recognizing the Need for Application Security

I am not an application security expert, but I knew the trends. Companies, like the financial services enterprise I work for, were being breached due to application vulnerabilities. My company had more than a dozen Internet-facing applications, and was moving toward creating mobile solutions for financial transactions. The more applications we added, the more our risk of a breach increased. Add in the fact that we were under tight scrutiny from federal and state regulators, clients and auditors, and it was clear that we needed to create an application security program.

Starting From Scratch

Yet, we had nothing in place – no application security procedures or controls, no documentation on how we currently did application security. Nothing. We were starting from scratch, and we needed to have an application security program yesterday. Like many companies, security was seen as a roadblock to productivity rather than a necessary part of the development processes. As a result, our software used to process millions of banking transactions was developed without clear application security guidelines in place. 

Conquering my Biggest Challenge

what was my biggest challenge? Getting buy-in from across the enterprise.

I knew my biggest challenge wasn’t going to be creating a program that would help reduce our risk. No, even though I wasn’t an expert on application security, I was confident I could learn what was necessary and find a partner to help me create a program. So what was my biggest challenge? Getting buy-in from across the enterprise. Because we’d never had a documented set of application security standards or practices, getting our development team on board was a challenge. There were two pitfalls we needed to avoid. The first was slowing down the business’s ability to move nimbly, and the second was creating policies that were strict enough but also reasonable enough that they wouldn’t be bypassed or ignored.

A lesson I’ve learned way too many times (I wish I’d learn it for real!) is that if you bring a problem to a group of smart people, they will happily help you create a solution, and implement it. If you bring a fully baked solution to them, you will have no end of resistance.

We talked about application security with development in terms of how it would be a “win” for their department, rather than about compliance needs. Looking at it from this angle allowed us to get to a place where, for the most part, we were able to agree on our goals.

One Step at a Time

When you are starting from scratch, you can’t expect to go from doing nothing to having an advanced program right away. Once I had stakeholders from different departments championing the cause, we collaborated in an effort to prioritize our efforts. We first ranked our applications in terms of business criticality and impact if breached. We gathered this information from as many business units as possible. We reached out to development, legal, infrastructure, finance, product management and many others. Using this input, along with information on how these teams operate, the security team made a list of controls, policies, and procedures we wanted to enact. This became our “to be” state, and gave us a goal to strive toward.

This was a long list, and we wanted to be realistic, so we created a plan for how we would implement the procedures in phases. At the same time, we shared information with our key stakeholders. This wasn’t just to win them over – it helped us set realistic goals and timeframes given the realities of our business.

Getting the Program off the Ground

Collaborating across teams rather than creating a plan in a silo meant we received less pushback when we began implementing the controls. Also, our roll-out plan dictated that we would implement one control at a time. This way we wouldn’t overwhelm teams with new procedures and rules, and the large-scale changes felt more manageable. Once we achieved the desired outcome with one control, we implemented the next.

We included secure code training as part of our plan, so that we weren’t simply testing code, we were helping our development team create more secure applications from the start. It didn’t matter if a team used Agile or waterfall or some other development methodology. If our relationship was strong, so was the result.

Conclusion

Within 12 months of beginning our application security journey, we were able to set goals, create a road map and get to where we wanted to be in terms of an application security program. The key was to start small, be realistic about our goals and make sure all the impacted teams had a voice in the processes. Now that the pilot is complete, our work is not done. We’ve continued to set new goals, and implement new controls so that application security is tightly integrated into the software development lifecycle.

Key Lessons Learned 

Recruit the smart guys

• Every team has a couple of key players
• Sit down with those people, and genuinely seek their help
• Let the others be swayed by their own leaders

Don’t tackle it all at once

• Triage!
• Focus on the highest risk first
• Work your way down the list until you’ve managed the risks appropriately

Find the right technical partners

• Secure code training
• Static application analysis
• Dynamic application analysis
• Think flexibility and scalability
• Slaughter a few (figurative!) sacred cows

Next Month: More details on our collaboration processes