ISO 27001 Information Security - Annex A 8 Technological Controls

This article on Annex A 8 Technological Controls is based on an extract from the Guide Book in the Qudos ISO 27001 InfoSec Toolkit - exclusively available as an integrated component of Qudos 3 software.

8.1 User endpoint devices (6.2.1 / 11.2.8)

Unattended user equipment should be protected. That might include using physical security devices such as a Kensington lock that attach a cable from a computer to a stationary object such as a desk. Many laptops have a Kensington Slot or K-Slot that can be used with a standard security cable lock. Another example of protection is by timed logouts in the event of inactivity. This topic is often covered in conjunction with Control 7.7 Clear desk, clear screen.

With the increasing prevalence of remote working, consideration needs to be given to requirements for controls and how they can be implemented when working from home or other remote working environments.

As people have largely moved on from desktop computers to laptops, there is an increased risk of the device being lost or stolen.
Encrypting the hard drive helps address the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers.

8.2 Privileged access rights (9.2.3)

Privileged access rights are those that provide levels of special access or capability above those of a regular user. An example would be 'Admin' rights
that allow a user to install / modify / remove software, configure networks or systems, load device drivers, change passwords for other users,
or grant / deny access permission for other users. Such rights should be restricted and managed as appropriate. While privileged rights are necessary to ensure efficient operations, there is also the need to minimise the opportunity for misuse or abuse. Privileged access rights should only be granted cautiously.

8.3 Information access restriction (9.4.1)

This is a preventive control to protect against risk by establishing business rules against unauthorised access or misuse of information and ICT assets.

Access to information and associated assets should be restricted to only those that need it for legitimate purposes. A central tenet here should be the principle of least privilege. These restrictions may best be referenced in an Access control policy.

8.4 Access to source code (9.4.5)

Source code is the version of software as it is originally written by programmers (in plain text or human readable alphanumeric characters).
Where an organization has source code, the access to that code must be managed.

Source code is typically managed in a specialised application - especially when there is access by multiple programmers.

Where an organization does not possess any source code (e.g. where it does not develop software), this control may not be justifiably excluded.

8.5 Secure authentication (9.4.2)

Secure authentication arrangements must be in place to ensure the identity of users and other entities. These should be referenced in an
Access control policy. Secure log-on procedures need to be in place as applicable. They may include various methods such as password handling procedures, MFA (Multi-factor authentication), CAPTCHA tests, and biometric authentication (such as fingerprint scanning, facial or voice recognition).

Qudos 3 IMS software installations may use the software's own MFA or SSO (Single sign-on) options.

8.6 Capacity management (12.1.3)

To ensure the availability of information, there needs to be adequate capacity in terms of people, information storage and processing resources, and the supporting infrastructure. Any trends in utilisation / spare capacity should be monitored - especially for mission-critical areas and systems
and / or those which may have a long lead-time to increase capacity when required.

Ultimately, there are two methods of matching capacity with demand. The capacity itself may be increased or the demand may be reduced.

8.7 Protection against malware (12.2.1)

Malware is an abbreviation of 'malicious software'. It may be defined as software that is specifically designed to disrupt, damage, or obtain unauthorized access to a computer system. Controls are required to detect and prevent malware, to recover from it, and to ensure an appropriate level of user awareness to avoid or minimise its impact.

8.8 Management of technical vulnerabilities (12.6.1 / 18.2.3)

Vulnerability assessment and penetration testing

IT assets may have technical vulnerabilities that threat actors could exploit or use to penetrate your networks. Vulnerabilities may arise from many sources including poor application design, unpatched software, weak passwords, inadequate access controls etc.
The initial requirement here is to prevent the exploitation of technical vulnerabilities. So, vulnerabilities should be assessed and addressed. A penetration test may also be required in some cases. This is performed by a specialist in the field who can identify vulnerabilities, attempt to ethically simulate the threat that can exploit them, and the exercise will typically also identify possible remedial actions.

8.9 Configuration management

This is a new control in ISO 27001:2022.

Processes should be in place define and implement configuration settings for hardware, software, services, and networks.

8.10 Information deletion

This is a new control in ISO 27001:2022 to delete any stored information that is no longer required.

