If you’ve been following along in the ISO27001 Annex controls, you’ll have already started thinking about the principles of secure development. 

In ISO27001 Annex A Control, A8.25 (Secure development lifecycle) you were asked to establish the rules for the secure development of software and systems, and this might include outlining secure coding guidelines for different programming languages.

ISO 27001 – A8.28 asks you to specifically consider the principles as they relate to coding. This is to ensure software is written securely, which can then reduce the number of potential information security vulnerabilities in the software.

Of course, if you don’t have any coding, then you can skip right along and consider this control ‘Out of Scope’. 

What does the standard require?

The standard states that “Secure coding principles shall be applied to software development.” (A8.28 – Secure Coding) 

Why is this required?

Consider this for a moment, without someone sitting down and creating the application you are using, you couldn’t read these words.  ‘Code’ informs systems what to present, when to present and how to present data to us. 

If software code is not operating correctly, or securely then it is prone to error or attack.  In deed ISO27002:2022 makes the statement that “Application code is best designed on the assumption that it is always under attack, through error or malicious action’.  No wonder then that this new control has made its way into ISO27001. 

Without following secure coding practices we leave ourselves from potential errors and malicious attack that could result in financial and reputational losses.  

Again, we can look at the recent case of the Post Office and Horizon scandal, which is still being investigated and understood.  But what we do know is that a software error resulted in a series of miscarriages of justice. People lost their livelihoods, had to move homes (and countries), and others were imprisoned.  Wrongly accused of fraud because, ultimately, software code got it wrong. 

There are undoubtedly a number of failings in this situation, but at its heart this is a story of poor coding practices leading to errors which meant the system could not be trusted (breach of integrity). 

Of course, it doesn’t need to be as dramatic as this to be an issue.  Without good secure coding practices in place systems can fail dramatically, or simply slow your operation down. Leading to financial impact due to slow systems or people needing to create ‘work-around’ solutions. 

What the auditor is looking for

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

 The auditor will be looking for the following to be in place;

• Segregation of duties (A5.4 – Segregation of duties)
• Threat modelling (A5.7 – Threat Intelligence)
• Special interest groups that focus on coding (A5.6 – Contact with special interest groups)
• Classification and handling of code (A5.12 – Classification of information)
• Access to code is controlled (A5.15 – Access Control)
• Documented Secure Software Development Lifecycle (A8.25 – Secure development lifecycle)
• Management Review Team (MRT) meeting minutes.
• Awareness, Education and Training (A6.3 – Information security awareness, education and training)
• Use of Coding tools (e.g. compilers) (A8.18 – Use of privileged utility programs)
• Risk Register.
• Audit results.
• Incident Logs.

What do you need to do?

Speak to the team responsible for development to understand and establish what they do in relation to Code.  Specifically you’re looking to assess;

• What development is undertaken?
• Who is involved in the coding process?
• What languages are used?
• What platforms are used?
• How code is separated from live environments?
• What is the testing process?

Some, or all, of these questions may have been covered in your establishing of controls around ISO27001 Annex A control A8.25 (Secure development lifecycle). But if you haven’t gone to this level of detail, then now is your time.

For example, once you understand what language the code is created in, you can look for specific security coding practices related to that language. Ask the team where they get this information from, as it might come from special interest groups that they are members of. This is a great example of why ISO27001 controls such as A5.6 (Contact with special interest groups) are so important.

On an ongoing basis you must ensure these principles are being followed, and this should form part of your audit of this control. This will evidence that the principles are being maintained and implemented. If there are any issues or incidents, investigate whether the principles failed or hadn’t been followed.

Difficulty rating

We rate this a 1.5 out of 5 difficulty rating. This control is about formalising something that most likely already happens in your development teams. Your job is to ensure that the principles are being followed. Therefore, this control is more about establishing what you do, documenting it and then monitoring the process to ensure it happens.

Q&A

Do I need a separate document for these principles?

Although there is no mandatory requirement to document your processes, we would advise you to update your software development lifecycle documentation to reflect how code will be managed in a secure way.  Always keeping in mind that information security is interested in;

• Confidentiality – of the code you are creating (keep in mind ‘need to know’ principles)
• Integrity – of the code, by ensuring it is tested rigorously for vulnerabilities
• Availability – of the code so that you can return to the source (code) should you need to 

Code is at the heart of your system. It’s at the heart of every digital system, irrespective of platform or device. It is therefore vitally important to ensure secure coding practices are adopted.