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

What is the objective of Annex A.14.1?

Annex A.14.1 is about security requirements of information systems. The objective in this Annex A area is to ensure that information security is an integral part of information systems across the entire lifecycle. This also includes the requirements for information systems which provide services over public networks.

ISO 27001:2013 addresses the lifecycle through A.14.1.1 to A.14.1.3 and it’s an important part of the information security management system (ISMS) especially if you’d like to achieve ISO 27001 certification.

A.14.1.1 Information Security Requirements Analysis & Specification

Information security related requirements need to be included in any requirements for new information systems or enhancements to existing information systems. This can happen alongside A.6.1.5 as part of the information security in projects and should take into account the value of the information at risk which could align with the information classification scheme in A.8.2.1.

In any new system development or change to existing systems, it is important to understand what the business requirements for security controls are by doing a risk assessment. This should be done prior to the selection of or commencement of the development of a solution. Security considerations should happen from the earliest possible opportunity to ensure that the correct requirements are identified before solution selection commences.

The security requirements should be documented and agreed so that they can be referenced as the solution is procured or developed. It is not good practice to select or develop a solution and then assess the level of security capability afterwards. This often leads to higher risks and costs and may also cause problems in applicable legislation such as GDPR which encourages a secure by design philosophy and techniques such as Data Protection Privacy Impact Assessments (DPIA). There are also numerous websites advocating secure development practices and key principles for consideration such as those advocated by the National Cyber Security Centre (NCSC). ISO 27002 also includes implementation guidance. Any of the principles being followed should be documented.

The auditor will be looking to see that security is being considered at all stages of a project lifecycle, for a new system or changes to an existing system. They will also expect to see consideration for confidentiality, integrity and availability at a minimum prior to the selection or development process commencing.

A.14.1.2 Securing Application Services on Public Networks

The information involved in application services passing over public networks need to be protected from fraudulent activity, contract dispute and unauthorised disclosure and modification. For services being provided over a public network, like the internet, it is important to understand the risk levels involved and the business requirements for protecting information. Once again, it is important to consider confidentiality, integrity and availability.

When financial transactions or sensitive personal information form part of the service, it is especially important to consider security to minimise the risk of fraudulent activity where GDPR requirements for encryption and other safeguards need to be the minimum requirements. Once operational, it is important to ensure that such services are constantly monitored for attack or undesired activity. The auditor will expect to see the consideration for “how secure” application services over public networks need to be, with decisions based on risk assessment and other legal, regulatory and contractual requirements.

A.14.1.3 Protecting Application Services Transactions

Information involved in application service transactions must be protected to prevent incomplete transmission, mis-routing, unauthorised message alteration, unauthorised disclosure, unauthorised message duplication or replay. Additional protection is likely to secure application service transactions (not necessarily just financial transactions). These may include; Use of electronic signatures, Use of encryption; and Use of secure protocols. The ongoing monitoring of such transactions in as near to real-time manner is also likely to be required.

What is the objective of Annex A.14.2?

Annex A.14.2 is about security in development and support processes. The objective in this Annex A area is to ensure that information security is designed and implemented within the development lifecycle of information systems.

A.14.2.1 Secure Development Policy

Rules for the development of software and systems should be established and applied to developments within the organisation. A secure development policy is used to ensure that development environments are themselves secure and that the processes for developing and implementing systems and system changes encourage the use of secure coding and development practices.

Such policies will include showing how security needs to be considered at all stages of the development lifecycle from design through to live implementation. Specific coding languages and development tools have different vulnerabilities and require different “hardening” techniques accordingly and it is important that these are identified and agreed and developers are made aware of their responsibilities to follow them.

Compliant policies will address security checkpoints during development; secure repositories; security in version control; application security knowledge; and developers’ ability to avoid vulnerabilities, then find and fix them when they occur. The auditor will be looking here to see that security considerations are appropriate to the level of risk for the systems being developed or changed and that those doing the development understand the need to include security consideration throughout the development lifecycle. Strong initial screening in hiring for these skills, inlife management and training of resources is essential and practices like pair programming, peer reviews and independent quality assurance, code reviews and testing are all positive attributes.

A.14.2.2 System Change Control Procedures

Changes to systems within the development lifecycle must be controlled by the use of formal change control procedures. System change control procedures should integrate with, be aligned to and support operational change control. Formal change management procedures are designed to reduce the risk of accidental or deliberate development of vulnerabilities that may allow systems to be compromised once the changes are put live. For system change control, it is important that the system owner understands what changes are being made to their system, why and by whom. It is their responsibility to ensure that their systems are not compromised through poor or malicious development.

