Being An Agile Security Officer

Whenever I give a presentation, training, or just talk to security teams, it becomes clear that over the years a gap has been created between application security and development. A gap we created consciously and with intent and that became painfully visible with the introduction of Agile and DevOps. Suddenly exhaustive information security policies with checklists and penetration tests became serious impediments. The challenge we are facing now is how to bridge this gap again.
Fortunately this challenge is easier to solve as it appears to be. The key to success is to split the security officer function more Agile minded roles with different responsibilities and duties. In the coming blogs I will dive deeper into the different aspects of these roles and the differences in the responsibilities and duties. But first we need to take a little trip down to memory lane to understand how we ended up in this situation.

A little history

Information Security as a profession more or less started in 1985 when Stephen Katz became the first CISO (chief information security officer) at Citibank [1]. Security was given its own department in the company with its own C-level officer. At that time it seemed like a logical choice. Security was more or less defined by infrastructure and policies and had little to do with application development. That started to change mid-nineties with the rising of web applications, but we (as a security industry) failed, maybe even refused, to recognize it and kept security separate from development.

The Status Quo

With the increasing use of web applications, cloud solutions, and connected ‘things’, security nowadays is for the bigger part defined by development, but still the security aspects are usually the responsibility of another department with their own processes. Until a few years ago even this unnatural separation didn’t cause huge problems. Sure, security was the ‘department of NO’ and developers ‘never cared about security’, but with risk assessments at the beginning of a project and penetration tests at the end, the final result could become more or less secure. Most vulnerabilities that still ended up in production could be handled by incident response teams and the findings of the yearly audit were given a high priority and fixed before fines were issued. This was not an ideal situation, but it worked well enough for most companies.

The Winds of Change

This status quo started to tremble with the introduction of Agile and DevOps. Suddenly there was no ‘beginning of a project’ anymore and release cycles become so short that penetration tests became a serious impediment. Since development is directly linked to business value and therefor company turnover, security was more and more bypassed for the sake of time (and money). As the responsibility for security was taken away from development more than 2 decades ago, it is not surprising that most development frameworks and approaches don’t spend much time on the subject. Most of the time there is a small section mentioning security is important and you should align with the corporate policies and that’s it [2]. Even education doesn’t spend much time on the subject usually (although that is changing), so most developers are not even aware of the problems unless they do some research on their own, helped by organizations as OWASP [3]. The security specialists on the other hand are not trained in modern software development practices. They are still trained to use tollgates, checkpoints, and a world of fairly static situations to become, and remain, resilient.

Away with the Old

So after 30 years of trying to build secure software and systems we ended up with two worlds at war; one wanting to build with bricks, concrete, and steel and the other wanting to use Lego and Meccano. History showed that speed will always win over certainty. Even when you are wrong while being fast, you have more time (and therefor chances) to correct and in the end you will win. Assembly lines, workflow software, Lean, Agile, DevOps, and all other speed improving approaches won over the old ways and will remain to do so in the future. So the solution to the security vs development struggle is not in slowing down or adding more tollgates to development. Instead security has to start understanding how the new world works and find new ways to regain grip on the situation. In the Agile world there are a couple of roles that provide you the mechanisms for that.

The Security Stakeholder; defining the what and what not

In the Agile way of working the Product Owner is the person who translates business and customer desires into work items (user stories) for the teams [4]. The actual desires and requirements  however are provided by Stakeholders. As a Security Stakeholder you have to ‘compete’ with other stakeholders in prioritizing user stories, so it becomes important to be able to translate requirements into real business value.

The Security Expert; helping with the how

Security experts give active guidance and assistance inside teams. They actively help implementing security controls and mechanisms. As a Security Expert you should focus on implementing the user story in the right way and not discuss the user story itself, as that is the role of the Stakeholder.

The Evangelist; raising the bar

Depending on your workload as a security expert, a last interesting role for security officers in Agile worlds is that of the security evangelist. The evangelist acts as a domain expert across all teams and coaches teams to become more aware on best-practices, regulations, tooling, intelligence, discuss security and privacy related topics, and increase awareness and skills across the teams.

To be continued!

As mentioned at the beginning of this post, I will dive deeper into the different aspects of these roles and the differences in the responsibilities and duties in a coming series of blogs. In the mean time I can advise to read the blog of my colleague Chris to provide some more background on the role of a Product Owner and the growth path you can expect as a stakeholder (which in my opinion will be similar to that of a Product Owner) [5].
 

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
Links
[1] https://www.bankinfosecurity.com/influencers-steve-katz-a-2164
[2] https://en.wikipedia.org/wiki/Agile_software_development#Regulated_domains
[3] https://www.owasp.org/index.php/Main_Page
[4] https://xebia.com/blog/scrum-the-mythical-product-owner-role/
[5] https://xebia.com/blog/the-five-belts-of-the-product-owner/