In recent blog posts we discussed the need for AppSec programs and which frameworks are available to build a program. At Checkmarx we view it as the utmost importance that our customers get the best value and the fastest Return on Investment (ROI) from our products. A well-designed AppSec program is critical to achieve this objective. As mentioned in earlier blog posts there are existing frameworks that help with developing and maturing AppSec programs. However, these frameworks have a few downsides:
High Entry Barriers in Terms of Time and Cost
1) Some of these frameworks have high entry barriers: The first step of adopting a framework is usually to perform an assessment. However, with some of the existing frameworks, an assessment contains so many questions which can be overwhelming for someone who just wants to get a high-level overview of the current situation and an indication where to get started and what to build on. It is difficult to see the need for going into a great level of depth with several days to up to a week of interviews before even getting started. With some frameworks the upfront cost of performing an assessment can also be prohibitive. I.e. just for learning the current state of your AppSec program you need to make a significant investment in time and money using such frameworks.
Large Number of Activities and Long Planning Horizon
2) Many activities and plan far ahead: Some of the existing frameworks such as SAMM and BSIMM also have too many activities to not lose sight of what is most important. Around 122 tasks in 12 practices (such as in the case of BSIMM) is a lot of detail to work through (see Theo Despoudis’s view on this here). Furthermore, these frameworks tend to plan very far ahead, typically building a detailed plan for 4 or 5 phases ahead with a planning horizon of between 1 and 2 years ahead. This seems to be outdated in times of DevOps and Agile where a planning horizon for specific actives are usually a few weeks rather than years.
Lacking diversity in perspectives
3) Only one perspective: Software Development Lifecycles (SDLCs) and therefore also AppSec programs usually include diverse stakeholder-roles who have different responsibilities and therefore perspectives on the process and outcome. As stated in a recent blog post by Vince Power, developers are often primarily focussed on meeting their objectives in implementing new features and security is often an afterthought because the first focus is on getting the required functionality in place. However, as an organization, software development is viewed from other perspectives as well: What risk is the application causing to our business or our customers if its data/information leaks or is modified or if the functionality is not available as expected, etc.? What does is cost to fix such issues? Depending on the type of software these risks can be substantial and exceed the benefit (e.g. in revenue) that is created by the application. Some existing frameworks focus mainly on one of these perspectives. SAMM and BSIMM for example are more focused on the management perspective. In contrast, the DevSecOps Maturity Model (DSOMM) is more focused on the developer perspective. You can see where this is going: It would be beneficial for a model to take different perspectives into consideration and take a balanced view of what’s important from such different viewpoints.
Taking a different approach: lightweight framework, fast assessments, and short planning cycles
Please don’t get me wrong, the above-mentioned models are not bad or wrong but sometimes they make it difficult to get started with something pragmatic, lightweight and something that is not objectionable from different stakeholders. Therefore we saw the need to take an improved approach and develop our own methodology that builds on the strengths of the existing models but eases their weaknesses and additionally incorporates our own thought leadership to take such frameworks and methodologies to the next level.
The result is the AppSec Program Methodology and Assessment (APMA) Framework which offers support to our customers on their journey to achieve their AppSec goals and sustained success. This methodology consists of three parts: A framework, A maturity model and implementation methods. We will describe these in more detail below.
For the framework we focused on keeping it lightweight and reduced the practices of other frameworks to 5 core dimensions (-> reduced number of activities). For the maturity model we focussed on keeping assessments short so that they only require less than one hour for a rapid assessment (not days or weeks -> lower entry barriers). For the implementation of a program, we focus on an agile planning cycles which means that we only give the recommendations that are reasonable to be implemented in the next sprint (-> shorter planning cycles) and then look at each next set of next steps sprint by sprint. For our assessments, and best practices and workshops we focus on the target role of the stakeholder to keep it motivating, interesting and relevant for them. we emphasize that the management and the development, and DevOps perspective are equally important (-> support different perspectives).
The framework consists of the following dimensions which are required for an efficient and effective AppSec program: (1) Strategy & Governance focuses on high level goals & objectives, policies and KPIs, and is usually the CISO’s responsibility. (2) Security Testing – Tactical focuses on processes of an AppSec program and is usually mainly in the responsibility of the head of AppSec. (3) Security Testing – Operational focuses on technology, i.e., the tools and how to use them (procedures and guidelines) and is mainly in the responsibility of the head of application development in conjunction with AppSec management. (4) Security Testing – Architecture & Scale focuses on the infrastructure required to perform security testing and is mainly the responsibility of the IT/infrastructure manager. (5) Lastly, the dimension Planning focuses on the breaking down the work into work packages, a timeline and to provision and/or train resources and is mainly the responsibility of project manager, program manager and delivery manager.
For all the major components we provide best practices advice. Best practices advice in general often falls short of providing clear guidance because it often only discusses potential best practices but leaves the reader to choose the right practice. We are taking a different approach here, where each of our best practice document is aimed at providing clear initial guidance so that you know how to get started. In future blog posts we will discuss the dimensions of the APMA methodology in more detail.
If you’re interested in performing an APMA assessment for you organization, please contact us on https://checkmarx.com/contact/.