ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance

What is ISO 27001 Security Testing in Development and Acceptance?

ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance is an ISO 27001 control that requires us to test our software before we put it into production to ensure that information security requirements have been met.

Purpose

ISO 27001 Annex A 8.29 is a preventive control to validate if information security requirements are met when applications or code are deployed to the production environment.

Definition

The ISO 27001 standard defines ISO 27001 Annex A 8.29 as:

Security testing processes should be defined and implemented in the development life cycle.

ISO27001:2022 Annex A 8.29 Security Testing in Development and Acceptance

Implementation Guide

I am not in the business of telling you how to conduct testing. Testing is a professions in it’s own right and information security testing can require some specialist resources . What I am going to do is show you want the ISO 27001 standard expects in the implementation for you to achieve ISO 27001 certification. These are on the whole, no brainers, common sense and what you would expect but let us take a look anyway.

General

Testing is part of the software development lifecycle. There relevant clauses that you need include:

ISO 27001 Annex A 5.8 Information Security In Project Management

ISO 27001 Annex A 8.25 Secure Development Life Cycle

ISO 27001 Annex A 8.26 Application Security Requirements

Secure Development Policy

The first step is to create, or download, your secure development policy. The secure development policy set’s out what you do for information security in the context of software and systems development. It does not set out how you do it, as how you do it is covered in your processes.

The ISO 27001 Template is the quickest way to do this but you can also take a look and write it yourself.

Separate Environments

You are going to make sure that for the in-scope developments that you have separate development, test and live environments with the appropriate management and controls in place around this. This will include the process of promoting through those environments and the authorisations and approvals and acceptance.

Testing in a test environment should be conducted with the test environment matching as closely as possible to the production environment.

It is possible to have multiple test environments to facilitate different kinds of tests.

Testing

All secure development will have testing. It is not our place, again, to tell you how to test as again, this is a profession in its own right but there must be a level of security testing in place that looks at the three parts of information security being confidentiality, integrity and availability.

Simple testing that can be considered here would be penetration testing, vulnerability testing, regression testing, code scanning and code testing.

We conduct testing for new information systems, upgrades, patches, new versions, changes.

When conducting security testing we are testing against a set of requirements that we have defined. This can be in the form of configurations in testing systems. Baseline configurations and using the features of testing tools to enhance our capability.

Testing should consider including:

• Access restrictions
• Global admin restrictions
• Cryptography and encryption
• User authentication
• Secure Configurations

Testing is always proportionate to the risk, importance and data being processed, stored or transmitted.

Test Plans

Testing is conducted against test plans. When creating test plans consideration is given to

• Schedules of Activity
• Schedules of Tests
• Inputs and Expected Outputs
• Evaluation Criteria
• Follow Up Actions

Knowledge and Experience

The standard touches on this in a number of areas, having people with the right knowledge and / or experience to perform the role. This is also true of testing. Having a competency matrix and being able to point to qualifications or certifications will help. Where there are gaps a plan, such as training, should be in place but these are basic HR and people functions that are common place in any role.

Who Tests

Who conducts the test should be considered and be proportionate to the test being performed. Consider testing by the actual developer, peer review testing and also independent testing. An independent test has to be completed before go live.

Types of Testing

There are many types of testing that can be undertaken. The following is not an exhaustive list but

• Code Review
• Vulnerability Scanning
• Penetration Testing
• Peer Review
• Automated Testing
• Manual Testing

Documentation

Be sure to have documented evidence of tests conducted as well as of the acceptance criteria, process and sign offs.

Outsourced Development

If you outsource your development then the third party supplier controls will apply. The main thing is to ensure they meet your requirements for secure development but all relevant controls will apply to them.

Conclusion

Many if not all of the controls that apply to this control are covered elsewhere. Be it the experience, licensing, technical controls but consider them in the context of this clause and be able to evidence them as they apply to secure testing.