Context

The evolution to Agile methodologies in project development has allowed development teams to increase the speed at which a product is released. The increase of speed has brought the ability to provide new features to customers regularly (for instance, monthly).

The side effect of this evolution in software development is that the internal security team becomes a bottleneck in best cases and completely bypassed in worst ones. The main reason is that the traditional way used to evaluate the security before the deployment in production, specified below, cannot follow the production rate of the development teams:

1. Request to external security providers for a penetration test offering before the go Live,
2. Selection of a provider,
3. Planning of the test,
4. Realisation of the test,
5. Reception of the report from the provider,
6. Analysis of the issues by the security team (when an analysis is performed),
7. Forwarding of the issues to the development team for the mitigations.

The challenge

In order to exit from this nightmare, an approach named ‘Pushing Left’ was initiated by Tanya Janca from OWASP Ottawa Chapter in 2018:

 

Figure 1: Pushing Left idea

 

The idea behind the scene is quite simple: include the security into the project from the beginning in order to make the security fully integrated at all steps of the life cycle and also make the security posture of the software clearly defined, visible and measurable at each time of its life.

The main challenge when trying the apply the Pushing Left approach in an Agile approach is that the software development is split in smaller units (Sprint) that contains a Software Development Life Cycle (SDLC) in themselves, thus it needs to include the security in every unit. To allow this inclusion, the security team must help the development team to take care of all the required security tasks… Hard? Yes, Impossible? Not, it is mainly a matter of mindset…

A proposal

The following approach can be used to include this.

 

Figure 2: Main steps of the approach

 

Step 1: Backlog security analysis

Review the backlog in order to identify, which User Stories impact business features and will require a work from the security team (see step 2).

The objective is to plan the intervention of the security team according to the identified User Stories.

Step 2: Identification of the Abuse Cases

During the Sprint planning, identification of the Abuse Cases for all User Stories that are planned to be included in the current Sprint.

Abuse Case is ‘A way to use a feature that was not expected by the designer, allowing an attacker to influence the feature or outcome of use of the feature based on the attacker action (or input).’

The objective for each User Story is to:

1. Identify the technical and business attacks from which the feature represented by the User Story must be protected. It is called the identification of the Abuse Cases.
2. For each identified abuse case prioritised them with a rating. This rating could be CVSSv3 but any rating which has been agreed by the organisation can be used ;
3. Identify the required countermeasures and how to implement and setup them.
4. Evaluate the required effort needed to implement the identified countermeasures against the identified attacks.

The second objective is to ensure that the global effort computed for each User Story (feature + security) can be performed in the timeframe of the current Sprint (generally two weeks). If it is not the case, then adaptations are needed. They could be (among others):

• Complete removal of the user story if the risks is not acceptable.
• Refactoring of the user story, if possible, to remove conditions allowing the abuse case to be triggered.
• Split of the User Story in several smaller User Stories in order to distribute the remediation effort.

Excellium has created a methodology to identify the Abuse Cases and offered it to the OWASP foundation.

Step 3: Security continuous evaluation

During the Sprint:

Leverage the continuous integration platform in order to add or adapt automated security checks based on identified Abuse Cases and other security issues raised during manual security review (see below).

At the end of every Sprint:

Manual security review of all created features in order to ensure that:

1. Countermeasures against identified Abuse Cases are correctly identified.
2. The produced feature does not contain non-obvious security issue like authorisation issues, business logic issues…

Benefits:

Using this approach, the security posture of the software becomes explicit because the attacks from which the software is protected are clearly defined. It also allows leveraging any assessment performed by an external security provider on the software to validate that all Abuse Cases are correctly handled, this, by asking it to control that all Abuse Cases provided by the client cannot be triggered.

Requirement

Apply the Pushing Left in an Agile project requires the presence of security people (internal or external) in the team in order to help the development teams during the three steps of the approach. It also requires that these security people have the same agile mindset that the ones of the development team in order to apply this mindset for all their proposals and actions.

Concretely, it means for a security people:

• Get a Purple mindset (half-offensive and half-defensive) to identify attacks and how to prevent them,
• Be technical,
• Provide pragmatic as well as actionable advices,
• Provide technical guidance as well was secure code snippets, secure configurations,
• Select, install and tune security tools involved in the continuous integration process,
• Continuously adopt technical recommendations, technical proposals and tools usage and configuration to provide real benefit to the team,
• Analyse tools’ reports and derive the actions for the development team (countermeasure, training on a particular security issue…),
• Perform the manual security review and share the result with the team in a sincere collaboration model (avoid a strict auditor approach in which results are provided without guidance and explanation),
• To summarise, become the security buddy of the company and share the security knowledge with the team to allow them to understand the encountered security issues…

 

Pitfalls

The approach contains some pitfalls that can lead to a total failure of the Pushing Left initiative.

Below are the main pitfalls met with the Pushing Left approach.

The first one is the will to handle all Abuse Cases identified without taking the risks rating into consideration. Wanting to address all Abuse Cases can represent an amount of effort than cannot be handled by the development team in a single Sprint. This is even more true if it is not possible to remove some User Stories from the Sprint.

=> Some Abuse Cases can be accepted to only select the ones having a real impact on the business. Abuse cases non-selected must be documented in order to explain why the risk was accepted and prove to an auditor that they were identified.

The second one occurs when security people do not have the agile mindset and try to apply ‘traditional security mindset’ when providing advice. Precisely, it is when the security people use the popular approach ‘You cannot do that, because group policy X does not allow you to do that…’ without providing a solution to the problem or only a theoretical solution that requires the development team to find themselves how to implement it and then lose time in the Sprint.

=> As mentioned above for the security people, they need to acquire the agile mindset and propose actionable actions. They must not be afraid to fail and refactor initial proposals based on the development team’s feedback…

The third one is about security checks added in the continuous integration process. Precisely, when security people added too many checks in one time. Adding many checks too quickly prevent the development team to understand the objective of the check or understand the feedback given by the tool. Another pitfall about the security check is when tools are not enough customised and return too many false positives causing frustration and time loss to the development team.

=> Take time and add the automated security checks slowly by taking into account the culture of the development as well as its maturity regarding the security. Share feedbacks regarding the tools and security checks with the development team and react accordingly in order to provide useful security feedbacks to the developers. Integrate all these tools with the Integrated Development Environment (IDE) of the developers because that is their own daily workplace.

Every Pushing Left tentative can bring pitfall specifics to the company. However, these above are the common pitfalls met by Excellium during the support of our clients while implementing a Pushing Left tentative.

Conclusion

Use the Pushing Left approach in an Agile project is possible but it implies to refactor the organisation of the Agile team as well as processes to include security people as members of the development team and allow them to be part of all phases of the Agile project. It is an important change allowing the security posture of the built software to be clearly defined in terms of expectation. By avoiding a blurry security state, this make the software security visible and clear for everyone.