Agile Transformation | DevOps | DevSecOps | Security
Being An Agile Security Officer: Security Stakeholdership mindset 
Dave van Stein 27 Dec, 2016
Share 
This is my fifth and last part of my blog series about Being an Agile Officer
In the previous parts I showed how Security Officers can align with the Agile process and let security become a standard considered quality attribute again. Unfortunately many teams not only need to be made aware of security requirements, but also need technical advise and guidance in designing and implementing them. As an Agile Security Officer you therefor need not only to act as a Stakeholder, but also as a Domain Expert for Security.
Be the Security Expert
As a Security Experts you should provide active guidance and assistance inside teams. As the Security Expert you actively help implementing security controls and mechanisms. Depending on your skills and that of the agile teams this can consist of creating the actual code, advise on encryption protocols to use, review configurations, execute tests, review cloud solutions, perform risk and privacy assessments, or implement tooling. 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 and Product Owner. Especially in organizations where few security specialists are presents, this means you sometimes have to act in both roles. However, it is important to separate these two activities in order not to frustrate the process [1].
Be there for the teams
As a Security Expert you should be easily accessible to teams, so make sure you are nearby where you’re needed. Make sure people know where you are located, show yourself at stand-ups and be part of retrospectives of sprints with security features. If physical presence is difficult, at least make sure that there is a way for quick remote interaction. Be present on communication channels like slack or mattermost. If these are not being used, at least have a dedicated mailbox for security questions that you give priority over everything else.
Security Automation
As a Security Expert you should also focus on continuously reducing the effort it takes to implement security requirements. You should evaluate safe mechanisms or libraries for programming languages that are being used, make security checks part of that automated build process, and automate the collection of evidence needed to proof the presence and effectiveness of implemented controls. Especially in DevOps environments the ultimate goal should be a security enabled build pipeline that automatically scans for security related problems. These pipelines should warn about license violations, known vulnerabilities in used software components, and vulnerabilities in the deployed application. Fortunately many tools have already been developed, are continuously improved, and can be combined with most of the popular build automation tools [2].
Be the Security Evangelist
Depending on your workload as a security expert, another interesting role for agile security officers is the security evangelist. The evangelist not only acts as a domain expert across all teams, but also actively coaches teams to become more security aware. One way to do this is to form a special interest or focus group, or a guild like in the Spotify model [3]. This group should act as an “organic and wide-reaching community of interest that want to share knowledge, tools, code, and practices.” The security guild’s mission is to spread knowledge about best-practices, regulations, tooling, intelligence, discuss security and privacy related topics, and increase awareness and skills across the teams.
Security Champions
The ultimate goal should be to identify so-called security champions. Security champions are agile team members that have shown a good understanding for a specific area of security. They can act as the security voice for a specific product, team, or technology. Examples would be mobile security, security testing, front-end frameworks security, etc. These champions can represent and offload the security domain expert and do the initial triage to determine whether or not the Security Expert should be involved [4].
Summary
I started this blog series with stating that 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. In the last 5 blogs I showed that how the role of a Security Officer has to change in order to bridge this gap again. The key to success is to split the security officer function into more Agile minded roles with different responsibilities and duties;
- The Security Stakeholder; defining the what and what not
- The Security Expert; helping with the how
- The Evangelist; raising the bar
Only by making security part of and align with the agile way of working we can bridge this gap and eventually make security an enabler instead of a blocker.
Links
[1] https://www.disciplinedagiledelivery.com/roles-on-dad-teams/
[2] https://schd.ws/hosted_files/appseceurope2017/c1/Creating%20an%20AppSec%20Pipeline%20with%20Containers%20in%20a%20Week%20How%20We%20Failed%20and%20Succeeded%20.pdf
[3] https://www.full-stackagile.com/2016/02/14/team-organisation-squads-chapters-tribes-and-guilds/
[4] https://www.owasp.org/index.php/Security_Champions
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
Process hacker, compliance archeologist and anthropologist, ivory tower basher, DepSevOcs pragmatist, mapping enthousiast, complexity reducer, intention sketcher. LEGO® SERIOUS PLAY® Facilitator.