ISO 27001 - Annex A.14 - system acquisition development and maintenance

What is Annex A.14?

Annex A.14 can be seen as a control that not only oversees procurement processes for new systems, but also provides criteria for new systems that can be tested before going live. This control is also designed to ensure that new systems' security requirements are assessed, established, and measured.

It is common for an organisation to identify the functional and non-functional requirements of a new system when developing a new product. Annex A.14 outlines the organisation's expectations for the system's appearance and capabilities. Before purchasing or creating a system, the organisation can verify that it meets the organisation's needs by comparing it to the system's specifications. This is the time to identify what kind of security measures you'll need.

Annex A.14 has three umbrella controls, each with their own objective to facilitate a successful ISMS and obtain ISO 27001 certification. 

What is the objective of Annex A.14?

Overall, Annex A.14 is about incorporating information security into each stage of a system’s life cycle. To do this, each control offers the following objectives:

Annex A.14.1: Security requirements of information systems

An important goal of this Annex A area is that information security be integrated through the lifecycle of the system. Additionally, this includes the standards for information systems that provide services across public networks.

Therefore, you need to see if information security is embedded into each and every step in all of your systems.

Annex A.14.2: Security in development and support processes

Section 2's goal is to make sure the creation of all of your information systems takes security into consideration. System design and development is a constant part of your organisation’s work. As a result, it will take some time for your organisation to work through this clause.

Your procedures must be mapped from the beginning of development to the end of release. After that, look for any weak spots in the security system.

Some areas that you may need to cover according to the standard are:

• 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

Annex A.14.3: Test data

The goal of the third and final clause is to ensure the protection of data used for testing.

What is system acquisition development and maintenance?

Information systems are an important organisational asset because of the benefits they provide and the high expenditures they incur. Organisations must prepare for the long term when purchasing information systems and services that support their business objectives. On the basis of long-term corporate strategies and the needs of everyone from data employees to the CEO, critical applications and project priorities are established.

A specific information system has to be acquired once the necessity for it has been recognised. In most cases, this is done within the context of the organisation‘s information systems architecture. Either external sourcing or internal development or modification can be used to obtain information systems. Once the need for a specific system has been recognised, system development can begin.

System development is the process of defining, creating, testing, and implementing a new software application or programme. Customised solutions might be built in-house or purchased from a third-party developer. During system development, you need to integrate security into every stage, from project inception to deployment and disposal. It is the most effective strategy to safeguard data and information systems.

During the system’s life, it needs to be maintained constantly. The purpose of the maintenance process is to sustain the capability of a system to provide a service. This process monitors the system's capability to deliver services, records problems for analysis, takes corrective, adaptive, perfective, and preventive actions, and confirms restored capability.

Now that you have an understanding of what Annex A.14 is about, let’s take a look at its individual controls.

What are the Annex A.14 controls?

Annex A.14 has 13 controls in place to assist with the acquisition, development and maintenance of your information security system. They are:

A.14.1.1 Information Security Requirements Analysis & Specification

A risk assessment is essential when developing new systems or making changes to existing ones to determine the business requirements for security measures. This should be implemented before the selection of a solution or the beginning of the development of a solution. Security considerations should begin at the earliest possible moment to ensure that relevant requirements are recognised before the selection process begins.

At each stage of the project lifecycle, the auditor will be looking to ensure that security considerations are being taken into account. Prior to the selection or development process beginning, they also expect to see consideration given to confidentiality, honesty, and availability.

A.14.1.2 Securing Application Services on Public Networks

The information in application services travelling over public networks must be protected from fraud, contract dispute, and unauthorised disclosure and change. For services supplied through a public network like the internet, risk levels and business requirements for protecting information must be understood. Again, privacy, integrity, and availability are key.

When financial transactions or sensitive personal information are part of a service, security is extremely crucial to reduce the risk of fraud. GDPR requirements for encryption and other measures must be the minimum requirements. When functioning, systems must be regularly monitored for attacks or unwanted activities. The auditor looks for "how secure" application services over public networks need to be, depending on risk assessment and legal, regulatory, and contractual criteria.

A.14.1.3 Protecting Application Services Transactions

Unauthorised message change and transmission, unauthorised message disclosure, unauthorised message duplication, and replay are all possible outcomes of unprotected application service transactions. Application service transactions may be more secure if they are subject to additional safeguards (not necessarily just financial transactions). Secure procedures, such as the use of electronic signatures and encryption, can also be considered. These transactions also require constant monitoring in real-time.

A.14.2.1 Secure Development Policy

The development of software and systems within an organisation should be governed by a set of guidelines. Develop and implement systems and system improvements in an environment where security-conscious coding and development techniques are encouraged by adopting a secure development policy.

Policies that are compliant handle:

• Security checkpoints throughout development,
• Secure repositories,
• Security in version control,
• Application security knowledge and 
• Developers' capacity to prevent vulnerabilities and detect and fix them when they do occur.

