In ISO27001 Annex A control (A8.3 - Information access restriction), the need to restrict access is clearly required. Why then, do we also need a separate control which specifically relates to source code?
Clearly, ISO27001 feels that controlling access to code is something which deserves special consideration. Perhaps because of our reliance on software and apps which are being created at an exponential rate. We all rely upon these tools, and trust them implicitly, and therefore we need assurance that the ‘heart’ of the app (the code) can be trusted. This is covered in much more detail in several technical controls related to software development.
What does the standard require?
The standard states that “Read and write access to source code, development tools and software libraries shall be appropriately managed..” (A8.4 – Access to source code)
Note that there are three aspects to this control, which requires control over access to;
· Source code – which you create
· Development tools – which you use
· Software libraries – which you access and share code with
Why is this required?
Without control of access to source code, someone could change the code, which could cause it to act unexpectedly. Someone could change the code maliciously or unintentionally, but the outcome remains the same – data breach, impact on reputation, financial losses.
If you develop apps and systems, then your developers are the Golden Geese, and your code is the Golden egg (I hope you’ve read ‘Charlie and the Chocolate Factory’ to get that reference!). Your source code is the thing that will be used many times and is the most valuable asset you have.
If someone deliberately or accidentally contaminates the source code, it could lead to considerable issues for you and your business.
In the same way that source code needs to be protected from contamination, it needs to be protected from theft. Again, it is your most valuable asset. You may have invested significantly in its development, and competitors are keen to get their hands on it. So you do not want your developers uploading code to unprotected libraries, to share with their peers.
This is also becoming increasingly problematic because of the introduction of AI tools, such as ChatGPT. We have heard developers using ChatGPT to ‘de-bug’ their code for them(!), which means copying large quantities of IP protected code being uploaded to the tool.
What the auditor is looking for
The ISO27001 auditor will look for evidence of security measures including;
Allocation of roles & responsibilities (A5.2 - Information security roles and responsibilities).
Segregation of duties (A5.3 - Segregation of duties).
Access Control Policy (A5.15 – Access Control).
Access Rights (A5.18 – Access Rights).
Starters and leavers process (A6.5 - Termination or change of employment responsibilities).
Awareness, education and training (A7.9 - Security of assets off-premises).
Data Leakage Prevention security measures (A8.12 - Data Leakage Prevention)
Logs and monitoring (A8.15 – Logging & A8.16 Monitoring Activities)
How privileged utility programs are used (A8.18 - Use of privileged utility programs)
Policy for the development of software (A8.25 - Secure development lifecycle)
Processes for managing development (A8.27 - Secure system architecture and engineering principles)
How security fits within your development lifecycle (A8.28 - Secure Coding)
Supplier Agreements (for outsourced development) (A5.20 - Addressing information security within supplier agreements & A8.30 - Outsourced development)
Risk Register.
What do you need to do?
There is a lot to do here, but much of this would have been addressed when you considered ISO27001 Annex A control (A8.3 - Information access restriction). However, because this control is looking at source code access, as well as the use of development tools and libraries, you will need to evidence control of these systems and tools too.
First, speak to the development team to understand what the development lifecycle is. To start, speak to the development team and understand the process, where the source code is stored, and who has access to it. This will become increasingly important as you go through the technical controls. Is it on your internal servers? Do you use a Cloud or data library like GitHub or BitBucket? How is code accessed, and who has access to it? What about code reviews? Who performs these? Is it internal to the team, or do you have quality assessors?
Speak to your teams about the development tools, ask them who has access to them, and find out how they provide and revoke access. When looking at the libraries in use, are these locked down to individuals or teams? Have we verified access to ensure that individuals who have left the organisation no longer have it?
Finally, ensure your developers receive training which outlines what they can and cannot do with code. This has become increasingly important over recent over recent years with AI tools like ChatGPT.
If you outsource development, this would be the time to review the contracts in place and understand their working practices, too. You can find more detailed information on this in ISO27001 Annex A control A8.30 (Outsourced development).
Q & A
Are there some common principles we should keep in mind?
Yes, keep in mind the principle of least privilege. What do people need to perform their role? Do they need access to ALL source code? Can we limit their access to only the projects they're working on? This is extremely important in relation to access to your source code. Secure coding practices are covered in the new ISO27001 Annex A control A8.28 (Secure Coding), so review these and ensure you’re following them.
Identify any risks and detail these on your risk register, with an appropriate owner and risk treatment or mitigation plan.
Difficulty rating
We rate this a 3 out of 5 difficulty rating. This control requires you to understand the development lifecycle, but only at a high level. Although you don't need to become a developer, you should understand what code libraries are and how they are used. You need to establish what risks are associated with the use of the code, and these risks may not be instantly clear to your business or the development team.
More questions?
Remember that nothing in ISO27001 sits in isolation, so you should review our FAQ to gain answers to other aspects of the standard. Follow the links in this control to see the relationship in other controls, but if you’re still confused about this control, then please get in touch.
For information on how to implement ISO27001, you might like to consider buying our book “The Real Easy Guide to ISO27001”
Comments