Thoughts on an AppSec program – The Team
December 29th, 2009 | by wadew |
I’ve spent the past 3.5 years working on a team where my primary responsibilities involved “application security”. Now that this era has come to an end, I’d like to share some of the initiatives and define their successes and shortcomings. Since this promises to be a pretty long post, I’m going to break it up into more digestible bits containing an initiative or two.
Dedicated application security team
When I was first hired on to the team, it was responsible for both security assurance (application security) and incident response. One of the first milestones which lead to the success of the program was the separation of the team into 2 groups with distinctly different areas of responsibility: one team did security assurance, the other did incident response. I credit this move as a success because when the responsibilities were shared, engineers were required to share their focus between the proactive mindset of security assurance, and the reactive mindset of incident response. Inevitably, certain engineers were more skilled in one or the other of the disciplines and the quality of service across the different offerings would be degraded at times. While the teams now had a different and separate structures and managers, the importance of information sharing wasn’t lost as the teams were already so used to collaborating as a single team.
If your company is serious about application security and the workload justifies it, I would suggest that a dedicated application security team be created to provide the expertise needed to address the unique challenges of a complete application security problem space. The charter and team responsibilities must be carefully selected, if the mission is too narrow certain critical of the supporting components in application architectures might be out of scope, while a mission that is too broad will reduce the amount of time engineers will be able to dedicate to appsec will be limited. If I had to do it over again, I would certainly narrow the scope of the team to only include application security and associated disciplines (training, threat modeling, secure design and architecture consulting, security assessments, code reviews and analysis – SCA).

