ISO 27001 technological controls for software development

The latest version of ISO 27001 contains multiple controls about secure development, engineering, coding and testing that seem to overlap. In this article we provide guidance how to implement these controls. The overlapping controls explained are 8.25, 8.26, 8.27 and 8.28. We also cover 8.31 and 8.33 (test environments and test information).

ISO 27001 and requirements for software development

ISO 27001 was created to help reduce information security risks, by applying a list of suggested controls. The main requirement of ISO 27001 (the so-called High Level Structure) is an about risk management. Companies must analyse their own context and stakeholders, analyse risks and apply controls to manage risks as needed. The standard does however contain many standard controls that you must consider when treating your own risks. In the latest version, the controls are split into organisation al, people-driven, physical and technical controls. Many companies that we help with ISO 27001 make or use custom software, and thus must implement the controls related to software development: 8.25, and further. These controls are very similar and thus somewhat confusing, so they are explained here.

The purpose of the controls 8.25 to 8.28

Control 8.25 (Secure development life cycle Control) is intended for companies that design and implement software and systems, or hire other companies to make custom software for them. The company should have a proces in place to ensure that information security is implemented wehen designing software and systems.

Control 8.26 (Application security requirements) applies to all applications used by the organisation, even if not developed in-house. The purpose of this control is to make sure security is considered when buying ar building new applications.

Control 8.27 (Secure system architecture and engineering principles) requires that engineering principles are applied to all information system development activities. It is thus only applicable to systems designed (hardware design and software design) by the organisation. These principes can be more technical than the requirements from A8.26.

Control 8.28 (Secure coding) is aimed at making sure that during custom software development, the software developers do not create vulnerabilities. This control only applies to actual software development, but not to selection of applications.

The purposes of these controls are slightly different and all four should be implemented carefully. In practice however it is possible to combine the implementations: it is allowed to have one software development description that covers requirements, design and coding. One must however be careful that all three controls are explicitly covered.

Example secure development lifecycle (A8.25)

Having a Secure Development Life cycle means that software is not just coded, but there is a structured process including requirements, design, implementation (coding), verification (testing) and release. In each step, information security should require attention. Since most companies use an agile, scrum-like process, you could list the following steps as your process:

• Requirements: The requirements for each change are documented in tickets / stories, and must contain acceptance criteria. Where applicable, the acceptance criteria include security requirements, such as role based access restrictions, how incorrect input is handled or checks to ensure data integrity. The product owner checks the acceptance criteria when approving the ticket/story
• Design: When needed, the lead developer / CTO create a design and have this peer reviewed by another developer / architect to make sure it preserves security. This includes checking for sufficient availability/redundancy, proper data storage and ability to reach required performance and not introducing hard to maintain new technologies. During the design process the product owner also considers ‘privacy be design’ and tries to minimise the collection or display of personal information.
• Implementation/coding. Developers must know and apply our coding guidelines
• Verification/testing: Code is checked by developer against the acceptance criteria and peer reviewed when checked in. Where possible the development pipeline is automated wit automated unit tests and other quality gates defined.
• Release: Software is tested in a staging / acceptance first and must be approved by the CTO or product owner before deployed into production. The release into production is done via an automated pipeline based on our change management process.

This process description should be documented so that developers can easily access it (e.g. on confluence), referenced from other pages that developers use and also mentioned in developer introduction or training. An auditor might want to see some example tickets with acceptance criteria or see the automated pipeline or release notes.

Background: As far as we could find, the term software development life cycle was first used or popularised by Microsoft around 2010. As their name suggests, Microsoft has a background of developing software for microcomputers without network connections, and like most companies in the 1980’s and 1990’s, shipped software with no security at all, relying solely on network security. In the late 1990’s, the company discovered the Internet, security issues and improved its security practises. Below is their original SDLC illustration, from the 2010 white paper ‘Simplified Implementation of the SDL.doc’.

Example Application security requirements (A8.26)

This control states that information security requirements should be identified, specified and approved when developing or acquiring applications. Many companies use a lot of standard applications and this control should contain requirements that apply to your own and to standard software. Example requirements you could select and list are:

All applications that communicate using the Internet or public networks must use encrypted secure connections for data transport, using TLS.
The web applications must use encryption that scores at least 60% on internet.nl
The supplier of each SaaS solution (Software as a Service application) must have a GDPR compliant privacy policy on their website. Larger vendors must have ISO 27001 or similar certification
Applications that are use for confidential data must offer secure authentication, preferably based on single sign on or multi factor authentication
Applications that are use for confidential data must have role based access, so that we can give different access rights to different roles in our organisation
Applications must have a well-defined test process and change process. This can mean that our organisation has access to an acceptance environment and chan test changes beforehand, of the supplier tests all changes in their acceptance environment.

You must document these requirements somewhere so that the CTO / architect has access to this. You must then ensure that these requirements are included in your own coding guidelines and are considered in your acquisition process. So you might want to refer to these in your supplier management or in your project plan template. Try to document when you choose certain new software whether you checked these requirements, e.g. in the project plan.

