Testing applications or code when they are deployed to the production environment is necessary to validate if information security requirements are being met.  That’s what this ISO27001 Annex A control is all about.

 Ensuring there is a security testing phase during the design, development and acceptance process is crucial to ensuring no vulnerabilities or risks are left unnoticed.

What does the standard require?

The standard states that “Security testing processes shall be defined and implemented in the development life cycle.” (A8.29 –Security testing in development and acceptance)

 Keep in mind that this control is about Security testing. It’s not an ISO9001 (quality) test, whereby you’re assessing the general look and feel of the application or service developed.

This ISO27001 is interested in understanding security testing processes, to assess the application or code for potential issues which could lead to a breach or cyberattack.

Why is this required?

The primary purpose of testing is to manage the risk of vulnerabilities and identify them as early as possible in the process. Of course, this also offers assurances surrounding the quality of the application or code, which could affect your customers, product, or services.

Failure to test for security weaknesses could lead to a breach occurring, or errors in the systems which result in compliance issues or disruptions to services.  We have already mentioned several times the Post Office, Horizon scandal, and one can only imagine that the testing of the service somehow was not adequate.

But one can look at any major outage and system failure and find that part of the chain of events that was weakest, was the security testing phase.  From banking system failures to the millennium bug, security testing was needed to find the weaknesses and potential issues that might occur.

What the auditor is looking for

For this ISO27001 control, the auditor will expect to see a variety of security measures that might include;

Speak to the team responsible for development to understand and establish what security testing they undertake.  You should try and integrate security testing into the software development lifecycle (SDLC) so that testing happens throughout the process, and not just at the end.

There are different forms of testing that can be undertaken, such as Static Application Security Testing (SAST) where code is analysed for vulnerabilities without it being executed. However, you can also run scans on an application to identify vulnerabilities as the system runs. This is called Dynamic Application Security Testing (DAST).  Ask the development team if they use either of these approaches and then detail this within your Secure Development LifeCycle documentation.

Penetration tests (aka Pen Tests) and code reviews are also methods of security testing, to ensure that the application or code is impervious to attack, or errors.  Pen Tests are a useful tool to ensure that weaknesses are not introduced into your systems at a later stage and vulnerability scans can be automated to identify any emerging risks.

Ensure you speak to your developers about the testing process, but ensure you focus on the security aspects of the tests. Leave them with a clear understanding of what you’re looking for, and that is to ensure they are continually on the lookout for issues related to breaches of confidentiality, integrity, and availability. Through into the mix, the principle of Privacy by Design and Default and they should see that you’re not just looking for a test of the system’s functionality.

Difficulty rating

We rate this a 1.5 out of 5 difficulty rating. This control is about formalising something that most likely already happens in your development teams, but there may not be an emphasis on security. Be clear in your need for security testing and establish what is currently undertaken and then ensure security is at the top of the testing process.

Q&A

How often should security testing take place?

Look at your software development lifecycle and at the end of each phase, there should be a security test taking place. Keep in mind that testing doesn’t have to be technical, but it should be a focus.  For example, if you are developing a new system that requires a password for authentication, then you should test to ensure that the password is masked, so that no on-lookers can see what is being inputted.

Can we skip acceptance testing?

It’s not advisable to do this.  The project initiator, whoever it may be, needs to sign-off on the final application and feel comfortable that everything they required has been delivered.