Software has been dominating the corporate universe, and it is often a differential in an increasingly competitive world. Therefore, software and its developers are mostly embedded in an agile culture – and historically agility and security have not been very companions.
In addition, security has increasingly come to the vanguard, but security professionals have gradually become more out of date in their understanding of the agile culture, creating a daunting gap in the industry. Therefore, we will talk a little about the disagreements between agility and security, mentioning points in which this can be avoided, bringing harmony between both.
The fundamental idea behind agility is culture. The great differential of agility compared to other methodologies is the focus on the constant delivery of value to the customer. Let’s imagine a system with a simple CRUD (Create, Read, Update, Delete) of products.
From this idea, we create a backlog sorting by a degree of value to the customer, suppose it is the same CRUD, where each action would be a story.
So in the planning, our developers come to the conclusion that they can deliver functionality to each sprint. Therefore, they would deliver the “Create” phase, then the “Read”, “Update” and finally, “Delete”.
At the end of a sprint, which normally takes place within two weeks, the customer would be able to register goods. However, let’s suppose that after finishing the “Create”, the client takes a look at the market in which it is inserted, and detects that, better than performing the “Read”, “Update” and “Delete” of a product, it is to have the “Create” Clients. And, therefore, in the next sprint, the “Create” of Customers will be done and not the “Read” of products. In agility, this change is very well accepted.
Now, what if we were in a world without agility? The product would be delivered only after all the features are “ready” and the customer would only realize that he needs a “Create” of customers after that end, thus being able to lose the “time to market”. Another factor that deserves emphasis in agility is constant feedback. Then, at the end of each sprint, the team organizes itself into a “retrospective” ceremony, where they discuss what went well, what didn’t work, and what could be improved. Thus, in the next sprint, it is possible to put these improvements into practice. See how much value agility delivers in just one sprint!
Security, for the most part, continues with “Waterfall” design processes and practices, with requirements defined in advance for the system as a whole: policies, documents, and gigantic wikis. But what’s the problem with all this? Let’s look at the principles of agility:
- INDIVIDUALS AND INTEGRATIONS come before processes and tools;
- WORKING SOFTWARE comes before comprehensive documentation;
- COLLABORATION WITH THE CLIENT comes before negotiating contracts;
- RESPONDING TO CHANGE comes before following a plan.
Basically, we see agility on one side and security on the other, and this game needs to change! Security needs to become an enabler rather than a blocker.
Let’s take an example – a developer brings a genius solution that will add a lot of value to the product. When he presents it, security personnel respond with the following sentence: “We can’t implement it, as this will bring us vulnerability A, B, and C”.
What if, instead, the security team had the following view: “What a great solution! From a security point of view we can develop, but for that, we need to implement controls A, B, C”. It’s clear how the approach was totally different – we see partnering security and putting in the necessary controls.
How to change the game?
We need to strengthen the relationship because DevSecOps is also a culture, which involves a lot of interaction, and facilitating interaction between teams is essential to ensure that security does not hamper deliveries – remembering that deliveries in an agile team are constant.
Security needs to provide quick, informal guidance and answers to questions via instant messaging or chat platforms, email, and, whenever possible, in person.
One way to promote this closeness is through participation in agility rituals. When creating stories by the PO, it is essential to have someone with a security vision to suggest security requirements. In refinement, these security requirements will be discussed along with the functional requirements, removing what doesn’t apply and adding what was forgotten in the story creation phase.
These phases are extremely important for information security, as they will address the security requirements inherent to the story in question, it makes no sense for a story to have, for example, 10 functional requirements and 200 security requirements. Again: requirements really need to make sense for that story.
Introducing agile thinking
The idea of a sprint focused only on security requirements is usually not efficient, as it means that the product, at first, was delivered without security requirements. That is: it went into production without security requirements and then there was a sprint to insert them, which was not implemented in an initial sprint. So the ideal is to insert them along with the functional requirements, so it is essential to define the appropriate requirements in each story.
At the daily, where the state of the story is analyzed, the security team must be aware of issues raised that may affect security and privacy – in the case of stories that are of security importance, the progress of that story needs to be monitored.
During development, have someone with a solid background in security do “pair programming”.
Security should also be involved in reviews and retrospectives, to understand what was accomplished and the challenges the team faced.
Above, some actions that could strengthen the relationship between Security and Developers in an agility team were listed, but there is a problem, it would be necessary to have a security professional available to the teams full-time or almost. Another factor is that, in the agile methodology, teams need to be “autonomous” and depending on a person from another team reduces this autonomy a little. Security Champions can solve this problem, since they would be a member of the team, or sometimes even more than one person, because security needs to be addressed by everyone, remember, the key word here is culture.
As seen, there are many differences between developers immersed in agility and security professionals still treating software like Waterfall projects. Taking into account that DevSecOps is a culture, as well as agility, security specialists can take advantage of the experience of ‘agilists’ in establishing this culture within their teams and with that implementing a culture of Security within the development teams.
In future articles, we will address how OWASP SAMM Agile can help in this mission, as well as about our experiences in adopting the OWASP SAMM framework with agility.