Architecting Secure Software with ISO 27001 Controls A.8.25 – A.8.27

A.8.25 Secure development life cycle

This clause aims to ensure that your information security is designed and implemented into the development lifecycle of your information systems.

How your organisation designs and develops systems is evolving all the time. It’s what you do day-in-day-out. So, this clause will take some time to figure out for your business.

If you design and develop your own product this clause will have a major impact on you.

If you are embarking on your ISMS journey, the development department might need to be enhanced to introduce systems from requirements capture all the way though to support of the product once it has been released. 

To achieve this, start by mapping your processes from start of development right through to release. These typically include requirements gathering, through development, testing, release, and then support. Then check for the security areas that need to be enhanced.

The standard here gives you areas you need to cover, they include:

• Secure development policy
• System change control procedures
• Technical review of applications after operating platform changes
• Restrictions on changes to software packages
• Secure system engineering principles
• Secure development environment
• Outsourced development
• System security testing
• System acceptance testing

The following clauses will go through some of these in more detail and outline the considerations to ensure that security is embedded within the individual processes that make up the software and product development lifecycle.

A.8.26 Application security requirements

The objective of this clause is to ensure that your information security is an integral part of information systems across your entire lifecycle including providing services over public networks.

So, you need to look across all your systems and check that information security is built into every step.

As part of the previous control, you might have already mapped the development lifecycle, as a way to document all your systems.  Then, you can check all the information security activities for each of the steps and upgrade or enhance what you have in place instead of having to re-invent the wheel so to speak.

Depending on your product, pay particular attention to identity, authorisation and authentication parts of your system, any transactional services where integrations between systems (either your own, or a supplier’s) to ensure that these are appropriately secured, and last but by no means least, and ordering or payment processing.

Don’t forget to also check through all departments, including marketing, development, sales, implementation, support and financial systems for information security vulnerabilities. Updated any documented procedures and added more steps just to ensure that any prevention activities are included.

A.8.27 Secure system architecture and engineering principles

This control aims to ensure information systems are securely designed, implemented, and operated within the development lifecycle.

Here, you should establish development principles by which your teams apply to their work. These should be documented and reviewed periodically to ensure that they are contributing to enhancing security, meeting the latest threats and that the latest best practises are considered. The principles should provide guidance to your team on subjects such as user authentication, secure session control and data validation and sanitisation.

When reviewing any work by developers or system architecture, the new functionality should be checked against these principles, for example, any new functionality should be checked against the data validation principles adopted, or against the requirements of storing configuration or private system data securely.

Other things to consider when establishing the principles are how individual security controls can work together to produce a full suite of controls, any specific controls required by business processes, the capabilities of the controls to prevent, detect or respond to security events.

Security architectures such as “Zero trust” and other principles such as “security by design”, the principle of least privilege should be strongly considered. This can be implemented by using controls like ensuring that each request is encrypted end to end, authenticating and authorising each request for information including authentication information, data classification.

Naturally, any principles should be aligned with and enforced by any third-party development. This can be done by including it in the contract or other binding agreements with the supplier.

In this post, we explore these controls and provide practical tips on how your organisation can implement them effectively to strengthen your security posture and support ISO 27001 compliance.