This requirement can have quite far-reaching consequences. Consideration needs to be given to deletion of information that may be on many different assets and in many different locations. Also, to the most appropriate methods to be used, taking into account the applicable risk and compliance obligations.

8.11 Data masking

This is a new control in ISO 27001:2022 and is aimed at limiting the exposure of PII and other sensitive data.

Data masking is the technique of creating an alternative version of data that is structurally similar but hides the original data.

It is used when data may be shared with unauthorised users. Common examples are the replacement display of stars in software password fields, and the replacement display of 0's or X's instead of credit card numbers in eCommerce portals and printed receipts. Data masking is accepted as a technique to protect an individual's data by EU / UK GDPR.

8.12 Data leakage prevention

This is a new control in ISO 27001:2022.

This control is about preventing the unauthorised sharing of information.

There is a subtle but important difference between a data leak and a data breach. Data leakage may be considered to be when sensitive
data is unknowingly exposed outside the organization. A data breach is caused by an attack. A data leak may be caused by human agency or by software or files not being configured correctly. A data leak may, of course, lead to a data breach.

8.13 Information backup (12.3.1)

Backup processes are required in order to mitigate against the effect of loss of data. As with so much of an ISMS, a backup strategy depends very much on risk. Consideration needs to be given to the impact of losing data. That consideration will lead to a determination of what data should be backed up, how often it should be backed up,
and the method to be used. Once a backup strategy is in place, it should be monitored and tested periodically for assurance that it is working correctly.

Historically, backup regimes relied on tapes and more recently on removable hard drives for backups. Increasingly, organizations now utilize cloud service providers to perform backups for them. While that can solve a lot of headaches, it is still worth seeking confirmation about arrangements for those backups.

8.14 Redundancy of information processing facilities (17.2.1)

Consideration should be given to an appropriate level of redundancy in systems and components. These redundancy arrangements should be periodically tested to ensure that they will work if needed in practice. A simple example may be the use of mobile wi-fi for internet connection in the event of failure or non-availability of an office network.

8.15 Logging (12.4.1 - 12.4.3)

Logging is required in order to record significant events and generate evidence. Logs should be maintained of significant events such as Log-on and log-off dates / times.

Logs should only be accessible by suitably authorised people and safeguarded against tampering. Those with administrator privileges may potentially be able to manipulate the logs on systems under their direct control. Therefore, logs should be suitably protected and reviewed to maintain accountability.

8.16 Monitoring activities

This is a new control in ISO 27001:2022.

Monitoring must be performed on networks, systems, and software to detect issues or unusual behaviour. The intention is to be able to
evaluate and avoid or minimise the impact of potential security incidents. Where possible, automated, continuous monitoring tools should be implemented with alerts to relevant team members by email or SMS.

8.17 Clock synchronization (12.4.4)

Synchronization of clocks is important in computer networks as many aspects of managing them involve determining when events occur.
Clocks in IT systems used should be synchronized to approved time sources such as NTP time servers.

8.18 Use of privileged utility programs (9.4.4)

A privileged utility program is one that is capable of overriding normal system and application controls. They may include antivirus, diagnostic and backup utilities amongst others. The requirement is to restrict and tightly control their use. Although documentation not a specified requirement, business rules regarding use of such utilities may usefully be documented in policies and operating procedures.

8.19 Installation of software on operational systems (12.5.1 / 12.6.2)

There should be procedures in place to control the installation and updating of software systems in use. Commercial software applications in use should be maintained at a version that is supported by the vendor.

Control of software installation may include restricting the ability of users to install software. Where that is not possible, by 'white-listing' approved applications, and 'black-listing' those that are forbidden.

8.20 Networks security (13.1.1)

This control area focuses on ensuring the protection of information across the network and seeks to maintain security when it is processed or
transmitted within the organization or shared with any external parties.

8.21 Security of network services (13.1.2)

Security measures necessary for network services must be identified and implemented (by your in-house IT team or external service providers).
These may be documented in operating procedures.

8.22 Segregation of networks (13.1.3)

Network segmentation and segregation are effective strategies to limit the impact of a network intrusion. They strategies can make it significantly more difficult for a threat actor to locate and gain access to sensitive information, and increase the capability to promptly detect their activity. Examples of implementation include segmenting a network to protect key hosts, and segregating high-risk applications from a network.