Auditors want to know that security considerations are in line with the risk of systems being built or updated. They also want to know if employees involved in development are aware of the importance of including security concerns at every stage in their work processes.

A.14.2.2 System Change Control Procedures

Changes to systems in the development lifecycle need rigorous change control procedures. System change control should correspond with and assist operational change control. Formal change management practices limit the possibility of unintentional or deliberate vulnerabilities that could compromise systems once the changes are made. In system change control, the system owner must know what changes are performed, why, and by whom. They must ensure their systems aren't compromised by poor or malicious development.

Therefore, they should specify the rules for authorisation and pre-live testing and validation. Audit logs must show accurate change procedures used. ISO 27002 covers numerous areas of change control, from simple documentation through deployment time to avoid negative business impact. Like other A.14 controls, this one follows A.12.1.2's defined processes.

A.14.2.3 Technical Review of Applications After Operating Platform Changes

When operating systems are changed, essential business applications must be examined and verified to ensure that there is no negative impact on the organisation's operations or security. It's not uncommon for some applications to experience compatibility issues after a switch to a new operating system platform. As a result, it's necessary to evaluate operating system updates in a development or testing environment before implementing them in production. Control and testing procedures for operating system modifications should adhere to accepted change management practices.

A.14.2.4 Restrictions on Changes to Software Packages

Discouragement, restriction, and stringent control are all requirements for software package modifications. Packages from third-party vendors are created with a focus on broad distribution rather than customisation. Customisation is typically restricted to features included in a given package and is not available outside of it. Changes can be made more easily when using open-source software, but this must be restricted and controlled so that they do not have a negative influence on the product's internal integrity or security.

A.14.2.5 Secure System Engineering Principles

Establishing, documenting and implementing secure systems engineering principles is critical to the success of any information system installation. At both a generic and platform-specific level, principles of secure software engineering exist. Consideration should be given to the selection and use of these principles wherever development is taking place, and they should be documented and mandated. To ensure that the usage of system engineering principles is properly balanced against recognised risks, the auditor is going to be searching for evidence to back up the decisions made.

A.14.2.6 Secure Development Environment

It's critical for organisations to have safe development environments that cover the full system lifecycle, from the initial design phase through final deployment. To prevent the malicious or unintentional development and updating of code that could affect confidentiality, integrity, and availability, development environments must be safeguarded. Risk assessment, business requirements, and other internal and external requirements, such as legislation, regulation, contractual agreement, or policies, should be used to establish the level of protection needed. Development environments should take extra precautions to safeguard any live data that may be there.

A.14.2.7 Outsourced Development

Outsourced system development must be overseen and monitored by the organisation. When system and software development is contracted out to a third party, the security criteria must be clearly stated in the contract or agreement that is connected to the project. Annex A.15.1 and A.13.2.4 for nondisclosure and confidentiality are crucial here.

The auditor checks to see if there is evidence of due diligence undertaken before, during, and after the engagement of the outsource partner, including consideration of provisions for information security when outsourcing is utilised.

A.14.2.8 System Security Testing

During the course of development, it is essential to test the system's security features. When it comes to any new development, security testing must be carried out and signed off by an appropriate security authority. Expected results of a security test should be documented prior to testing, and they should be based on the company's security requirements. The auditor will be looking for evidence that any security-relevant development has undergone security-specific testing.

A.14.2.9 System Acceptance Testing

There must be procedures in place for testing and approving new systems, updates, and new versions of existing ones. Prior to conducting any acceptance testing, the tests and the criteria for demonstrating that a test was successful should be defined based on business needs. Security testing should also be a part of the acceptance testing process. Security acceptance testing should be included in all acceptance testing criteria and procedures according to the auditor's requirements.

A.14.3.1 Protection of Test Data

It is imperative that test data be carefully chosen, preserved, and monitored. Ideally, test data should be created in a generic form that has no connection to the live system's data. However, it is widely accepted that real-world data is typically necessary for accurate testing. Anonymised as much as feasible, carefully picked, and securely erased when testing is over. The use of real-time data must be pre-approved, logged, and monitored. When testing with live data, the auditor will be looking for mechanisms in place to ensure the security of that data.

Why is system acquisition development and maintenance important for your organisation?

As society progresses further into a digitised era, acquiring, developing and maintaining systems for information security is of utmost importance. Business Information System makes it simple to store operational data, revision histories, communication records and documents. Further, as cyber attacks and cybercrime become more prevalent, a well maintained information system with security controls helps to protect the information from various threats. 

As an organisation, customer and supplier trust is key to business operations. Applying the controls of Annex A.14 will further establish strong bonds of trust and increase your reputation as a safe service provider.

Conclusion

Information security is an integral part of an information system’s life cycle. From making the decision to acquire a new system, to developing and maintaining said system, you should look at applying InfoSec controls along the journey. It helps establish safer business practices and protect your valuable information. 

At DataGuard, work with industry experts to assist you in your journey to getting ISO 27001 certified. From acquiring systems for your organisation to developing and maintaining them, we are here to help.