ISO27002:2022 explained – Technological controls

In this article, we explain the new ISO 27002:2022 chapter 8 – Technological controls. This covers the controls required to set up and maintain secure technological systems, particularly focusing on secure systems, development and code management. This is the last article in a series of four, each article covering one chapter:

1. organization controls (chapter 5)
2. people controls (chapter 6)
3. physical controls (chapter 7)
4. technological controls (chapter 8) – This article

In the previous version, ISO 27002:2013, these controls were mostly in chapters 9-14. As we described in this overview article, a few new controls have been added in 2022. A detailed explanation of the previous controls can be found in this blog post.

This is a long chapter with 34 controls, so you might want to get a coffee before you begin!

User endpoint devices (8.1)

User endpoint devices are any devices from which information can be accessed, processed or where information can be saved. They include laptops, smartphones and PCs. A policy for user endpoint devices should include registration, physical, password and cryptographic protection, and responsible use. Responsible use includes controlling who has access to the device, installation of software, regularly updating the operating system and backing device up. An organisation may require a specific policy for bring-your-own-device to prevent disputes and the information security risks associated.

Privileged access rights (8.2)

The allocation of privileged or admin access rights to users, software components and systems should be done on a case-by-case basis and only as needed. This means that there needs to be a policy in place determining when access rights can be granted and when they should expire or be revoked. when privileged access rights are granted, the user should understand what they are for and when they should be used. The first step is that privileged users should always be aware that they have admin access rights. These rights should not be used for day-to-day tasks, which should always be done with standard access accounts. Privileged access should only be used when administrator tasks are being conducted.

Information access restriction (8.3)

Access to information and other assets should be based on business need, with access restricted to particular users. Information should not be accessible to anonymous users to prevent untraceable and unauthorised access.  This is important to preserve the confidentiality of information, to monitor its use, and to prevent modification and distribution.

Access to source code (8.4)

Source code needs to be kept secure to prevent unwanted changes and to keep the code confidential. The employees role and business need determines if they have read and write access. Limiting access to read-only for the majority of staff helps to protect the integrity of the code. For the same reason, developers should use development tools that control activities, rather than having direct access to the source code repository.

Secure authentication (8.5)

Secure authentication helps to guarantee that a user is who they say they are. The required strength of authentication is dependent on the classification of the information. Usernames and passwords provide a basic level of authentication, which can be strengthened using cryptographic or biometric controls, smart cards or tokens, or other multifactor authentication. Login screens should show the minimum amount of information possible to avoid providing help to unauthorised persons. All login attempts should be logged, successful or not, so that attacks or unauthorised usage can be identified.

Capacity management (8.6)

Capacity management covers all of human resources, office space and other facilities, not just information processing and storage. Future requirements should be taken into account in business and security planning, particularly if asset acquisition has a long lead time. Cloud computing often allows flexible capacity management. In contrast, physical facilities and personnel may require more strategic planning. Optimisation of physical and digital information storage, deletion of old data, and optimised batch processing and applications will mean that existing capacity is more efficiently used.

Protection against malware (8.7)

Malware detection software (e.g. virus scanners) provides some protection, but it is not the only was to protect against malware. Protection also includes information security awareness, access controls and change management controls to prevent malware being installed or causing problems. As a first line of defence, malware detection software needs to be installed and updated regularly. However, a policy to prevent unauthorised software installation, the use of suspicious websites, the download of files from remote sources and vulnerability detection are equally as important. Finally, the security risks can be reduced by actively planning for a malware attack. Keeping abreast of new malware, isolating critical environments, and making business continuity plans should an attack occur will all help maintain business continuity in the event of an attack.

Management of technical vulnerabilities (8.8)

