ISO 27001:2022 – 8.28 Secure Coding

With the release of ISO/IEC 27001:2022, we saw the introduction of 11 new Annex A controls, and in this article, we are looking at the final control. ‘8.28 Secure coding’ has been added to the standard to ensure we develop secure code, code as free from vulnerabilities as feasibly possible.

‘But didn’t we have a whole stack of secure coding requirements in the ISO/IEC 27001:2013 version?’, I hear you ask. Yes, yes we did. There have been a number of changes to these controls as well, so If you are doing any type of development, even if it’s outsourced, it’s imperative that you understand your requirements and how all these controls fit together. So let’s look at what we had in 2013 and how it has changed in the 2022 version.

Secure development in ISO/IEC 27001:2013

I’m going to spend a fair bit of time going through the changes for development controls, not just discuss the new 8.28, as anyone doing development will need to address all of these, and 8.28 is tied into them.

ISO/IEC 27001:2013 had a whole Annex A section devoted to development, specifically A.14.2 ‘Security in development and support processes’. This comprised 9 controls:

• A.14.2.1 Secure development policy
• A.14.2.2 System change control procedures
• A.14.2.3 Technical review of applications after operating platform changes
• A.14.2.4 Restrictions on changes to software packages
• A.14.2.5 Secure system engineering principles
• A.14.2.6 Secure development environment
• A.14.2.7 Outsourced development
• A.14.2.8 System security testing
• A.14.2.9 System acceptance testing

Secure development controls now sit within the ‘Technological controls’ section of the new structure. It comprises 7 development controls, inclusive of the new control, as a few have shifted into other broader controls or been combined, which I will discuss below.

Secure development lifecycle

In 2013, the A.14.2.1 Secure development policy control states:

“Rules for the development of software and systems shall be established and applied to developments within the organization.”

A.14.2.1 has been renamed in 2022 as control A.8.25 ‘Secure development lifecycle’. This term better describes the intent, ie managing the lifecycle of development not just a policy to define it. There have also been minor changes to the description:

“Rules for the secure development of software and systems shall be established and applied.”

Of note is the addition of ‘secure’ development, not just rules for how to develop, and ‘within the organisation’ has been removed. The reason for this removal is that ISO/IEC 27001:2022 is addressing not only development for use within your organisation, it addresses the development of products and services supplied to other organisations. Technically, if you were performing development for outside your organisation, secure development should have still been included in the scope of your ISMS, but this formalises it. If you had somehow convinced your auditor that development for external was out of scope, you won’t be able to exclude it anymore.

Change control in development

2013 has three controls that relate to change management within development that have been combined into 8.32 ‘Change management’ in the 2022 version:

• A.14.2.2 System change control procedures
• A.14.2.3 Technical review of applications after operating platform changes
• A.14.2.4 Restrictions on changes to software packages

ISO/IEC 27001:2013 had a control devoted to change management, A.12.1.2 ‘Change management’. While the 8.32 Change management control has very little difference to the old A.12.1.2 control, if we look in ISO/IEC 27002:2022 this paragraph has been added to its guidance to ensure it includes development:

“Change control procedures should be documented and enforced to ensure the confidentiality, integrity and availability of information in information processing facilities and information systems, for the entire system development life cycle from the early design stages through all subsequent maintenance efforts.”

Secure system engineering principles

2013’s A.14.2.5 ‘Secure system engineering principles’ has been replaced with 2022’s 8.27 control and renamed ‘Secure system architecture and engineering principles’. While A.14.2.5 states:

“Principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts.”

The new 8.27 control in 2022 has been slightly reworded to:

“Principles for engineering secure systems shall be established, documented, maintained and applied to any information system development activities.”

The clear difference here is we have changed from secure principles during implementation to any development activities. It is now clear these principles must be applied in all development practices.

Secure development environment

The A.14.2.6 ‘Secure development environment’ control is now included in 2022’s 8.31 ‘Separation of development, test and production environments’ control. A second control from the 2013 version ‘A.12.1.4 Separation of development, testing and operational environments’ is also merged into 8.31.

A.12.1.4 ‘Separation of development, testing and operational environments’ was focused on keeping environments segregated to reduce risk of unauthorised access or unsanctioned changes to operational environments that could cause issues to business operations. 8.31’s purpose is more focused on protecting production environments and data from compromise due to development and testing activities and their impact on these environments when changes are made. This is a much more focused reason.

