Introduction: Our Agile Security Journey



May 31, 2018

Ernout ‐ CEO

Welcome to: "Our Agile Security Journey". Wouter de Meijer, Ernout van der Waard and Bryan Soman have put together a security blog series to guide you in your decision-making. First up: Our Agile Security Journey.

Organisations must change in order to ensure future growth and success. To do this, we have to maximise digital service potential to connect organisations with the outside world. And while doing this, keeping security in mind.

Organisations undergoing digital transformation often find themselves exposing systems to the internet. Data has to be accessible for external parties. This transition involves breaking down silos and giving stakeholders access to their own data, in addition to enabling self-service. Sometimes this makes you feel vulnerable, as if being connected to outside world is a tradeoff with security. However, this doesn't have to be the case.

What does it take to expose your digital services, without sacrificing security? How do you translate business goals and risks into adequate security measures? And most importantly, doing that without undermining the delivery of the very services that will ensure your organisation's future success? It is these kind of questions that we would like to answer for you in this blog series.


If you want to build and design your online services in a secure way, you need to plan security consistently throughout the development journey. Security is not something that you can achieve by performing ad-hoc security checks before the service is going into production.

At WORTH we are always improving our approach to security, specifically in an Agile environment. In this blog series we share our insights and thought processes on this area of our work.

How to achieve successful security?

Organisations often struggle to define security requirements at the start of their project. How do you set the project up for success? In our experience, the requirements we receive from our clients when they begin a new project have a lot in common:

REQUIREMENT 1: The ISO 27001 security certification

First of all, this certification especially proves that the company is security-aware and is handling data with care. For instance, that your software design documents will be safely stored. Even though this is a good start, this certification does not give you 100% guarantee that security within the applications will be designed and built.

REQUIREMENT 2: Network or access security requirements like firewalls, TLS certification, network segregation, single sign-on/two factor authentication

Secondly, whilst encryption, network security control are important, these are just part of your security design, not the whole picture. It is a myth that with crossing these of your checklist, you have the same level of security as a bank. This is not the case, as security is not only about technical controls but it also involves people and processes.

REQUIREMENT 3: ‘Comply with OWASP top-10’

Thirdly, OWASP top-10 is an extremely useful awareness and educational instrument for web application security. Regardless, it is essentially a reference and is focussed on common mistakes. Being ‘compliant with OWASP top 10’ is not possible, but often what clients mean is not to make any of the most common mistakes. Unfortunately this does not easily identify your risks, which may be outside the OWASP top-10, and only focuses on the technical elements. Where do you need to take action?

REQUIREMENT 4: Comply to NCSC / AVG / BIR guidelines/standards

Finally, these provide a more hands-on list of security requirements. Now it is clear what the expectations are for the online service you are developing. The challenge with these standards is that they are relatively extensive - and you’ll need to decide which are applicable to your situation. Also, another challenge is that the guidelines are outdated the moment they are released. Risks change all the time and a secure application requires continuous focus.

Where agile processes come into place

As outlined above, security requirements are generally focus very specificor are checklist based. This approach is useful. Nevertheless, it does not fully address what activity is needed to deliver a secure digital service.

In our view, successful software teams do not rely completely on project specifications provided by clients. The teams must work with their product owner to finalise them together in an agile process. This is also the case for security. Security is not a binary concept. It's is necessary to define security requirements that satisfy project security needs.

In fact, a development team will more easily spot security risks if they are proactive and aware of security measures. All this is done in partnership with project product owners. This way of working is something that security maturity assessment frameworks like OpenSAMM / BSIMM help to address in more detail. These frameworks have helped us to develop a more secure software development life cycle.

As part of the security improvement journey at WORTH, we have looked at touchpoints in each of the four project stages in the life cycle illustrated in the image below.


What's coming up next?

Finally, how do we ensure transparency? How do we make sure the business risks found in the Discovery phase are traceable when your system is developed and running? How do you recognise a partner that doesn't solely focus on development, but also on design and security? We will let you know next time, so stay tuned!

Blijf op de hoogte