Talking about the myth “Security doesn’t match with Agile”. Why does this myth exist and is it true ?
Let’s talk about Agile ;) In most of our interventions on Digital Transformation missions we include agile methods in our clients’ transformation plans. Agile is even a central element of those plans since most of the KPIs we choose to measure the degree of transformation are agile KPIs. Why ? Because they are very helpful tools to change mindsets and to achieve objectives quickly. Nevertheless, each time we start setting up Agile in big structures, we encounter a string resistance from the Security teams.
This opposition is not without reasons. Let’s try to read some parts of the Agile manifesto and listen to the (all too common) reactions of an IT security guy.
Agile manifesto : Individuals and interactions over processes and tools
Security guy : How could this be a good practice ??!! If so, how could I control the project steps and the tools to reduce security risks !Agile manifesto : Working software over comprehensive documentation
Security guy : I don’t give a sh*t about working software. I need a comprehensive documentation to build a robust security strategy and ensure traceability.Agile manifesto : Responding to change over following a plan
Security guy : How am I supposed to follow the changes? What about audits already planned ? How can I anticipate risks ?😲
Not only does the Agile manifesto scares security teams, Agility principals scares them as well.
Agile principal : Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Security guy : Whaaat ! Continuous delivery ? In your dreams maybe. Every delivery need a month at least to prepare and pass the Security audit..Agile principal : Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Security guy : In this scenario, who is supposed to approve specifications ???
Because the principles and core tenants of Agile seem to go against the process followed by IT Security, many IT managers tend to think that these two methods are mutually exclusive and take away from each other. Simply put, IT Security professionals often consider that, the higher the level of Agile methodology on a project, the lower products security standards will be met. We don’t. On the contrary we believe that , if applied and understood correctly, Agility can improve security through all its approaches and requirements. Here is a way of doing things.
1- KPI : In the first place I think we should find security KPIs in agile project. If it’s not the case add them. Don’t forget to choose measurable ones 😝
2- Sprint 0 : Involve Security team from the beginning. They have a very important role in sprint 0. They can design and approve the main infrastructure architecture of the project, development environment and processes. The security team must ensure that servers, databases, external services, repositories are all secured.
3- CI : You could reveal security values in Continuous Integration pattern : You can start by “code scanning” step before the building phase with advanced vulnerabilities detection and security risks. This step could be blocking step in the pipeline.
4- Team composition: I also recommend to try to including a security member in Agile team. He can :
- be present in all Scrum ceremonies.
- help the PO in writing some User stories such as sign in, register, contact User Stories.
- prepare technical tasks to ensure security respect.
- contribute to “acceptance criteria” redaction to improve security values.
- test and validate User stories related to security issues
5- Automated testing: It’s very helpful to add automated security tests on the application to reduce manual security test and improve time to deliver. Actually, most of security tests are essentially checks that known weaknesses have not been introduced. Bellow are some security tests that can be automated easily :
- Authentication / logout / Session management : Browser automation tools can be used
- Known weaknesses of SSL : Combination between browser automation tools and proxy server.
- Http layer : Injecting attack data in the web tier of the application using security tools
I strongly believe that the application of these points promotes communication and interactions, increases the autonomy and independence of the team, facilitates responding to changes and profites to continuous delivery while strengthening security.
It’s obvious that all these elements mean additional work for security teams since, at the least, it requires them to update their tools and processes. But the biggest challenge is still the mindset change. In short, the Security team must have Agile mindset and we need to start talking about “Security in Agile” and “Agile in Security”.
