If your business develops software of systems that other rely upon, then it’s critically important that you consider security within the development lifecycle.  That’s what ISO 27001 – A8.25 expects of you.  It’s the first of a series of ISO27001 Annex A controls focused on the development process, so if this control is relevant to you, then be prepared to talk about how you develop (secure) systems and the controls you have applied.

What does the standard require?

The standard states that “Rules for the secure development of software and systems shall be established and applied.” (A8.25 –Secure development lifecycle)

Why is this required?

Security is all about the reduction or management of risk. Without secure development, you risk developing systems which are inherently insecure, and therefore vulnerable to attack or data breaches.

Software is increasingly complex and rarely is ‘stand alone’, as it interacts with multiple different systems and services. Unfortunately, security is still not a primary concern of many businesses, and when new applications and services are being considered, security is usually not the first thing to be discussed. 

Remembering that Information security is primarily concerned with confidentiality, integrity and availability, anything that threatens these principles should be a matter of focus.  However how many times have we heard of a software ‘bug’ or system error that has led to a breach? 

The most recent example of this of course is the Post Office, Horizon scandal. Where an error in the system led to over 700 people being wrongly accused and convicted of fraud. The enquiry continues into how this happened, but at its foundation (and most simple) root cause, was a system that was not built with security in mind. 

Failing to consider security within the development lifecycle could result in data leakage or the system’s functionality exposing data because of unaddressed or unmanaged risks. 

For example, imagine you decide that it would be great if your system captured users names, addresses and other personal data, in order to provide them with a personalised training programme.  If you don’t include security within your development process, you might forget that this data needs to be encrypted, or masked so that it is not visible by unauthorised people.

What the auditor is looking for

For this ISO27001 control, the auditor will expect to see a variety of security measures that might include;

Once you have established if this control is applicable you need to speak to your development team and ask them what the process is for the development of systems and application. This is the process that you will document and evidence in your SSDLC.

Note that this is a ‘lifecycle’, so it is likely to have a defined start, middle and end process which loops back to the start. What you need to establish in the development process is when are we asking questions about risks? Is it at the start of the process, the middle, at the end or several places along the development process.

The answer to this question will be determined by your approach to development. For example if you use an ‘agile’ process for development, then you might look to identify risks through secure code reviews and threat modelling workshops within each iteration of the short development cycle.

 However, if you employ a more traditional ‘waterfall’ approach, then security may sit somewhere in the middle, or at several stages, in the process of planning, design, development, testing, deployment, and maintenance.

Only your development team can explain how development is undertaken, but it is your job to ensure the rules are clearly defined, and that they consider security within the process.

Difficulty rating

We rate this a 1.5 out of 5 difficulty rating. This control is very much reliant upon your development team to explain their approach to software and system development. Your role is to ensure that security becomes part of the process. This might mean including an additional step within the process, or ensuring that before the system is signed-off as complete, that there is a full assessment (testing) of the security.  Of course it makes more sense to consider risk at the start of the process, rather than trying to retro-fit security into the system.  Keep in mind the principles of ‘Privacy by design and default’ and ‘Security by design’, and you won’t go far wrong.

Q&A

Do I need a policy?

Yes, you should establish rules surrounding the SSDLC. This is more of a procedure than policy, as it should outline each stage of the development process. This can be outlined using process flow charts, but should clearly identify when security is considered. It should also outline what happens if an issue/risk is identified.

Is there specific training we should provide?

Yes, your development team need to understand the importance of checking code for errors and issues. The new ISO27001 Annex A Control A8.28 (Secure Coding) specifically expects that secure coding principles have been applied to software development. Therefore it is important that your developers know what these are, and what to do if an issue is identified.