They should therefore be involved in setting the rules for authorisation and pre-live testing and checking. Audit logs are required to provide evidence of the correct use of change procedures. ISO 27002 documents many aspects of change control that should be included, ranging from simple documentation of the changes through to consideration of the time for deployment to avoid negative business impact. This control like others in A.14 also aligns with documented procedures in A.12.1.2.

A.14.2.3 Technical Review of Applications After Operating Platform Changes

When operating platforms are changed, business critical applications need to be reviewed and tested to ensure there is no adverse impact on the organisational operations or security. When operating system platforms are changed it is commonplace that some applications may have compatibility problems. It is important therefore to test operating system changes in a development or test environment where critical business applications can be checked for compatibility with the changed OS. Procedures for control and testing of operating system changes should follow standard change management control.

A.14.2.4 Restrictions on Changes to Software Packages

Modifications to software packages need to be discouraged, limited to necessary changes and all changes should be strictly controlled. Vendor supplied software packages are designed for the mass-market and are not really designed for organisations making their own changes to them. In fact most of the time the ability to make such changes is locked out by the vendor and customisation limited to within the package. Where open-source software is used, it is far more likely that changes can be made by the organisation, however, this should be restricted and controlled to ensure that the changes made do not have an adverse impact on the internal integrity or security of the software.

A.14.2.5 Secure System Engineering Principles

Principles for engineering secure systems must be established, documented, maintained and applied to any information system implementation efforts. Secure software engineering principles exist at both general levels and specific to development platforms and coding languages. Wherever development is being carried out, consideration for the selection and application of such principles should be considered, assessed, formally documented and mandated. The auditor will want to see that as with many controls, the use of system engineering principles is considered against the risk levels identified and will be looking for evidence to support the choices made.

A.14.2.6 Secure Development Environment

Organisations need to establish and appropriately protect secure development environments for system development and integration efforts that cover the entire system development lifecycle. Development environments need to be protected to ensure the malicious or accidental development and update of code that may create vulnerabilities or compromise confidentiality, integrity and availability. Protection requirements should be determined from risk assessment, business requirements and other internal and external requirements including legislation, regulation, contractual agreement or policies. In particular, if any form of live data is used in development environments it needs to be especially protected and controlled.

A.14.2.7 Outsourced Development

The organisation must supervise and monitor the activity of outsourced system development. Where system and software development is outsourced either wholly or partly to external parties the security requirements must be specified in a contract or attached agreement. This is where Annex A 15.1 is important to have correct as well as A.13.2.4 for nondisclosure and confidentiality.

It is also important to supervise and monitor development to gain assurance that organisational standards and requirements for security within systems is achieved. Depending on how embedded outsource partners are within the organisation, especially if staff are located on organisational premises, it is important to include their staff in security awareness training and awareness programmes and communications. It is critical to ensure that the internal security practices of the outsource partner, e.g. staff vetting, at least meet assurance requirements relevant to the risk levels related to the developments they will be working on.

The auditor will be looking to see that where outsourcing is used, there is evidence of due diligence before, during and after the engagement of the outsource partner has been conducted and includes consideration for information security provisions.

A.14.2.8 System Security Testing

Testing of security functionality needs to be carried out during development. Specific testing of security functionality for any development must be carried out and signed-off by an appropriate authority with security competency and responsibility. Security testing expected outcomes should be documented before testing commences and should be based on business requirements for security. The auditor will want to see that there is evidence that security specific testing has been carried out in any development that is security relevant.

A.14.2.9 System Acceptance Testing

Acceptance testing programs and related criteria must be established for new information systems, upgrades and new versions. For acceptance testing, the tests and the criteria for demonstrating a successful test should be designed and developed based on business requirements prior to tests being carried out. Acceptance testing should also include security testing. The auditor will be looking for evidence that shows acceptance testing criteria and methods were designed according to business requirements and include provisions for security acceptance testing.

What is the objective of Annex A.14.3?

Annex A.14.3 is about test data. The objective in this Annex A area is to ensure the protection of data used for testing.

A.14.3.1 Protection of Test Data

Test data must be selected carefully, protected and controlled. Test data should ideally be created in a generic form with no relation to live system data. However, it is recognised that often live data must be used to perform accurate testing. Where live data is used for testing it should be; Anonymised as far as possible; Carefully selected and secured for the period of testing; Securely deleted when testing is complete. Use of live data must be pre-authorised, logged and monitored. The auditor will expect to see robust procedures in place to protect data being used in test environments, especially if this is wholly or partly live data.

More help on the ISO 27001 requirements and Annex A Controls can be found in the ISMS.online Virtual Coach which complements our frameworks, tools and policy content.