ISO 27001 Information Security - Annex A 8 Technological Controls

A8 - Technological controls
ISO 27001 Annex A8 - Technological controls

31st May 2023 - ISO 27001 Information Security in plain English - Post #21 in the series.

ISO 27001 - Annex A 8 Technological Controls

Something that sets ISO 27001 apart from all the other ISO management system standards is its Annex A. This is a table of controls that are derived from the detailed guidelines published in ISO 27002 (which provides a reference and guidance on information security).

What is a control? A control is defined by ISO as a measure that modifies or maintains risk. Those measures might include policies, processes, practices, devices or other conditions or actions.

There are 93 controls specified in Annex A, and they are spread over 4 categories - each of which deals with a different facet of information security. Annex A is actually longer than the regular clauses.

In recent articles in this series, we have looked at the other 3 categories. First, there was Annex A 5 Organizational controls. This was followed by Annex A 6 People controls  and the Annex A 7 Physical controls. The final category is this one - A 8 Technological controls. In case you are wondering why that first category was numbered as 5, it's to maintain numbering compatibility with ISO 27002.  That is a very handy reference standard for determining and implementing risk treatment controls in an ISMS.

So, this article is about A 8 Technological controls. The objective of this category is to apply and manage technological controls on information held by the organization. For the convenience of those looking to update their ISMS from the previous version of ISO 27001, we have included the relevant control numbers from that standard in brackets. Here goes...

Find out about Qudos 3 IMS software

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.

That concludes our brief introduction to ISO 27001 Annex A 8 Technological Controls. We will shortly be providing a recap of the article series and subsequent articles will take a deeper dive into some of the key topics in information security.

Click the LinkedIn Follow button below to receive notification of releases.

There's nothing like word of mouth to share creative content. So, if you found this blog informative, please share it with a colleague or business associate.

About the series 'ISO 27001 Information Security in plain English'

This blog post is part of a series where we will work through all the clauses and controls in ISO 27001. A great starting point for developing your ISMS.

This blog series began with an introductory webinar. A copy of the slide deck is available for you here:

Qudos_ISO_27001 Information_Security_in_plain_English (PDF)

Now updated for the latest version of the standard - ISO 27001:2022.

Ready to start your journey to ISO 27001?

The first step to commencing a management system based on ISO 27001 is to conduct a Gap Analysis. We can provide a qualified, experience certification auditor to perform a professional Gap Analysis service for you.

Contact us today to discuss your needs!