In this newsletter, we’ll cope with the Pushing Left approach. What is this approach? Why do we need it?

Let’s start.

A bit of context 

The evolution towards Agile methodologies in project development has allowed development teams to increase the speed at which they release a product. The increase in 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 the worst ones. The main reason is that the traditional way we use 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 offers before they 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 the team performs an analysis),
7. Forwarding of the issues to the development team for the mitigations.

The Pushing Left approach

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

Requirements > Design > Code > Testing > Release
______<<<            <<<       <<<        <<<       <<<

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

The main challenge when trying to apply the Pushing Left approach in an Agile approach is the split of software development into smaller units (Sprint). These contain 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 take care of all the required security tasks… Hard? Yes, Impossible? No, it is mainly a matter of mindset…

How to use the Pushing Left approach

The use of the following approach can include this.

Backlog security analysis > Identification of the abuse cases > Security continuous evaluation
/\___________________________________________________|
|____________________________________________________|

Step 1: Backlog security analysis

Review the backlog to identify, which User Stories impact business features and will require 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 the designer did not expect, allowing an attacker to influence the feature or outcome of the use of the feature based on the attacker action (or input).’

The objective for each User Story :

1. Identify the technical and business attacks from which the feature the User Story represents must be protected namely, the identification of the Abuse Cases.
2. For each identified abuse case prioritized 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 set up 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 time frame of the current Sprint (generally two weeks). If it is not the case, then adaptations are necessary. They could be (among others):

• If the risks are not acceptable, complete removal of the user story
• The refactoring of the user story, if possible, to remove conditions allowing to trigger the abuse case.
• A 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 to add or adapt automated security checks. Those ones are 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 authorization issues, business logic issues…

Benefits:

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

 

Requirement

Applying the Pushing Left in an Agile project requires the presence of security people (internal or external) in the team. The reason is that they 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 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 advice,
• 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 summarize, become the security buddy of the company and share the security knowledge with the team to allow them to understand the encountered security issues…

 

Pushing Left Approach and pitfalls

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

The main pitfalls met with the Pushing Left approach:

Pitfall #1:

The first one is the will to handle all Abuse Cases identified without taking the rating of the risk 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.

Pitfall #2:

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 an agile mindset and propose actionable actions. They must not be afraid to fail and refactor initial proposals based on the development team’s feedback..

Pitfall #3:

The third one is about security checks 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 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 Excellium met during the support of our clients while implementing a Pushing Left tentative.

 

Conclusion

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