In the grand scheme of an enterprise’s life, one year isn’t a long time. Especially when you are talking about designing, implementing, iterating and improving an application security program. But that is the amount of time one financial services company took to create and improve their application security program. Upon speaking with the project manager I was most struck by his pragmatism. When you are starting from scratch, you can’t expect to go from doing nothing to having an advanced program right away”, he told me. Here is his story, in his own words, of how he worked with teams across his organization, developed a program based on best practices and key metrics, and then expanded the program to reach his own application security goals.
For more information on why we publish anonymous case studies, read our post here.
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.
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.
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.
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.
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.
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.
Recruit the smart guys
Don’t tackle it all at once
Find the right technical partners
Next Month: More details on our collaboration processes