The management of technical vulnerabilities can be divided into three categories: identification, evaluation and action. In order to identify vulnerabilities, assets must be inventoried with details of the supplier, version, deployment state and responsible owner. The vendor may provide information on vulnerabilities, but the owner should identify additional resources that monitor and release information about vulnerabilities and methods to identify vulnerabilities, such as pen-testing. When a vulnerability has been identified, the risk and urgency need to be assessed, as well as the potential risks of applying an update or patch. Updates can often be used to take action against vulnerabilities, but may not always adequately fix the problem and can introduce new issues. If no update is available or the update is considered inadequate, measures such as work arounds, isolation from the network and increased monitoring may be sufficient to mitigate the risk.

Configuration management (8.9)

Software, hardware, service and networks need to be configured to function correctly with the security settings considered necessary to protect the organisation. The configuration should be based on business need and known threats. As with all secure systems, privileged access should be limited and unnecessary functions disabled. Configuration changes should follow the change management procedure and be fully approved and documented.

Information deletion (8.10)

Information should not be kept for longer than necessary in order to reduce the information security exposure risk, to optimise resource use and to comply with laws such as the GDPR. Approved secure deletion software should be used to ensure permanent deletion and certified disposal providers should be used for physical media. The deletion method used by cloud service providers should be checked by the organisation to ensure it is adequate. Maintaining a record of deletion is useful in the event of a data leak.

Data masking (8.11)

Only the minimum amount of data required for a task should be available in search results. In order to achieve this, personal data should be masked (or anonymised or pseudononymised) to hide the identity of the subjects. This may be required by laws such as the GPDR.

Data leakage prevention (8.12)

Monitoring and detecting unauthorised attempts to disclose or extract data are key to prevention. When an attempt is detected, measures such as email quarantine or access blocks can be activated. Other methods, such as policies and training about uploading, sharing or accessing data should be used to address the risks of staff leaking data.

Information backup (8.13)

The organisation needs a specific policy on back-ups, which covers method, frequency and testing. When developing the policy, the organisation should consider points such as ensuring the completeness of back-ups and restores, the business needs of back-ups, where and how they are stored, and how the back-up system is tested. The back-up system should be considered as part of the business continuity plans and be adequate to meet the continuity requirements.

Redundancy of information processing facilities (8.14)

Any organisation needs a system architecture that is sufficient to satisfy the business availability requirements. Redundancy ensures availability by having spare capacity in case of system failure, and often requires duplicate systems such as power supplies. Adequate redundancy that can be spun up when necessary forms an important part of business continuity planning and should be tested regularly.

Logging (8.15)

Monitoring activities (8.16)

Clock synchronisation (8.17)

Clock synchronisation is important to ensure that the timing of an information security incident is reliably recorded. On-premises systems should use a network time protocol (NTP) to ensure synchronisation. Cloud service providers generally handle timing for logging. However, on-premises clocks may not be perfectly synchronised with the Cloud provider’s clock. In this case, the difference should be recorded and monitored.

Use of privileged utility programs (8.18)

A utility program may be capable of overriding system and application controls. The usage of and access to utility programs should therefore be tightly restricted, with unique user identification and logging of usage.

Installation of software on operational systems (8.19)

Software installation can introduce vulnerabilities in operating systems. To minimise this risk, software should only be installed by authorised persons. The software should be from trusted and well maintained sources or fully tested if developed internally. Previous versions should be kept and all changes logged so that roll-back is possible if required.

Network controls (8.20)

Networks must be secure enough to protect the information passing over them. To keep them secure, they need to be kept up to date and monitored, with the option to limit both connections to authenticated devices and what traffic can pass over the network. A method to isolate the network may be useful should the network come under attack.

Security of network services (8.21)

Web filtering (8.22)

Not every website on the internet is innocent. Some contain illegal information and others distribute malware. Blocking the IP addresses of suspicious websites can reduce the risks. However, not every malicious website can be blocked, so filtering must be accompanied by rules and awareness training on appropriate and responsible internet use.

Segregation in networks (8.23)

Large networks can be split into several domains. This means that different security levels can be applied to each domain, with limited access to different parts of the business network. The networks can be fully physically separated or digitally separated using logic networks. Wireless networks do not have physical boundaries and should therefore be considered as external connections until a gateway such as a VPN has been passed when sensitive data is being accessed.

Use of cryptography (8.24)

