CMMI for Application Security — Four high-impact implementation considerations

Ponemon Institute and Security Innovation recently made public the results of a research study they did to get an idea of the state of application security across organizations.

Amongst other things, the study listed five simple CMMI levels for ASM (Application Security Maturity) which we felt are pretty apt. Development teams could do a quick reality-check to find out the level where they currently fit. Teams that are already operating at Level 5 (the highest) could vouch for the remainder of this post. Pat yourself on the back and sustain the momentum! Others, who are at lower levels currently and would like to know how to move up the ladder continuously, should incorporate all of the following aspects as an integral part of their application security programs:

  1. Ongoing security audits: Development teams that undergo security audits on a periodic basis find it easier to sustain at a minimum of Level 4. The study listed this explicitly as one of the three pillars of a secure SDLC program and we couldn’t agree more.
  2. Compliance accountability: Holding the development teams accountable for compliance esp. in regards to “regulatory requirements”. This is in addition to “secure architecture standards” and “secure coding standards”. This is an excellent recommendation in the study which we strongly concur with. More often than not, development teams treat regulatory/compliance requirements as mere checklist items and don’t understand the business impact of non-compliance.
  3. Dedicated security representative: Additionally,we recommend having a dedicated representative — internal (within their team) or external (central security team or external consultants). This ‘human form of external motivation’ (not simply security tools!) makes it easier to move up the levels over time. Would like to stress that this needs to continue till Level 5 is reached. If it’s stopped at Level 4, there is a tendency for the momentum to reduce as a result of which levels would drop to 3 or 2.
  4. Attrition: We also recommend taking attrition into account for your team’s internal security experts by grooming more than one person (in parallel) for the role. This will prevent single point of failure in case the designated expert leaves the team or the organization.In conclusion, ‘CMMI levels for ASM’ is indeed a practical way for organizations to get started and incrementally improve their application security programs but would be more effective/SMARTer if the considerations indicated above are taken into account.

About the Guest Blogger:


Vishal Asthana, CISSP has recently joined us as our Regional Director for India operations.

Prior to this, he was part of the central security team at Symantec which is responsible for building a culture of proactive application security across product teams’ end-to-end development lifecycle (SDLC). This was accomplished by use of a combination of quantitative and qualitative activities.

He is passionate about security aspects in Agile development environments and is the lead author for SAFECode’s paper Software Security Guidance for Agile practitioners released in July 2012. Before this, he presented Symantec’s work in the Agile Security area at Security Development Conference 2012 and SOURCE Barcelona 2010.

Vishal has 13+ years of rich technical and techno-management experience obtained in the US and India across diverse industries (Software/Hardware security product companies, reprographics, BPO). He holds a Master’s Degree in Electrical Engineering from the University of Southern California (USA) and a Bachelor’s Degree in Electronics and Telecommunication from the University of Chennai (India).

Previous Article
Can software security requirements yield a faster time to market?
Can software security requirements yield a faster time to market?

At the surface, the answer to this question is clearly no. Development teams that build more features and s...

Next Article
Why manual testing is worth the extra buck: weighing the pros and cons
Why manual testing is worth the extra buck: weighing the pros and cons

Clients often ask for our guidance on whether they need to do a manual penetration test for a specific appl...