In most organisations we are using a combination of waterfall or agile development to deliver new business functionality. Unfortunately it is also true that security is not the first consideration, in fact it is often an after thought.
For most large-scale projects, there is a consistent use of SDLC or waterfall approach. These instances have a traditional requirements stage and then formal testing to validate that the specs are met. Such large-scale projects always have a Non-Functional Requirements document that includes “Security” as one key element.
We can think of Security being more akin to a ‘degustation’ course set and there is an expected additional course (stage) that is dedicated for the security test to ensure all needs are met. For such critical projects, there may be time pressure but adequate security testing is usually performed.
Agile Security
In the agile world, a series of sprints are undertaken to build functionality and by definition the requirements are not all known in advance. The requirements are embodied within stories that are built and developed in each sprint.
As the design is made on the run, it limits the bandwidth and opportunity to consider security needs of any new system. Indeed there is a strong temptation to believe that it can be bypassed.
Time is of the essence for nearly every digital project that I have seen. Thus the team naturally wants to deliver these new features into production as quickly as possible.
Let’s remember that a philosophy of MVP or minimum viable product is preached, therefore the team is pushing to not over engineer and keep development to the thinnest possible slice.
A Security Sandwich
The so-called “Security Sandwich” approach is all about trying to adhere to robust security within the agile framework. For example this would mean that you add stories that include the “security” risks and have these integrated into the development process.
To write a security user story, is however not that easy for the average agile developer. Such efforts require a very strong holistic sense of how this story fits into the overall picture. Thus understanding the overall threat model is part of the developer’s responsibility – this means that we have to look at what threats exist and what their impact might be.
A risk-based approach will always assist in getting to the real essence of what the security story needs to cover. This is especially the case as it would often be politically incorrect to have the release delayed due to a ‘security test’.
In the agile world, there is an expectation of continuous releases and delivery.
Compounding this is the fact that security tests usually are about vulnerabilities that exist between different systems and components. As such test automation is going to be tricky.
Best Practices for Agile Security
This is a developing area and there are no simple security metrics that can be pointed to as the ‘answer’. Best practice is about ensuring that security stories are part of the sprints and not a discrete activity prior to the release going live. You just have to design it right.
Instead it is only possible to tackle an agile approach to security – where this is about testing as we go and it is not a ‘big bang’. The developer has to take this task on and not rely on a specialized security team to give the ‘all clear’ at the end. Thus developers are both debugging and also finding security vulnerabilities.
Ideally this occurs on a daily basis as the builds are being developed.
The dual objective is that we want to build software both quickly and also securely. It is indeed a Security Sandwich.
Want to know more?
Why not become a CSO member and subscribe to CSO's mailing list.
Get newsletters, updates, events and more right here.