14.2.6 touched on the need for segregation between different development environments and control over the movement of data between environments, but not in huge detail. If you look at the associated ISO/IEC 27002:2022 reference for 8.31, it goes into a LOT of detail about segmentation, setting up rules between environments, testing in the correct environment, not copying sensitive data to test environments unless equivalent controls are in place, and a myriad of other great recommendations. If you are doing any type of development you will need to go through the details of this control.

Outsourced development

ISO/IEC 27001:2013 had the A.14.2.7 ‘Outsourced development’ control which has moved to the new 2022 version 8.30 control of the same name.

The 2013 control states:

“The organization shall supervise and monitor the activity of outsourced system development.”

While the 2022 version states:

“The organization shall direct, monitor and review the activities related to outsourced system development.”

The intent here is slightly different and shows a maturing of ISO/IEC 27001 over the last 10 years. No longer do you want to be just supervising and monitoring outsourced development, you need to be actively involved, not just a passive onlooker. This means you are directing the outsourced developers in what is required from a security standpoint, for example, aligning with your secure development requirements and overall security standards, and then reviewing their work to ensure it meets your standards and they actually followed your direction.

Security testing and development

In ISO/IEC 27001:2013 there are two controls that cover testing and acceptance within development practices, being A.14.2.8 ‘System security testing’ and A.14.2.9 ‘System acceptance testing’. These two controls have been combined into the new 2022 8.29 control ‘Security testing in development and acceptance’.

If you look at the two previous controls in ISO/IEC 27002:2013’s guidance, they were very short and didn’t provide much detail. The new 8.29 control has been expanded considerably and provides much better guidance on what is expected and most importantly, references the other development controls to ensure testing and acceptance is performed against these controls. For example, ensuring secure coding practices have been used, as outlined in the new 8.28 ‘Secure coding’ control which is the overarching focus of this article. It also makes references to numerous other controls across Annex A to ensure testing is methodical and incorporates all your standards and requirements, such as access control, authentication, cryptography and secure configurations, just to name a few.

What is secure coding and why has it been added?

Now that we have run through the other development-related controls and how they have changed in ISO/IEC 27001:2022, you are probably asking what this new ‘secure coding’ control is and how it differs from the other controls, which to be honest, are quite thorough.

8.28 ‘Secure coding’ is basically the glue that pulls all the other development controls together. The other controls outline areas to address and rules to follow, while this new control establishes structured governance around the entire development process which is critical for the successful application of secure coding processes.

What is the expectation of ISO 27001 Annex A 8.28?

Like the other controls in Annex A, the description for this new control is short and states:

“Secure coding principles should be applied to software development.”

It’s very broad and really requires us to look at 27002’s purpose and implementation advice to understand the full scope of this requirement.

ISO 27002 secure coding implementation advice

As I’ve stated before, even though we don’t have to use ISO/IEC 27002 as our implementation framework for satisfying ISO/IEC 27001 Annex A’s control objectives, it is the best way to understand the intent behind the Annex A controls and ensure we have covered all areas.

8.28 in 27002’s purpose section builds on the Annex A description by stating:

“To ensure software is written securely thereby reducing the number of potential information security vulnerabilities in the software.”

It’s simple and straight to the point but it’s the start of the guidance section that provides us information that really outlines the intent and the scope of where we need to be going, and this goes way beyond anything we had in the 2013 version:

“The organization should establish organization-wide processes to provide good governance for secure coding. A minimum secure baseline should be established and applied. Additionally, such processes and governance should be extended to cover software components from third parties and open source software.

The organization should monitor real world threats and up-to-date advice and information on software vulnerabilities to guide the organization’s secure coding principles through continual improvement and learning. This can help with ensuring effective secure coding practices are implemented to combat the fast-changing threat landscape.”

There are a few critical pieces I want to pull out of this and shine a light on as they are new and unless you have a very mature development practice, may not have them in place. Even if you do, you may not have them documented or maintain the required artefacts to show you are following your processes, which is what your ISO/IEC 27001:2022 internal and external auditor will want to see.

Establishing a secure baseline

To provide an example to better illustrate this point, most of us know what a standard operating environment (SOE) is, a secure configuration standard, a gold image or any other term used for a baseline system installation. We have had these in place for decades to ensure systems and applications are deployed in a known usable and secure state. These baselines go well beyond security, for example, ensuring certain applications are installed by default and configured ready for use, but we are only focusing on security here. When we deploy these images or apply these baseline configurations, we are ensuring adequate security controls are implemented on a default system or application. This ensures secure deployment and reduces numerous security risks out of the box.

