Emma, could you please introduce the topic ?

Historically, the Agile approach is a set of practices used for IT development projects. 

The Manifesto published in 2001 proposes 4 main values to revolutionise the performance of companies:

This emphasis on human interaction between the development team and business teams aims at reducing the time to market of the products developed, as opposed to projects conducted in V-model which, once delivered, may no longer satisfy changing business requirements.

Today, this practice is applied in most companies at all levels. In the latest State of Agile Report, out of more than 4,000 companies surveyed worldwide, 95% declared that they use agile and 65% of them have been practising it for at least 3 years.  In addition to IT, the methodology is also used in marketing, human resources, sales, and finance departments. 52% of the companies surveyed stated that at least half of their company’s departments adopt agile processes and therefore the scalability of such practices should not be ignored.

Beyond a project management method, it is a new philosophy with gamified elements. We no longer speak of meetings but of ceremonies, with new roles appearing such as product owner and scrum master. Using this philosophy, the desire is to create an atmosphere of co-construction and to make maximum use of collective intelligence to improve the company’s performance.

Although the concept of security is present in the manifesto, the integration of such measures into product development is not properly addressed. The method by which security is implemented in V-model projects does not apply to the agile philosophy and thus new ways of implementing security should be identified for it.

 

What are the trends and challenges of this field?

One of our challenges is to provide our clients with a global view of their problems. Adopting an agile approach requires a change in all levels of the business from security, to quality teams and as such the effect on all levels of the business must be considered.

In terms of organisation, the ISS must reposition itself as a service to the business and thus shift its image from a ‘policeman’ to a support function. The role of Security Champion (a member of the feature team such as a developer) becomes the point of contact for the ISS teams. In doing this a connection can be created with each feature team, thus increasing autonomy over security integration. This is not something that can be achieved overnight, it requires training to highlight cybersecurity issues and share knowledge (particularly the basics of ISS and secure development). In addition to this, a security Guild should be created, bringing together ISS experts, security champions as well as security enthusiasts. This allows members to exchange information on the latest security news, good practices as feedback and lessons learned from the field. This Guild must be set-up in such a way to allow easy communication between members (such as on an internal wiki).

After the security champion receives training from the ISS team, they become the security referent and thus developers can turn to them for questions and advice. Therefore, the role in itself is fairly technical. In adopting an agile approach, the ISS experts will keep their role, but the relationship will change from that of control and audit to support and facilitative. Audits can still be carried out (such as penetration tests) at the request of the feature team or on the initiative of the security experts. Methodological tools must also be available to help the Champions in their tasks and this includes rewriting risks in conversational format. To adapt to the use of User Stories by feature teams, the ISS team could try writing Evil User Stories, which correspond to an action carried out from the point of view of an attacker. For example:

Faced with these risks, there are Security User Stories, proposing remediation solutions for EUS, with ready-to-use acceptance criteria. All this can be integrated into a security baseline (also in backlog format, in a product management tool, such as JIRA for example), proposing a minimum-security base to be integrated into the products.

In addition to organisational support for the teams, technical support must be provided by optimising the continuous integration and deployment chain (CI/CD) with tools aimed at automating security as much as possible, which can be called the Security Stack or Security Pipeline: code review, vulnerability scans, detection of secrets, security of the Infrastructure as Code, etc.).  Particular attention must be paid to its own security, so as not to produce the opposite effect… From a shift-left security perspective, security is integrated into the product by default, right from the start. It therefore adapts its velocity to that of an agile approach and enables a shift from a DevOps logic to that of DevSecOps. 

Another role can be created, that of AppSec Manager. This is part of the ISS team and is an expert in software security as well as an expert in the security stack. Their role is to help the developers to prioritise and remedy the vulnerabilities reported by the Stack. They work in tandem with the Risk Manager/IS expert, who provides them with knowledge of the risks associated with the product, which enables a more detailed analysis of the vulnerabilities to be dealt with as a priority. All this helps to create a culture of security by design.

 

What do customer expect?

CISO customers expect to be reassured that security in agile mode will not cause them to “lose control” over the proper implementation of security. The model we propose empowers the feature teams, gives them tools, but security retains control by centralising the performance indicators, by having the capacity to carry out random checks/according to predefined criteria, via bug bounty for example or an envelope of pentester days, to be distributed over the various products.

Secondly, as a consultant, I think that clients expect us to share our convictions and very concrete examples of what we have been able to achieve for other clients. To meet this demand, Wavestone’s Cybersecurity and Digital Trust (CDT) practice has created several methodological accelerators based on feedback from the field, ready to be shared and adapted. Being able to carry out the mission in Agile mode was also part of the expectations, favouring co-construction rather than providing fixed and almost finalised deliverables from the first draft. In this gamification perspective, which is very important from an agile approach, we offer original co-construction workshops based on collective intelligence, thanks to our Creadesk asset, which trains consultants and provides them with tools for remote collective work.

 

Any final advice for our readers?

Implementing a true test & lean approach is crucial. In order to extract the most benefit from using co-constructing tools, we must regularly test and verify them in the field. While anticipating problems is crucial, significant value can be achieved when one we confront the problems as they arise. It allows us to be in direct contact with the business and feature teams, to show them that concrete actions are being implemented. The approach is agile, flexible, and scalable. The accelerators, methodologies and tools proposed evolve during the pilots and become even more relevant for the second wave of pilots, until all the feature teams are integrated.

At the same time, it is important to remember that change management is essential. A real communication plan is needed – building communities of practice/guilds from the beginning of the pilots and identifying early adopters who will be valuable drivers of change within the teams. Agile has a real and rapid impact in everyday life and at all team levels: implementing this change is essential.