Security by design? Don’t create a YAPWAV!

Security is about making risks visible and mitigating the impact of possible incidents to an acceptable level. The ‘security by design’ philosophy aims for every application or system to be at an acceptable risk level, all the time.

When starting with a ‘secure by design’ approach, often existing security processes are simply bolted onto the development life-cycle. One of the major pitfalls of this approach is requiring teams to do a YAPWAV. YAPWAV stand for the developer’s hell called: Yet Another Process Without Added Value. A YAPWAV is an activity a team solely has to do to please a stakeholder, without noticeably improving the product they’re building.

A classic example of a YAPWAV is the mandatory risk assessment for each software deployment, just for the purpose of satisfying a documentation process. These kinds of security processes are bound to fail as they add no (visible) value to the product the team is building. In the agile philosophy, every action or activity should contribute to the value of the product. The moment an activity is introduced that doesn’t add visible value, teams will decide it’s not worth the effort and stop doing it.

Your assumptions are wrong; the end is no longer neigh

Traditionally, security processes are designed from a structured, controllable viewpoint. Software development has a start and an end, and you can plot activities on that planning. At the start of a project risk and impact assessments are carried out, and close to the release date a security test is performed and approvals are collected. This approach might not be optimal but is often sufficient in a world that is mostly static.

The introduction of Agile and DevOps changed software development into a continuous process. Even when teams use mechanisms as sprints with a beginning and end, changes in software are introduced at a continuous pace. This continuous flow of change breaks many security checks.

The assumption of discretely timed phases with beginnings and endings is no longer valid. Imposing phase dependent checks on every change results in an inefficient process that puts a high burden on your organization.

At first this approach will start to consume a lot of sprint resources from development teams. Next, the number of requests for approvals and waivers will overflow your risk and compliance departments. Basically, it’s trying to plot a system of ‘checking everyone at the gate of your castle’ onto a modern city. It simply won’t scale and will only cause a lot of frustration without adding value.

Create a map towards security by design

Agile software development starts with raw ideas and continuously refines and clarifies them until the work that needs to be done is clear. The key to success for continuous security is converting phase depending checks into a continuous flow of activities and plot them on this agile way of working.

Microsoft already created the basis for this in their ‘Agile Development Using Microsoft Security Development Lifecycle‘ approach. In this approach, they differentiate activities that are required every sprint, and activities that are only required at certain times or circumstances. This approach is a good starting point, but there’s more to it.

Integrating security processes into agile development will only be successful if you can integrate it with existing activities. Many security activities have a comparable functional counterpart; security testing is just a form of testing, threat modeling is a form of designing, security requirements are a form of business requirements, etc, etc.

In the table below I mapped a couple of security activities to common activities in Agile and Devops. As always; these are just guidelines, so feel free to adjust to your own way of working.

Agile activity Compatible security activity Epic refinement Business continuity/impact analysis, high level privacy impact assessment Backlog refinement low level privacy assessment, high level threat model Pre Mortem Threat Modeling, Privacy Impact Assessment Sprint refinement Low level threat model Sprint Security scanning/testing, code reviewing Definition of Done Risk Assessment Sprint retrospective Risk Analysis on identified issues Post Mortem Root cause analysis for incidents

Be Effective

By merging security YAPWAVs into existing processes you will introduce  minimal overhead and improving the overall quality and value of your system. These integrated processes will have a higher likelihood of adoption as they are no longer processes executed for the sake of a single stakeholder. Security has become ‘just another quality attribute’ which is a foundation under the ‘secure by design’ philosophy.