ISO 27001 Annex A.14 : System Acquisition, Development And Maintenance

A.14.1 Information security system requirements

A.14.1.1 Information security requirements, analysis and specification

Information security requirements should be factored into all new information systems from inception within the organisation. It’s a good idea to run a risk assessment analysis to determine the threat you will be facing with all security requirements documented and used as references for the subsequent system implementation and reviews.

A.14.1.2 Securing application services on public networks

Application services are often facilitated over digital communication channels and through the use of public networks. These activities may involve the dissemination of individual identification data and financial information.

Without effective security controls your company runs the risk of data loss or corruption of sensitive data being transferred across these open networks. .Any sensitive information transmitted through these media must be protected by strong transmission controls and procedures. Your systems will also need to be monitored for possible issues and attacks.

A.14.1.3 Protecting application services transactions

Both financial and non-monetary transactions are involved in online application processes. While the financial process may incorporate bank cards and e-commerce credentials, non-financial information assets like e-signature and encryption codes also come into play. Your organisation’s responsibility is to secure all forms of confidential data, transacting in your system from illegal interceptions, availability attacks or unauthorised disclosure, etc..

A.14.2 Development and support processes

A.14.2.1 Secure development policy

Regulations must be implemented to ensure the safe development of software and related systems within the organisation. A secure development policy highlight standards that foster secure standards for companies to facilitate in-house digital productions.

Best practices and specific crypto language techniques will be enforced to support secure coding within the data security perimeters, security checkpoints and version controls Software and system developers will need to attend training on these policies related to:

• Secure coding principles
• Pair programming and peer reviews,
• independent quality assurance tests and
• Encryption reviews and assessments.

A.14.2.2 System changes control procedures

Any changes to the systems throughout their development cycles need to be managed by formal change management procedures and monitored and verified by authorised staff. This is done to ensure the best quality outcomes from all processes and reduce the chances of introducing new vulnerabilities to the system. All changes performed must be documented and kept for future reference.

A.14.2.3 Technical review of applications after operating platform changes

Changes to systems will likely produce some errors or incompatibility but developers must commit to first testing these changes before applying them to live company operations. This testing will assist with identifying issues in the prototype can be identified, rectified and refined without causing considerable complications with the live environment.

A.14.2.4 Restrictions on changing to software packages

Companies are advised against making changes to off the shelf software packages as most of these products were created for mass commercial distribution and you lack permissions to alter their settings.

Although open-source software might allow such changes, there still lies a risk of damaging the product and connected company files in the process. Tso in essence the integrity of all purchased software should be respected and maintained by all means.

A.14.2.5 Secure system, engineering principles

Principles and guidelines should be established for ensuring secure engineering processes among internal software developers. These principles should resonate at all levels of the organisation where they apply to minimise the incidence of resulting discrepancies. All proposals for new engineering practices must first be presented for approval and then carried out as per the ISO27001 requirements.

A.14.2.6 Secure development environment

Your organisation must create development environments where developers can securely work on projects. This means that access controls most be segmented between environments and the development environments are protected by secure practices and developers monitored and prevented from following insecure practices.

A.14.2.7 Outsourced development

All outsourced development should be managed to ensure that your security standards or better are applied. Contracts should include clear security requirements, ownership and nondisclosure terms. These parties should also be included in your company’s training and awareness programs.

A.14.2.8 System security testing

Security functions integrated into the development process must all have a well-defined formal testing process and be tested by experienced and authorised parties.

You should record the results you expect to receive from these procedures before testing begins. Your auditor will also want proof that you carried out the security testing so be sure to include some form of documentation.

A.14.2.9 System acceptance testing

There should be an acceptance testing program and approval criteria established for all new information systems and projects requiring updates and version changes. The criteria for acceptance testing should be based on your business requirements and how you expect these changes to help achieve company goals.

A.14.3 Test data

A.14.3.1 Protection of test data

Tests allow us to produce results that we can use to compare real life situations with system testing helping developers assess the number of vulnerabilities associated with their models. The outcomes are then used to improve the system and reduce possible threats.

Test data is usually simulated as much as possible to mimic natural test environments because realistic tests generate reliable results. ISO 27001 recommends that all tests are to be selected using specific guidelines with samples needing to be protected and controlled.

The problem is, test data isn’t always sufficient and sometimes live information needs to be used under an anonymous identity to conduct accurate testing. Using actual data increases the risk associated with the process so to reduce the severity of the procedure, developers can opt to:

• Use security policies (including access control, encryption and monitoring) to protect live testing data.
• Securely delete the live data after testing. Any time Live data is considered its use must be reauthorised, monitored and logged.