ISO 27001 controls: What is Annex A:12?

Annex A represents the series of controls and objectives needed to implement ISO 27001 ISMS. Annex A:12 is all about Operations Security. Its main objective is to ensure the correct and secure operations of information processing facilities. Today, we are going to discuss a highly essential topic in ISO 27001 Controls, Annex A:12.

Annex A:12 Operations security

Annex A.12 focuses on operational procedures and responsibilities. The objective of this Annex A area is to ensure the correct and secure operations of information processing facilities.

Annex A:12.1 Operational Procedures and Responsibilities

The objective of this control is to ensure that the correct and secure operations of information facilities are protected.

Annex A:12.1.1 Documented Procedures Operating

Documented operating procedures help to ensure an effective operations system. It is important that documents are maintained correctly to avoid consequential loss and remove obstacles from the operations system for new staff or changing resources. For cloud-based services, it is important to maintain all documents on cloud-based services and ensure they are accessible to each staff member who needs them. This comes under the availability of resources under ISO 27001.

Annex A:12.1.2 Change Management

All threats that could develop in an organisation, business procedures, information processing facilities, and systems that affect information security should be controlled. Changes should be documented to capture evidence of amendments. Formal management responsibilities and procedures should be in place to ensure satisfactory control of all changes. An audit log containing all relevant information should be retained when changes are made.

Annex A:12.1.3 Capacity Management

ISO 27001 control requires that management should have the capacity to understand these procedures. It also requires procedures to check system performance. Managers should use this information to identify and avoid potential bottlenecks and dependence on key personnel that might present a threat to system security or services and plan appropriate action.

Annex A:12.1.4 Separation of Development, Testing, and Operational Environments

It is important to define and enforce the degree of separation between organisational, testing, and development environments needed to avoid operational problems. Development and testing activities may cause unintended changes to software or information if they share the same computing environment. Separating development, testing, and operational environments is desirable to reduce the risk of accidental change or unauthorised access to operational software and business data.

Consider the following:

• Sensitive data should not be copied into the testing system environment unless equivalent controls are provided.
• Development and operational software should run on different systems or computer processors and in different domains or directories.
• Other than in exceptional circumstances, testing should not be done on operational systems.

Annex A:12.2 Protection from Malware

Malware is a major attack vector on businesses. To protect operational information, malware protection should be supported by malware detection. The malware protection procedures must provide guidance to the management team, such as installing and regularly updating malware and repair software and conducting routine tests for scanning computers and media.

Implementing malware information verification procedures ensures the accuracy and quality of advisory bulletins. Creating a formal policy defining the powers of authorised actions can protect a business from malware.

Consider the following guidance:

• Establishing a formal policy prohibiting the use of unauthorised software.
• Implementing controls to prevent or detect the use of unauthorised software (e.g. application whitelisting).
• Implementing controls to prevent or detect the use of known or suspected malicious websites (e.g. blacklisting).
• Establishing a formal policy to protect against risks associated with obtaining files and software from external networks or other media.
• Reducing vulnerabilities that malware could exploit, e.g. through technical vulnerability management.
• Conducting regular reviews of the software and data content of systems supporting critical business processes.

Annex A:12.3 Backup

Backups should be kept at a remote location to safeguard against disasters.

“By failing to prepare, you are preparing to fail.” – Benjamin Franklin

When designing a backup plan, consider the following:

• Accurate and complete records of backup copies and documented restoration procedures should be produced.
• The extent (e.g. full or differential backup) and frequency of backups should reflect the business requirements of the organisation, the security requirements of the information involved, and the criticality of the information to the organisation’s continued operation.
• Backup information should be given an appropriate level of physical and environmental protection consistent with the standards applied at the main site.

Annex A:12.4 Logging and Monitoring

Annex A:12.4.1 Event Logging

Event logs can contain sensitive data and personally identifiable information. Appropriate privacy protection measures should be taken. System administrators should not have permission to erase or deactivate logs of their activities. Event logs should include:

• User IDs
• System activities
• Successful and unsuccessful data records and other attempts to access resources
• System configuration alterations
• Utilisation of privileges

Annex A:12.4.2 Protection of Log Information

System logs often contain a large volume of information, much of which is extraneous to information security monitoring. To help identify significant events for information security monitoring, consider copying appropriate message types automatically to a second log or using suitable system utilities or audit tools to perform file interrogation and rationalisation. System logs need protection, as modified or deleted data can create a false sense of security. Real-time copying of logs to a system outside the control of a system administrator or operator can safeguard logs.

Annex A:12.4.3 Administrator and Operator Logs

There must be an administrator to process key entries to specific entry or operational logs. The logs must have secured keys for private users only. Logs of information processing facilities must not be shared with anyone in the organisation. It is important to keep logs safe and reviewed to ensure privileged users are accountable.

Annex A:12.4.4 Clock Synchronisation

Documentation of external and internal time representation requirements and synchronisation is necessary. These requirements may be legally or regulatory governed by technical authorities. Effective logging allows organisations to reach back in time to identify events, interactions, and changes relevant to the security of information resources. A lack of logs often means losing the ability to investigate events (e.g. anomalies, unauthorised access attempts, excessive resource use) and perform root cause analysis.

Annex A:12.5 Control of Operational Software

The objective is to ensure operating system integrity. The correct setting of computer clocks is important to ensure the accuracy of audit logs, which may be required for investigations or as evidence in legal or disciplinary cases. Inaccurate audit logs may hinder investigations and damage the credibility of such evidence.

Annex A:12.5.1 Installation of Software on Operational Systems

Management permission is required to upgrade software on computer systems. Only approved executable code and non-developed code or compilers should exist in operating systems. User-friendly functions for easy testing should be ensured, and corresponding program source libraries should be updated.

Annex A:12.6 Technical Vulnerability Management

Annex A:12.6.1 Management of Technical Vulnerabilities

Specific information needed to support technical vulnerability management includes the software vendor, version numbers, current state of deployment (e.g. what software is installed on what systems), and the person(s) responsible for the software within the organisation.

Controls for managing technical vulnerabilities include:

• Switching off vulnerability-related services or capabilities
• Adapting or adding network firewalls
• Enhanced surveillance for real attacks
• Increasing vulnerability awareness

Annex A:12.6.2 Restrictions on Software Installation

The organisation should define and enforce a strict policy on which types of software users may install. Management and ICT are responsible for identifying risks and developing prevention strategies. Privileges should be granted based on the role of the users concerned.

Annex A:12.7 Information Systems Audit Considerations

It is important that audit standards for access to systems and data are negotiated with appropriate management. A technical audit team must be updated and control the information if there are any changes to the technical networks.

No other user can access and edit these policies. Adding any new clause or change must be approved by the ICT Lead Auditor.

For more guidance and support on achieving ISO 27001 certification and understanding Annex A:12, contact Citation Certification today. We provide comprehensive support and training to help your organisation meet all necessary requirements and achieve compliance with ISO 27001 standards.