As discussed in the previous article (in French), ISS teams must adapt their organisation, processes and tools to ensure that security issues are considered on an ongoing basis.
Agile methodologies are becoming more common within organisations and security teams must adapt to be part of the new operational model.
However, when security is scaled up from a few Agile projects supported to hundreds, the scarcity of security expertise becomes a major obstacle. The consequence? Security teams become overloaded and unable to support all the feature teams. Therefore, feature teams are required to resolve issues with new functionalities and release without a security review.
In order to to support this transformation, CISO teams must thoroughly review their operating model to be relevant and enable and effective security environment. What does this mean? They must review their organisation, processes and tools.
How can we enable this transition?
Define new ISS roles for a transition to a new operating model
The first step is to understand the different roles that security must play in the new operating model to support this move to scale:
- The Security Guild: in order to share knowledge between teams, it is important to build a community of people, who have an interest for security and help them build the best practices. This community of Security Champions, which is described in the following paragraph (and anyone who is interested in security subjects), also has to implement a common framework of references on the methodologies (Security KM, Evil User Stories, Security Baseline, Level 1 control, described in our previous article – in French –).
- The Security Champion: this is the security ambassador within the Feature Teams. He/she is fully part of the team and present in every sprint planning His/her role is to ensure that security is considered at every sprint during the development of User Stories. The Security Champion may be from the developing world and develop skills on security subjects, with help from the Security Guild and the Enabler Squad.
- The Enabler Squad: if we look into Spotify’s model, it is the engine of all Guilds. A group of people from the CISO team who will steer the Security Guild while building methods, processes, products, services and standards for development, which will help Security Champions gain autonomy. When starting the industrialization of the model, they can play the role of a Security Champion, before training them. They also provide security expertise on the most critical perimeters and support the less mature teams.
- The X-Team(“cross team”): If the Enabler Squad’s role is to assist the Feature Teams in the security integration, the X-Team’s is to control the security level and guarantee risk coverage. This team performs targeted technical tests (penetration tests, code review, etc). Obviously, performing a penetration test in every Feature Team and for every sprint is not possible as it is really time consuming. Therefore, tests could be done through sampling and/or randomly (thereby playing the “Chaos Monkey’s” role in the organisation[1]), by focussing on the most sensitive and less mature perimeters. As long as enough security KPIs are received from the Feature Teams, the X-Team can perform controls on all teams, especially those where the security maturity is drifting from the targeted level.
- CISO: his/her role evolves and is now a checkpoint and provides them with the ability to reject a particular change if the appropriate security controls are not in place (E.g. based on the X-Team findings or according to a “security score” at application or infrastructure level, scored by the ISS team). Given that they cannot be present during all Agile discussions, they must rely on the Security Guild to point out where a strategic decision must be taken. However, they could participate in PI planning and other infrequent discussions, to have an overview on all the ongoing projects and decide which one should be supported more closely. Dedicated committees can also be set up, allowing projects to sign up and have subjects arbitrated, with a call to the CISO if final arbitration is required.
As in every change project, the effectiveness of acculturation lies more in practice than in theory. It’s better to start small and initiate a progressive handling of the new operating model by the ISS team. It will then be easier to expand the perimeter to the whole company.
Mobilising security experts to start the transition in 2 or 3 Feature Teams
Integration of security must be carried out continuously. The goal of Feature Teams is to be mature and competent in cybersecurity and to have autonomy regarding risk management. But in the interim period, the presence of security experts in a position support support is crucial in order to ease the integration of security into projects, while Security Champions are embedded in every Feature Team. These security experts must prioritise projects (e.g. critical projects, Feature Teams facing difficulties…) as they will not have the capacity to support every project.
The objective is to start the transition, using security experts from the ISS team to “do” with the teams, learn by doing and use this knowledge to build the first bricks of the security methods required by the Agile team.
It is at that point that the first useful tools and methodologies must be built, used and upgraded:
- The Security Passport: it must be completed at every step of a project’s life (and beyond). It’s completed at the beginning of the project (at the same time as the PI Planning) to identify the project sensitivity, then set up and monitor the appropriate security measures.
- The Security Baseline: this is a set of basic security rules and standards, translated into “Agile language” (e.g. “as a developer I want to implement security measures to prevent attacks”) for easy integration into the backlogs of the Feature Teams and subsequently implementation during sprints. They are represented as Security Stories:
To reach a minimum level of security, projects (critical or not) must at the very least comply with this Security Baseline.
- Training for the Security Champion-to-be
-
- Presentation of the job description, roles and responsibilities.
- Training on evil user stories (EUS), security stories due to the gamification often used in Agile. Security Champions can get familiar with the Agile Card Game built by Wavestone (to learn more, have a look at that article – in French –).
- Learning how to use the knowledge management (KM) to share information, keep the community alive and know the key personnel.
- Securing team production
-
- Controlling development: training about secure development, securing the CI/CD pipeline, setting up control over the code, etc.
- Defining rules for separation of roles and responsibilities in DevOps: start of production, tests edition, production changeover, etc.
A more complete article will be dedicated to this last part.
What’s next? How do we transform to be able to scale?
This interim period where ISS experts are working in Feature Teams is key for building the different roles, tools and processes.
Once the model is well known by the ISS teams, it is time to deploy this methodology to the entire Agile perimeter.
Communicate
Celebrating successes of the first set of Feature Teams involved in the pilots can trigger adoption by the rest of the teams.
Once the first projects have demonstrated the benefit of the approach and the tools and methods have been developed, it will just be a matter of spreading these best practices throughout the company.
Train
Security Experts could be used as coaches to spread good practices within Feature Teams, which will be trained progressively.
A good solution is to use half of the security experts to share tools and train the teams. That half is known as the Security Enabler Squad.
The other half is then focused on risk mitigation for the critical or less mature areas, supporting them to achieve a good maturity level of the Security Champions of the other Feature Teams.
Communication and animation of the security community must go on around the transformation to support the change of scale.
Control and steer the maturity of the Security Champions
Finally, once Feature Teams are trained to use the security tools and methods, the ISS team, consisting of security experts can focus their efforts on controlling important releases and steering the Security Guild. As it is a space for information sharing, it has to be up to date, to pace up the maturity level of the entire Guild.
How long does it take to achieve full Agile Security?
Initial feedback shows a 3-year transition from the beginning of the intermediate state, when the security team work closely with a few Feature Teams, to a completely autonomous team of Security Champions. It may seem long, but the transition to Agile is much more than a simple change of methodology. It is a real paradigm shift that requires significant change in ways of working and methods to ensure that change can be sustained in the future
In the next article, we will answer the following questions:
- How to ensure security controls in Agile?
- Beyond projects support, how should the organisation and major ISS processes evolve to operate in the new Agile operating model of the company?
