Continuing with the article published Analysis of the People and Physical Controls of ISO/IEC 27002:2022 – Part 2, in this article we will present an analysis of the technological controls included in ISO/IEC 27002:2022.
End User Devices (8.1)
This control indicates that end user devices are all those from which information can be accessed, processed, or stored. They include computers, smartphones, or tablets. An end user device policy should establish clear rules for management, including registration, physical protection, password and cryptographic protection, and responsible use. Responsible use includes controlling who has access to the device, software installation, regular operating system updates, and performing device backups. An organization may require a specific policy for the use of personal devices in order to avoid conflicts and the associated information security risks.
Privileged Access Rights (8.2)
This control indicates that the assignment of privileged or administrator access rights to users for accessing software components and systems should be done on a case-by-case basis and only when necessary. This means that there should be a clear policy determining when access rights may be granted and when they should expire or be revoked. When privileged access rights are granted, the user must 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 administrator access rights. These rights should not be used for everyday tasks, which should always be performed with standard user accounts. Privileged access should only be used when administrative tasks are being carried out.
Restriction of Access to Information (8.3)
This control indicates that access to information and other assets should be based on business needs, with access restricted to specific users. Information should not be accessible to anonymous users to prevent untraceable and unauthorized access. This is important to preserve the confidentiality of information, control its use, and prevent unauthorized or accidental modification and distribution.
Access to Source Code (8.4)
This control indicates that source code should be kept secure to prevent unwanted changes and maintain code confidentiality. Employees' roles and business needs determine whether they have read and write access. Restricting access to read-only for most staff helps protect code integrity. For the same reason, developers should use development tools that control activities rather than having direct access to the source code repository.
The use of development and version control tools allows changes to be monitored and code integrity to be maintained.
Secure Authentication (8.5)
This control indicates that secure authentication helps ensure that a user is who they claim to be. The level of authentication required should be proportional to the sensitivity 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 forms of multi-factor authentication. Login screens should display the minimum amount of information possible in order to avoid providing assistance to unauthorized individuals. All login attempts should be logged, whether successful or unsuccessful, in order to identify attacks or unauthorized use.
Capacity Management (8.6)
This control indicates that capacity management covers all human resources, office space, and other facilities, not only information processing and storage. Future needs should be considered in business and security planning, especially if acquiring assets takes a long time. Cloud computing often allows flexible capacity management. Physical facilities and personnel, on the other hand, may require more strategic planning. Optimizing the physical and digital storage of information, deleting old data, and optimizing batch processing and applications will lead to more efficient use of existing capacity.
Protection Against Malware (8.7)
This control indicates that malware detection programs (for example, antivirus software) provide some protection, but they are not the only means of protection. Protection also includes information security awareness, access controls, and change management controls to prevent malware from being installed or causing problems. As a first line of defense, malware detection software should be installed and regularly updated. However, a policy preventing unauthorized software installation, the use of suspicious websites, downloading files from remote sources, and identifying vulnerabilities are equally important. Finally, security risks can be reduced by actively planning for malicious application attacks, such as applications that hijack data. Staying informed about new malware, isolating critical environments, and developing business continuity plans in the event of an attack will help maintain business continuity if an attack occurs.
Technical Vulnerability Management (8.8)
This control indicates that technical vulnerability management can be divided into three categories: identification, assessment, and action. To identify vulnerabilities, assets such as devices and applications must be inventoried with information about the supplier, version, deployment status, responsible owner, end of vendor support lifecycle, and any other information that supports vulnerability management for these elements. The supplier may provide vulnerability information, but the owner should identify additional resources that monitor and publish information about vulnerabilities and methods used to identify vulnerabilities, such as penetration testing. Once a vulnerability has been identified, it is necessary to assess the risk and urgency, as well as the potential risks of applying an update or patch. Updates are often used to address vulnerabilities, but they do not always adequately solve the problem and may introduce new issues. If no update is available or the update is considered unsuitable, measures such as workarounds, network isolation, and increased monitoring may be sufficient to mitigate the risk.
Configuration Management (8.9)
This is a control that indicates that software, hardware, services, and networks should be configured to operate correctly with the security settings deemed necessary to protect the organization. Configuration should be based on business needs and known threats. As with all secure systems, privileged access should be restricted and unnecessary functions disabled. Configuration changes should follow the change management procedure and be fully approved and documented. It is highly recommended to define specific configuration guides that clearly and precisely indicate the parameters to be configured on different devices and applications.
Information Deletion (8.10)
This is a control that indicates that information should not be retained longer than necessary in order to reduce information security exposure risk, optimize resource usage, and comply with personal data protection laws such as the GDPR. An approved secure deletion application should be used to ensure permanent deletion, and certified destruction providers may be employed for physical media. The organization should verify that the deletion method used by cloud service providers is adequate. Maintaining a record of deletion is useful in the event of a data breach.
Data Masking (8.11)
This is a control that indicates that only the minimum amount of data necessary for a task should appear in search results. To achieve this, personal data should be masked (or anonymized or pseudonymized) to conceal the identity of the data subjects. This may be required by personal data protection laws such as the GDPR.
Data Leakage Prevention (8.12)
This is a control that indicates that monitoring and detecting unauthorized attempts to disclose or extract data is key to prevention. When an attempt is detected, measures such as email quarantine or access blocking can be activated. Other methods, such as clear policies and training on how to upload, share, or access data, should be used to address the risk of data leakage by personnel.
Information Backup (8.13)
This control indicates that the organization needs a specific backup policy covering the method, frequency, storage, and testing. When developing the policy, the organization should consider elements such as ensuring the integrity of backups and restorations, business backup requirements, where and how backups are stored, and how the backup system is tested. The backup system should be considered part of the business continuity plans and be suitable for meeting continuity requirements.
Redundancy of Information Processing Facilities (8.14)
This control indicates that the organization needs a system architecture that is sufficient to meet business availability requirements. Redundancy at different levels ensures availability by providing backup capacity in the event of system failure and often requires duplicated systems, such as power supplies. Adequate redundancy that can be brought into operation when necessary constitutes an important part of business continuity planning and should be tested regularly.
Logging (8.15)
This control indicates that logging records events, generates evidence, ensures the integrity of recorded information, can help prevent unauthorized access, identifies information security events, and supports investigations. A logging plan should identify what information must be recorded (for example, user ID) and may cover events such as system access attempts, changes, transactions, or file access, among others. Logs should be protected, including from privileged users, so that they cannot be deleted or modified. Logs should be monitored and analyzed to detect patterns or incidents that may constitute information security incidents.
Monitoring Activities (8.16)
This is a control that indicates that the aim of monitoring is to detect abnormal behavior and identify potential information security incidents. The monitoring system may cover network traffic, system access, logs, and resource usage. Monitoring can help identify system failures or bottlenecks, activity associated with malicious applications, unauthorized access, unusual behavior, and attacks such as denial-of-service attacks.
Clock Synchronization (8.17)
This control indicates that clock synchronization is important to ensure that monitoring information is recorded reliably in the event of an information security incident. Local systems should use a time protocol (NTP) to ensure clock synchronization across different devices against a trusted source. Cloud service providers typically handle synchronization for logging purposes. However, local clocks may not be perfectly synchronized with the cloud provider's clock. In this case, the difference should be recorded and controlled to ensure proper correlation of events occurring in different zones.
Use of Privileged Utility Programs (8.18)
This control indicates that a privileged utility may be capable of overriding system and application controls. Therefore, the use of and access to utility programs should be strictly restricted, with unique user identification and logging of their use.
Installation of Software on Operational Systems (8.19)
This control indicates that software installation can introduce vulnerabilities into operating systems. To minimize this risk, software should only be installed by authorized persons. Software should come from reliable and well-maintained sources or be fully tested if developed internally. Previous versions should be retained and all changes recorded so that they can be rolled back if necessary, reducing the risk of introducing vulnerabilities into systems.
Network Controls (8.20)
This control indicates that networks should be sufficiently secure to protect the information passing through them. To keep them secure, they must be maintained, updated, and monitored, with the option of restricting both connections to authenticated devices and the traffic that may pass through the network. A method for isolating the network may be useful if the network suffers an attack.
Security of Network Services (8.21)
This control indicates that network security services range from providing a simple connection and bandwidth to complex services such as firewalls and intrusion detection systems. The level of security required will depend on business needs. Once the necessary security has been identified, it must be implemented and monitored. This is often handled by third parties providing network services. Access authorization procedures and means of access, such as VPNs, should be considered when configuring network security services.
Web Filtering (8.22)
This control indicates that not all Internet websites are harmless. Some contain illegal information and others distribute malware. Blocking the IP addresses of suspicious websites can reduce risks. However, not all malicious websites can be blocked, so filtering should be accompanied by rules and training on the appropriate and responsible use of the Internet.
Network Segregation (8.23)
This is a control that indicates that large networks can be divided into multiple domains. This means that different security levels can be applied to each domain, with limited access to different parts of the corporate network. Networks may be completely separated physically or digitally through logical networks. Wireless networks have no physical boundaries and should therefore be considered external connections until a gateway such as a VPN has been passed when accessing sensitive data.
Use of Cryptography (8.24)
This control indicates that the use of cryptography should be carefully managed, taking into account the level of protection required, key management, end-user device encryption, and how cryptography may affect content inspection (for example, inspection for malware). Key management requires a process for the generation, storage, archiving, recovery, distribution, withdrawal, and destruction of cryptographic keys.
Secure Development Life Cycle (8.25)
This control indicates that secure development covers the construction of services, architecture, software, and systems. A key aspect is the separation of development, testing (acceptance), and production environments with secure repositories for source code. Security should be considered from the specification and design phase, with control points integrated into the project plan and testing planned. Developers should also be familiar with secure coding guidelines and be able to prevent, identify, and correct vulnerabilities.
Application Security Requirements (8.26)
This control indicates that organizations should identify and specify application security requirements after determining them through a risk assessment. Requirements are determined by the security classification level of the information that passes through the application. Requirements may include access controls, protection level, encryption, input and output controls, logging, error message management, resilience against attacks, and legal requirements. Security requires special attention if the application performs information transactions or order and payment processing.
Secure Systems Architecture and Engineering Principles (8.27)
This control indicates that architecture and engineering principles ensure that systems are designed, implemented, and operated securely throughout their lifecycle. Analysis of secure system principles, such as which security controls are required and how they should be applied. Best practices, practical considerations of cost and complexity, and the way new functionality can be integrated into existing systems.
Secure Development (8.28)
This is a control that indicates that the practice of secure development helps ensure that code is written to minimize vulnerabilities. Secure development principles can be used to promote best practices and establish minimum standards within the organization. These should take into account real-world threats, the use of controlled development environments, and ensuring developer competence. Secure coding should also include update and maintenance management, particularly controlling who is responsible for maintaining code from external sources.
Security Testing in Development and Acceptance (8.29)
This control indicates that security testing should be an integral part of development. This includes checking operating system configurations (for example, firewalls), secure coding, and security functions (such as access controls). Testing should be planned, documented, and accompanied by criteria for determining acceptable results before moving to production environments.
Outsourced Development (8.30)
This control indicates that when development is outsourced, information security requirements should be communicated to and agreed by the outsourced developer and monitored by the outsourcing organization. It is important to note that usage licenses and intellectual property, testing, and contractual rights for auditing the outsourced development process are examples of security considerations that should be agreed between the parties.
Separation of Development, Testing, and Production Environments (8.31)
This control indicates that testing and development activities can cause unwanted changes or system failures, which could compromise the production environment if not properly protected. The degree of separation between testing and production environments will depend on the organization, but the environments should be separated and clearly labeled so that testing or actions such as compilation cannot take place in the production environment. Changes should be monitored, with careful control over who has access to each environment. No one should be able to make changes in both the test and production environments without prior review.
Change Management (8.32)
This control indicates that the confidentiality, availability, and integrity of information may be compromised when introducing a change in processes, a new infrastructure, or software, or when substantial changes are made to an existing one. A formal process of documentation, testing, quality control, and implementation can reduce risks. Test documentation and contingency plans are important in the period leading up to implementation, particularly to ensure that the new software or infrastructure does not negatively affect the production environment. Configuration guides and operating procedures may need to be modified after changes have been made.
Test Information (8.33)
This control indicates that there are two key considerations for test data: it must be sufficiently close to operational information to ensure reliable test results, but it must not contain confidential operational information. If sensitive information is to be used for testing, it should be protected, modified, or anonymized before use and should be deleted immediately after testing.
Protecting Information Systems During Audit Testing (8.34)
This control indicates that operational systems should not be unduly affected by audits or technical reviews. To avoid unnecessary disruption, 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.
Referencias
ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection — Information security controls, https://www.iso.org/standard/75652.html
ISO/IEC 27002:2013, Information technology — Security techniques — Code of practice for information security controls, https://www.iso.org/standard/54533.html