Addition, Adaptation or Abandonment

At the core of introducing security to an environment is change. Change is an interesting and sometimes scary thing, especially if you are meddling is someone else's workflow or domain. 

So how do you handle this change when what you are proposing involves the developer’s workflows?

In short, you have to make very conscious decisions about what you add, what you adapt and what you abandon.

Addition

Bringing security practices into an existing development team is challenging. Agile development workflows are very structured and have very little slack space built in. The Sprint velocity may have been finely tuned over a number of iterations and adding new items to the Sprint is an exercise in balance, compromise and communication.

The most important consideration when adding to a lifecycle is the cost and frequency of the activity.  Costs need to be measured in both terms of activity completion and the additional costs levied as a result of delaying or providing less resource to other functions.

Additional activities need to be roughly scored before they are proposed to the team. This score may mean that the number of stories loaded into Sprints may need to be reduced to compensate. Trust me when I say that this will be a challenging conversation to have.

Copyright - Scott Adams (http://www.dilbert.com/)

Scoring needs to be carried out in conjunction between security specialists and development leaders. It needs to factor in the ramp up or education period for the new practice as well as whether the change will impact on story development. Blocks introduced to processes need to be found early and addressed.

Examples of activities that are likely to be added to workflows include outsourced security services such as penetration testing and security vulnerability management. These include processes for triage, prioritisation and scheduling remediation of vulnerabilities as they are identified. 

Often, these tasks do not naturally exist in standard development workflows or require integration with other groups, teams or individuals outside the development areas themselves.

Adaptation

The cost of adding items to workflows is quite clear. If something additional goes in, something has to give in return. Basic 'physics says no' rules apply here.

Is it better therefore to adapt existing rituals, artifacts or workflows to include security focus points?

Godzilla vs. The Coffee Shop

Imagine you went to the same coffee shop every day and ordered the same drink. Bob the coffee guy writes your name on your cup, puts it on the queue of other drinks being made and eventually a lovely hot caffeinated beverage appears on the end of the counter. Bob calls your name and off you go. Job Done!

What if the coffee shop was suffering from a case of sticky fingered clients? Drinks are going missing and Bob is getting into trouble. Something must be done.

Security to the rescue

A simple sounding adaptation to this process would be to change the final delivery stage. In our new process, the name is called and the customer must provide their receipt to collect their drink.

Do we now have a secure warm drink filled utopia? I don’t think so.

The customers are feeling inconvenienced and are proving to be quite bad at remembering to keep their receipt at hand. Bob is slowed down by the additional checks and hot drinks are queuing up on the exit counter and rapidly going cold. Furthermore, nobody feels empowered or trusted.

The process was adapted for security but in making a change like this was security chaos theory in action. One tiny butterfly-wing-beat of an action and Godzilla destroys a perfectly good coffee shop.

Objective focused adaptation

Simply put, if security start tweaking and adapting processes without fully analysing and understanding the situation then small security gains will come at a massive cost to the organisation.

If you need to adapt an existing process, work with the process owners to figure out how best to do that. Keep your adaptations focused on objectives not activities.  Nobody knows the current process and its constraints as well as the people living it every day. Don’t assume you know better than they do, communicate your needs and support them in helping you meet them.

Keep it simple when it comes to adaptation

Sometimes the simplest adaptations can have the greatest return.

For example, tagging or labeling all tickets that come through your work tracking system (i.e. JIRA or equivalent) with the word ‘security’ allows any developer or technical team member to quickly identify and flag security related stories. This simple label is the enabler for custom dashboards and work flows. It can be used to trigger additional code reviews or make anticipating security consultant support requirements easier.  Best of all, anyone can do it. No special skills or tools required.

When adaptations go bad

You've adapted a process. Your confidence is high. The only possible outcome is improvement right?

Making the change is the simple part, then it's up to you and the teams to monitor the process closely to see if it’s working. Continuous improvement (or learning from your mistakes) is a core of agile security as much as it is agile software development.

Simple things like choosing the wrong name for a process, ritual or artifact can cause confusion and inefficiency. Be prepared to react if your dream plan goes horribly wrong and react quickly.  Process change and adaptation takes time and is often done is increments. If you are changing a ritual or process that has been in place for months or even years – you will need to provide education and support to manage the transition.

Abandonment

So there was no good way to add to the workflow or adapt an existing process, is that the end of the story? Is the situation impossible?

Sometimes as security people the tools and processes that we are used to are just not made for your circumstances. They may be cumbersome or costly. Perhaps they need dedicated specialist resources or dedicated maintenance and monitoring.

So why don’t you abandon them altogether?

Focus on what really matters

Security is an evolving profession. 

The tools, techniques and methodologies we have are the product of years of work by organisations and individuals with a wide range of constraints and operating environments. While they are tried and true for a lot of circumstances, that may not always work for your organisation at this time.

Instead of focusing on your inability to integrate a certain activity or practice with your development lifecycle, focus on what those activities were trying to achieve and what risk they were protecting you from.  Once you have your objective in mind, invent something new.

Experiment, Assess, Adjust

Once you start focusing on what you what from your security practices in term of objectives - design processes and controls that suit your situation. Try them and then assess the situation. Did you meet your objectives? Did your risk level reduce? If you aren't where you want to be – adjust and try again.

Nobody knows your organisations security risk better than the people in it. Security specialists are here to support and empower all technical disciplines to build their own secure development environments and workflows. We want to make you better, faster, stronger and more secure - one change at a time.