The new 8.28 control is pushing this requirement to development practices. While we aren’t talking about some predefined image we roll out like in an SOE, we are looking at the equivalent of the rules we followed to build that image. It is ensuring that baseline requirements, a set of rules, are applied to any new code to ensure it is secure by design. This would include following standardised security requirements, guidelines and best practices, such as the application of coding standards, the use of vetted and approved libraries and frameworks, and the application of your secure development lifecycle.

Software components from third parties and open-source software

This is a great addition and long overdue. We are constantly seeing threat actors breach organisations via software supply chain attacks. Online repositories are rife with code injected with malware, and threat actors are using social engineering methods to trick developers into downloading these infected packages and applying them internally. If you want a great example of software supply chain attacks, just look at SolarWinds.

The new 8.28 control wants to make sure we reduce the risk of malicious libraries, modules, frameworks and other third-party and open-source code. We need to have vetting processes in place, processes to ensure the code we are downloading is from a trusted source and hasn’t been modified, and that we track what we have. Even after we have vetted and implemented third-party code, we need to track what components and supporting software we have in use to ensure it remains secure. This includes ensuring any identified vulnerabilities within these components are patched. Log4j was a perfect example of an open-source logging library used in countless applications where a vulnerable version led to widespread compromise as organisations didn’t know what applications in their environments used the library.

Ongoing monitoring of threats and vulnerabilities

This is another key component that has been added within this control and aligns with the new 5.7 control around ‘Threat intelligence’, which we talked about in our recent article. Staying up to date with what is going on in the world, the ever-evolving threat landscape, current attack vectors, threat actor campaigns, announcements of new vulnerabilities, and release of public exploit code, is critical. You need to stay on top of all of this if you want to be proactive and ensure you stay ahead of the curve. This will ensure your coding practices and principles adapt and improve over time. In this day and age, you cannot have static information security processes. They need to adapt to changes both inside and outside your business to ensure adequate risk reduction.

Before, during and after development

I won’t go into a lot of detail here as it’s very straightforward within the standard, but the remaining part of ISO/IEC 27002’s guidance addresses three key areas:

• Planning and before coding
• During coding
• Review and maintenance

It lays out all the components you should be looking at for the full development lifecycle, which includes ongoing maintenance until the product of your development is retired. These three areas pull together the other controls that address components of secure development in the standard, which I alluded to earlier when I said 8.28 is the glue that pulls them all together and provides overarching governance to your development practices. You will also find it makes reference to other areas in Annex A that support these practices, such as 8.8 ‘Management of technical vulnerabilities’.

How do I comply with ISO 27001:2022 Annex A 8.28?

There’s a lot to unpack in this control, and as we have discussed, it goes well beyond just the new 8.28 ‘Secure coding’ control to encompass the other secure development controls. Below I have summarised the key areas that need to be addressed to ensure compliance and most of all, to provide value to your secure coding practices as ISO/IEC 27001 shouldn’t be a box-ticking exercise. It should provide real value to your business.

I have also included the changes in the other related development controls I discussed above as they are basically components of this control, which is the governance structure over your development practices.

• Product and services provided to other organisations: This is now explicitly stated in 8.25. If you perform development on any service or product provided to an external organisation, it must be addressed within these development practices.
• Change control: You should already have change control processes in place as part of your ISMS, but this needs to be expanded to encompass development.
• Secure system engineering principles: If you only applied these to implementation practices, they need to be expanded to development, as now stated in the 8.27 control.
• Secure development environments: This wasn’t defined very well in the past, so make sure you go through the 8.31 control in ISO/IEC 27002’s guidance as it is a lot more detailed on what is expected.
• Outsourced development: Ensure your processes have you actively involved with any outsourced developers and make sure they are complying to your secure development practices and other security standards.
• Security testing: Make sure that security testing includes testing against your standards and other secure development guidelines. This includes testing of outsourced products.
• Secure coding: As mentioned, the new 8.28 control pulls together all the other controls and ensures you have processes in place prior to, during and after initial development. Ensure these are documented and in place.
• Threat intelligence: To comply with 8.28, make sure your threat intelligence process includes threats related to development practices, such as vulnerabilities and targeted campaigns. This information needs to feed into your development practices to provide value.
• Third-party and open-source components: Document any and all use of third-party components and open-source software. Have processes in place to vet these components before use, secure ways of downloading the component and future updates, and processes to ensure they stay patched and up to date. You should be developing a Software Bill of Materials (SBOM) for your development products.

Secure development is a complex topic and if certifying to ISO/IEC 27001:2022, there is a lot to address. We do a lot of work with clients in this space, so if you have any questions or need help in this area, reach out for a chat.