ISO27001 for software development

Author: Gary Hibberd

Date: 23 June 2020

Are you in Software development? Then listen up…

I recently spoke to a software developer who said that the General Data Protection Regulation (GDPR) was too vague to understand, and didn’t impact them because they are developers who develop things for other people.

I’ll be honest and say that it’s not often I’m left speechless, but on this occasion I was.

Privacy By Design

Article 25 of the GDPR is “Data protection by design and by default.” It’s a relatively short article within the GDPR, but it states very clearly the following;

“Taking into account the state-of-the-art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.”

We’ll forgive them the lack of punctuation in this paragraph, but the message is clear; If you’re touching Data (specifically personal data) then you need to ensure Data protection is considered from the inception to completion.

The eagle-eyed amongst you will notice that it does state that it is the responsibility of the Controller to determine these controls, and in many cases, this means your client or employer

Clients/Employers = Controllers

The interesting thing about this relationship for software developers, especially outsourced providers, is that Clients often don’t know what “appropriate technical and organisational measures” are, or how they should be implemented. They leave that kind of thing to you, the developer.

If I’m asking a builder to build a house, I expect them to know how to do it in a manner that is safe and secure. Do I need to explain to them what safe and secure means? I would hope not.

Appropriate technical and organisational measures

I started my career in IT as a FORTRAN programmer, so I understand structure is important. While words like ‘appropriate’ seem too vague for some IT professionals (and many others), the GDPR is handing YOU the responsibility of determining what technical and organisational measures you need to put in place, based on the Data you’re likely to be processing.

For example; Would you feel the same levels of security (technical or otherwise) would be appropriate for these apps;

App1 – An online shopping service for IT Consultants. Data collected includes financial data, home address

App2 – An online therapy service for children & adults. Data collected includes health, age, sex, contact details, guardian details (if under 13).

Would it be appropriate to treat security and privacy the same for both?

So how should developers approach this tricky situation? Thankfully there is an answer.

ISO 27001:2013 – System acquisition, development and maintenance

The objective of section 14 of the International Standard for Information Security, states “that information security is an integral part of information systems across the entire lifecycle. This also includes the requirements for information systems which provide services over public networks.

The control goes on to say that the information security-related requirements shall be included in the requirements for new information systems or enhancements to existing information systems.

This means that at the design stage, in the initial meeting to discuss the application/service you are development, you as the developer need to be very clear about the kinds of data being captured. You need to understand what the data flow is and what security measures you need to be implementing.

If you’re following ISO 27001, then these security measures and rules should be established as policy, so that everyone understands the approach you take to development. This may sound excessive if you’re a lone developer but think of it as an external policy that tells your clients your approach to security.

SDLC

Most (if not all) developers will be familiar with the concept of a Software Development Life Cycle, irrespective of the development approach. It doesn’t matter if you’re using DevOps, Agile, Waterfall, or Rapid methods; All follow a pattern that includes some form of change management that takes the application from test, pre-production and production environments.

The purpose of this blog isn’t to argue the benefits of one methodology over another. What matters is that changes to systems within the development lifecycle need to be controlled by the use of formal change control procedures. 

Again, the word ‘formal’ may sound scary (especially to those familiar with ‘Agile’ methodologies), but formal can simply mean that you’ll have key check-points, and dates to provide releases.

ISO 27001 goes on to say that organisations shall establish, and appropriately protect secure development environments for system development and integration efforts that cover the entire system development lifecycle. This means that as developers, you need to think about where you’re storing your code, who has access to it, and how it is segregated from test and live environments.

Testing, Testing; 1-2-3

And a quick word about Testing of applications and systems. Let’s clear something up; It has never been acceptable and will never be acceptable to use live data in a test environment!  If you are doing this – STOP now. Get in touch, and I’ll happily explain why this is bad practice.

Where you are using anonymised or pseudonymised data, you are still required to select Data carefully, ensure it is protected and carefully controlled. Therefore, Data Retention and Destruction policies need to include considerations for test Data

But let’s assume you’re not using live data, and you have a separate test environment; All good. But you are testing the security functionality too, right? If you’re following ISO 27001, then Annex A14.2.8 specifically requires you to do this.

Conclusion

Information Security frameworks like ISO 27001 are there to offer structure and guidance to organisations developing systems and services, in a secure way. 

If you’re a software developer, you need to have at least a rudimentary understanding of the ISO 27001 framework, but more than a working knowledge of the principle of “Secure by design”. It’s a principle that has been with us for as long as I can remember (and I started programming 35 years ago).

If you’re not sure what OWASP is, for example, and you think this is just for the Pen Testers to be worried about, then you’re already building insecure environments and services. 

Finally, a word to organisations who outsource their development to third parties;  The organisation or legal entity that has outsourced development must supervise and monitor the activity of any outsourced system development. It states this requirement very clearly within ISO27001, Annex:A14.2.7).

Perhaps, more importantly, the Controller has a legal requirement, under the GDPR (Article 28) to ensure that;

Where processing is to be carried out on behalf of a controller, the Controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.  

As the Controller, the person responsible for hiring your Software Development Company, are you confident, when they state that the GDPR is ‘too vague’?