This is the second part in my blog series about ‘being an agile security officer’. In this blog I will focus on the mindset of security stakeholdership in Agile and DevOps environments.
In the Agile world the Product Owner is the person who translates business and customer desires into work items (user stories) for the teams. The actual desires and requirements however are provided by stakeholders. Stakeholders are usually representatives of the business and end-users; in the new world security officers should start taking up the role of security stakeholders. The Product Owner usually has multiple stakeholders to take into consideration. As a security stakeholder you have to ‘compete’ with other stakeholders for the most valuable changes. It has become, more than ever, important to be able to translate your requirements into actual value.
You deal in dissatisfiers; deal with it!
The first thing you need to realize as a security stakeholder is the type of changes you bring to the table. In the KANO model the different types of changes are categorized in 3 main groups :
- Delighters: these are the cool, hip things users didn’t even realize they wanted, but cannot miss once introduced
- Satisfiers: these are the more traditional changes that gradually improve the product
- Basic expectations (or dissatisfiers): the things that nobody cares about until they’re absent
Unfortunately, as a security stakeholder you probably will not have a lot of delighters to bring to the table. In fact, most of your requests will not even be satisfiers. The line you are walking on are mostly the dissatisfiers; the stuff that nobody cares about unless it’s not there. On the positive side; these are mostly also the requirements on which there is little discussion about the importance. Understanding the type of changes you are requesting is important when creating and assessing user stories. This will be described in more detail in the next blog. For now the most important thing to remember is that value is defined differently for the 3 types of changes and a good Product Owner acknowledges that.
As mentioned earlier, Product Owners have a lot of stakeholders to take into account. Purely from a practical perspective it is impossible to please them all in the same way. Product Owners therefor use a technique called stakeholder mapping or stakeholder analysis to identify how much effort they have to put in each stakeholder . Stakeholder mapping is basically plotting stakeholders on the power (to influence) vs interest (in the product) axis. The outcome of this analysis helps product owners in managing all stakeholders. An example of this mapping and the corresponding effort is shown in below figure.
Luckily security officers are usually already in the upper half of this map. (If this is not the case, you really need to start working on awareness first!). To become a successful agile security officer it is paramount to get in the upper right quadrant.
As with every improvement approach the most important step is a change of mindset. For security officers this means that they must switch from a reactive approach towards a proactive approach. I will go deeper in the dirty details in my future blog posts, but a nice overview is given in the ‘DevSecOps Manifesto’:
As with the Agile Manifesto this list should be correctly interpreted. Although the items on the right-hand side are sometimes necessary or easier, the items on the left will ultimately yield towards a better solution. To be successful as a security stakeholder the items on the left-hand side should therefor always be the goal to pursue. The only way to achieve this is to start cooperating with the product owners and their teams. Work with them, understand the challenges they are facing and decisions they must make, and help them in every way you can to achieve their goals.
Minimize the work
As with every optimizing strategy, minimizing work is the highest goal. The less time you need to spend on something, the more you can do and the higher your efficiency becomes. From a security (or privacy, compliancy, or any other risk perspective) this means minimizing the impact of policies and requirements. Security officers usually have to deal with multiple policies that each need their own proof in some way. However, in reality many of those items do not need to be proven for each and every change. An important step into cooperating with the teams is to identify which items need to be proven under what circumstances. Microsoft already did a lot of groundwork for this in their agile security approach .
In short it boils down to splitting policies into 3 buckets:
- Requirements that need to be proven once (or e.g. annually)
- Requirements that need to be proven frequently, but independent of actual deployments
- Requirements that need to be proven with each deployment
With this approach you minimize the workload on teams, which ultimately results in more changes being possible. The next step will be do determine the most efficient way into getting the proof. Again, minimizing the time needed to do so is key. As a security officer you should contribute by integrating policies in the build pipeline and automating proof collection.
Become a member of the team!
Becoming a successful security stakeholder will be a journey, much like that of a product owner. Chris Lukassen also posted quite a few blogs about what to expect on the road ahead; I really recommend to read them until I post my next blog. His blog on how to implement the ISO27001 standard into the agile way of working is a very nice example .
As a final note for this blog this image that shows how not to start this journey 🙂
All parts in this blog series
Part 1: Being an Agile Security Officer
Part 2: The Security Stakeholder Mindset
Part 3: Pwn the Process
Part 4: User Stories
Part 5: Spread your knowledge