8.23 Web filtering

This is a new control in ISO 27001:2022.

It requires access to external website to be managed in order to avoid or reduce exposure to malicious content. The methods of addressing this control are likely to provide another illustration of integration with other clause and controls within ISO 27001.

8.24 Use of cryptography (10.1.1 / 10.1.2)

Cryptography is a translation from the original Greek for hidden writing. It is the process of securing information by the use of codes - of encrypting it.
Cryptographic solutions reduce the ability of non-authorised entities from gaining access to information.

The objective of this control is for appropriate use of cryptography. As a fundamental control within the ISMS, rules should be established to support the use of cryptography and the also for management of keys throughout their lifecycle. Those rules are typically defined in a documented policy.

8.25 Secure development life cycle (14.2.1)

Controls must be in place to ensure security during the development of software and systems.

Apart from being good practice from an information security perspective, it makes sound economic sense to incorporate security at an early stage of the development life cycle. NIST (The US National Institute of Standards and Technology) estimates that any code remediation performed after production implementation can cost up to 30 times that of remedial action performed at the design stage.

8.26 Application security requirements (14.1.2 / 14.1.3)

Information security requirements must be defined when acquiring or developing applications. The reference to 'acquiring' means that the control applies to those organizations that purchase or licence applications in addition to those that are developers.

Those requirements may include cryptographic controls, authentication methods and user options etc.

8.27 Secure system architecture and engineering principles (14.2.5)

Principles for engineering secure systems are required to documented and put into practice. These should include principles such as security by design, least privilege, and defence in depth - amongst others.

A review should take place to identify vulnerabilities and ensure that appropriate controls are specified.

8.28 Secure coding

This is a new control in ISO 27001:2022.

It requires secure coding principles to be applied at various stages including planning, during coding, review, deployment of updates, and maintenance. Threat intelligence may be utilised to identify new vulnerabilities and provide guidance.

8.29 Security testing in development and acceptance (14.2.8 / 14.2.9)

Security testing must be implemented to validate that applications meet the security requirements. The testing may take a range of forms including:

• Code review
• Vulnerability scanning
• Penetration testing

8.30 Outsourced development (14.2.7)

Where the development of software or systems is outsourced, the organization needs to exercise control to ensure that its security requirements are implemented.

8.31 Separation of development, test and production environments (12.1.4 / 14.2.6)

An appropriate level of separation must be established between development, testing, and production (live) environments. The primary reasons for the control are to preserve integrity of production data (by preventing developers from unintentionally modifying it), protect availability by avoiding data from being accidentally wiped during development or testing, and to protect confidentiality by keeping sensitive production data away from
those that may not be authorised to access it. The separation may be physical or logical.

All environments must also be kept secure.

8.32 Change management (12.1.2 / 14.2.2 to 14.2.4)

Changes to facilities, systems, and software should be subject to proper change management procedures. The intention is that the changes may be implemented to take a situation from its current state to a future state without introducing any information security issues. The standard does not prescribe any particular documentation here, but change management would typically be documented in a procedure. Depending on the nature of the change and the size / complexity of the organization concerned, there may be a significant change management process to follow.

This control may be most efficiently addressed alongside clause 6.3 Change management.

8.33 Test information (14.3.1)

Where data is used for test purposes, it must be carefully selected and managed to avoid any security breach. While production data can make for very realistic and efficient set of test data, its use as such introduces a minefield for loss of confidentiality / breach of privacy.

8.34 Protection of information systems during audit testing (12.7.1)

This requirement relates to minimising the impact of any audit and checking activities upon business operations. The scope and timing of any audits or tests should be agreed in advance with the relevant people. Access to data for audit / test purposes should generally only be required on a read-only basis. Any tests that require processing to be conducted should be agreed first and (where possible) conducted outside of business hours. Such tests should also be logged to provide a trail in case of any issues occurring as a result of the tests.

This article on Annex A 8 Technological Controls is based on an extract from the Guide Book in the Qudos ISO 27001 InfoSec Toolkit - exclusively available as an integrated component of Qudos 3 software.