The use of cryptography needs to carefully managed, with consideration of the required level of protection, key management, encryption of endpoint devices and how cryptography might impact content inspection (e.g.malware scanning). Key management requires a process generating, storing, archiving, retrieving, distributing, retiring and destroying cryptographic keys.

Secure development lifecycle (8.25)

Secure development covers the construction of services, architecture, software and systems. A key aspect is the separation of development, test (approval) and production environments with secure repositories for source code. Security should be a consideration right from the specification and design phase, with checkpoints built into the project plan and planned testing. The developers must also be aware of secure coding guidelines and be able to prevent, find and fix vulnerabilities.

Application security requirements (8.26)

Organisations need to identify and specify the security requirements for applications, then determine them using a risk assessment. The requirements are determined by the security classification level of the information passing through the application. Requirements can include access controls, protection level, encryption, input and output controls, logging, error message handling, resilience against attack and legal requirements. Security requires particular consideration if the application performs transactions of information or orders and payments.

Secure system architecture and engineering principles (8.27)

Architectural and engineering principles ensure that systems are designed, implemented and operated securely throughout their development lifecycle. Secure system principles analyse what security controls are needed and how they should be applied. Good practice, practical considerations about the cost and complexity and how new features can be integrated into existing systems should also be taken into account.

Secure coding (8.28)

Practising secure coding helps to ensure that code is written to minimise vulnerabilities. Secure coding principles can be used to promote best practice and set minimum standards in the organisation. These should take into account current real-world threats, the use of controlled environments for development and ensuring the competence of developers. Secure coding should also include management of updates and maintenance, particularly checking who is responsible for maintaining codes from external sources.

Security testing in development and acceptance (8.29)

Security testing should be an integral part of development testing. This includes testing of secure configuration of operating systems (e.g. firewalls), secure coding and security functions (such as access). The tests need to be scheduled, documented and have criteria to determine acceptable results.

Outsourced development (8.30)

When development is outsourced, information security requirements need to be communicated to and agreed by the outsourced developer and monitored by the outsourcing organisation. Licensing and intellectual property ownership, testing and evidence of testing, and contractual rights to audit the development process are examples of security considerations that should be agreed between the parties.

Separation of development, test and production environments (8.31)

Testing and development activities can cause unwanted changes or system failure, which could compromise the production environment if it is not adequately protected. The degree of separation between testing and production will depend on the organisation, but environments need to be separated and clearly labelled, so that testing or actions such as compiling cannot take place in the production environment. Changes should be monitored, with careful control over who has access to each environment. No one should have the ability to make changes to both the testing and production environment without prior review and approval.

Change management (8.32)

The confidentiality, availability and integrity of information can all be compromised when introducing infrastructure or software or making major changes to an existing one. A formal process of documentation, testing, quality control and implementation can reduce the risks. Documentation of testing and contingency planning are important in the run-up to implementation, particularly to ensure that new software does not negatively impact the production environment. Operating guides and procedures may need to be altered after the changes have been made.

Test information (8.33)

There are two key considerations for test information: it should be close enough to operational information to ensure the test results are reliable, but it should not contain any confidential operational information. If sensitive information must be used for testing, it should be protected, modified or anonymised before being used, and should be deleted immediately after testing.

Protection of information systems during audit and testing (8.34)

The operational systems should not be unduly affected by audits or technical reviews. To prevent excessive disturbance, the audits should be planned with agreed timing and scope. Read-only access will prevent accidental changes to systems during an audit, and all access should be monitored.

Congratulations, you made it to the end!

Each control measure in ISO 27002:2022 has guidance and implementation suggestions beyond what is summarised in this article. For further information, we therefore recommend reading the norm itself. For a summary of the other chapters in ISO 27002:2022, please visit out blog posts on chapter 5 – organisational controls, chapter 6 – people controls and chapter 7 – physical controls.

Questions or help needed in implementing controls? Get in touch with our consultants!

Image credits: Massimo Botturi via Unsplash; icon by Widyatmoko via NounProject