Example Secure system architecture and engineering principles (8.27)

This controls states that “Principles for engineering secure systems should be established, documented, maintained and applied to any information system development activities”. It thus applies to systems that you develop yourselves. Note that if your company makes hardware/devices, this control also covers the hardware design process.

Example principles that you might want to document for software systems are:

• Use of standard web frameworks when developing web systems. E.g. use of Laravel for PHP or Django/Flask for Python
• Use of cloud infrastructure to ensure secure hosting and scalability
• Implementation of logging of significant events through a standard logging library or service
• Use of REST APIs to protect against data loss or replay attacks
• Securing APIs using session management
• The use of ‘least privilege’: each component gets only access rights needed
• The use of ‘zero trust’. Authorisation should be checked before sharing information
• Ensuring that any traffic is encrypted

Example principles that you might want to document for hardware devices are:

• The application of hardening: configure devices so that the least number of services are exposed
• Fault tolerance so that faults are detected and possible corrected
• The use of security-oriented design reviews when making significant changes
• Documentation of security features

An auditor can ask to see the document/page containing the principles, can ask for evidence of any training/communication of these principles to designers, or ask for tickets that show that show that incidents have been applied. You might want to tag security related tickets with the word “security” so that you can easily find them during audits. If you do a lof of system design , you might want to keep notes of design review meetings and show these in audits.

Example Secure coding (8.28)

This controls requires organisations to ensure that secure coding principles should be applied to software development. A first step is to create a document or page that is called “Secure coding guidelines” or “coding standard”. The second step is to communicate this page or document to all developers (including external developers).

We suggest that you include rules like the following in your coding standard, You can add or modify rules as needed, these are just common examples that apply to most programming languages.

• All pages and services must check authentication or authorisation before doing other actions.
• Test external input for reasonable size to protect against buffer overflows and denial of service attacks
• Restrict the uploading of files to specific types, and change the name of files so that hackers cannot create or overwrite specific files
• Test all user input for acceptable characters (e.g. numbers only contain numerical characters) before storing or using user input
• SQL queries are not made by concatenating strings. You must use a secure query building method to insert parameters into queries, or use a secure database access method
• Do not hardcode password or configuration items into source code files
• Use a recent and supported version of all third party components or frameworks
• Log all significant user actions or significant events, including errors, access rights changes and admin-only actions
• Do not disclose information in error messages to users.
• Do not disclose passwords in log files

Our suggestions are based on OWASP. You can use the OWASP top 10 in your development onboarding or training. OWASP also offers testing guides and cheatsheets. If you can find one existing guide or cheatsheet that covers everything you need, you can use this as a coding guideline.

An auditor can ask to see the document and page that defines the coding guidelines, and ask developers if they are aware of the guidelines and apply these. They could also ask for evidence of peer review, or to see code examples that are compliant with the guidelines.

Test environments and test information (8.31 and 8.33)

There are two controls 8.31 and 8.33 that are about the environments and data used for testing. You can cover these by creating a separate testing policy or procedure, but you can also add a section ‘secure testing’ to your development documentation. The following is required for these controls

Control 8,.31 requires you to have multiple different environments so that you you can test code before showing it to customers or release it into production. Most companies use DTAP so they have separate development, test, acceptance and production environments. You should document which ones you have and whether you have one acceptance for all customers or one per customer. The control also requires you to secure environments: They should have authorisation enabled and not be accessible from outside if it has standard passwords or encryption disabled. Document your decisions.

Control 8.33 (test information) requires you to carefully decide whether to use real data in test and acceptance environments. You have two options here:

1. Create a completely made-up dataset that will be used in testing. This is the best option when there are many external and/or temporary testers that have not gone through background verification. Screenshots based on this dataset can be safely used in bug reports or user documentation without risk of data breaches.
2. Use an anonymised copy of production data. You can anonimize a dataset by replacing full names and numbers with shortened versions (Anthony becomes A****y), and perhaps shorten some fields and swap other fields. The benefit of this option is that you have a better opportunity to catch errors that only happen with certain input. The downside is a high risk of data breaches. In some fields, e.g. medical fields, specific regulations exist that forbid the use of customer data in acceptance environment.
3. Using a direct copy of production data. This is not a good option. There is not only a risk of data breaches, you also risk accidentally send an email to customers.

You can make different choice per environment, e.g. use made-up data in test environments and a carefully minimised and reduced copy of production data in acceptance.

Conclusion

To comply with ISO 27001, you must document your development and testing process. You can do this efficiently by making a short description of the choices made for each control and combining these in one document. You must be careful not to skip any control: all controls are probably applicable and must be implemented. You should base the actual decisions on your risk analysis process that is part of your overall ISO 27001 approach. Some of the decisions made here should be aligned with your implementation of the organisational controls (e.g. access management) and your people controls (training and background verification).

Image source: Goran Ivas via Unsplash