ISO 27001 – Annex A.12: Operations Security

What is the objective of Annex A.12.1?

Annex A.12.1 is about Operational Procedures and Responsibilities. The objective of this Annex A area is to ensure correct and secure operations of information processing facilities. It’s an important part of the information security management system (ISMS) especially if you’d like to achieve ISO 27001 certification. Lets understand those requirements and what they mean in a bit more depth now.

A.12.1.1 Documented Operating Procedures

Operating procedures must be documented and then made available to all users who need them. Documented operating procedures help to ensure consistent and effective operation of systems for new staff or changing resources, and can often be critical for disaster recovery, business continuity and for when staff availability is compromised. Where information systems are “cloud-based” traditional operational activities such as system start-up, shut-down, backup etc become less relevant and may often be outsourced to a cloud provider. In more traditional computing environments and architectures operating procedures are much more likely to be required.

It is important that documents are maintained in a correct and current state and should therefore be subject to formal change management and periodic review procedures – this is key, as the auditor will be specifically looking to see this.

We often get asked about how much detail is needed, and what areas of the business need to have documented procedures. Take a common sense approach. For example, if you have real staff stability, the implicit procedures are very well understood and resilience is in place across that resource pool, simple bullet points may be enough to form a checklist style documented procedure.

Similarly if procedures are evolving or regularly changing e.g. because of fast growth you want to have procedures that can be easily and quickly updated too. Again if lots of new resource is being added and the area has risk and complexity around it, then more depth to the procedures may be needed so it is unambiguous about what, when, how, who etc.

The areas of the business that need to be considered for documented procedures should be where your information assets are at risk through incorrect operation, which of course will be identified as part of the risk assessment in line with 6.1. That might include software development, IT management, through to financial accounting, customer management, consulting or manufacturing work etc depending on the nature of the business.

A.12.1.2 Change Management

The organisation, business procedures, information processing facilities and systems that affect information security need to be controlled. Properly controlled change management is essential in most environments to ensure that changes are appropriate, effective, properly authorised and carried out in such a manner as to minimise the opportunity for either malicious or accidental compromise. Change management applies across the organisation, its processes, information processing facilities, networks, systems, and applications.

Audit logs are required to provide evidence of the correct use of change procedures. The auditor will want to point out that change procedures do not have to be overly complicated, but need to be appropriate to the nature of change being considered. You might simply capture evidence of amendments and version control changes as you go, or operate much deeper more complex change management and include retraining and communications as well as have more significant investment and sign off processes.

A.12.1.3 Capacity Management

The use of resources must be monitored, tuned and projections made of future capacity requirements to ensure the required system performance to meet the business objectives. Capacity management typically looks at three primary types; Data storage capacity – (e.g. in database systems, file storage areas etc.); Processing power capacity – (e.g. adequate computational power to ensure timely processing operations.); and Communications capacity – (often referred to as “bandwidth” to ensure communications are made in a timely manner).

Capacity management also needs to be; Pro-active – for example, using capacity considerations as part of change management; Re-active – e.g. triggers and alerts for when capacity usage is reaching a critical point so that timely increases, temporary or permanent can be made.

A.12.1.4 Separation of Development, Testing & Operational Environments

Good policies for development, testing and operational environments would confirm they must be separated to reduce the risks of unauthorised access or changes to the operational environment. Keeping development, testing and live operational IT environments separate is good practice as this helps with segregation of duties and unauthorised access to the live environment & data. Changes and new developments should be thoroughly tested in a separate area before being deployed to the live operating environment.

Ideally development personnel should not have access to the live environment but this may not be possible, especially in small organisations. Once separated, it is important to check that testers are not accidentally (or deliberately) using test environments as live. The auditor will be checking to see that development, test and live environments are separated and that there are formal procedures including appropriate levels of authorisation for moving changes and developments from one environment to another.

What is the objective of Annex A.12.2?

Annex A.12.2 is about protection from malware. The objective here is to ensure that information and information processing facilities are protected against malware.

A.12.2.1 Controls Against Malware

Detection, prevention and recovery controls to protect against malware must be implemented, combined with the appropriate user awareness. This is a section about which most organisations have some level of awareness, understanding and implementation. However, malware protection can take a number of different forms aside from the obvious “anti-virus software”.

Other controls such as restrictions around the use of removable media or restrictions on the installation of software by users – helping to prevent the use of unauthorised software – are also valuable. Patching of known system and software vulnerabilities in a timely manner is also critical. Often viruses are designed to look for unpatched systems and software in which known vulnerabilities may reside. It is important that any malware protection is kept up to date, both in terms of relevant “signature files” and the software itself.

What is the objective of Annex A.12.3?

Annex A.12.3 is about backup. The objective is to protect against loss of data.

A.12.3.1 Information Backup

To protect the valuable information against loss, a good control describes how backup copies of information, software and system images shall be taken and tested regularly in accordance with an agreed backup policy.

Backup regimes need to be designed according to business requirements and risk levels relating to unavailability of information so it is important to ensure that such regimes do support actual needs rather than simply being “we do backups”. When backups are taken the information should be protected at the same level as the live data by minimum and should be stored away from the live environment to minimise the risk of a single compromise taking down both the live environment and the backups.

Regular testing of backups is crucial to ensure that restorations will be successful and achieved in a timely manner. Monitoring and recording of backups should be implemented to ensure that they are occurring in line with the backup policy. Smart auditors will want to see reports against failed backups and tests done to ensure they are working as expected. Backup policies need to be considered around what, where from and where to, who, when – taking into account office and homeworkers, mobile etc where there are considerations about mobile and removal storage backups that have increased risks in the event of loss that might be addressed through encryption or other controls.

What is the objective of Annex A.12.4?

Annex A.12.4 is about logging and monitoring. The objective in this Annex A area is to record events and generate evidence.

A.12.4.1 Event Logging

Event logs recording user activities, exceptions, faults and information security events need to be produced, kept and reviewed regularly. Logging and monitoring mechanisms form an important part of a “defence-in-depth” strategy for security management by providing both detective and investigation capabilities. Event logs of all types, e.g. system logs, access control logs, etc., may be required, especially regarding incident management and auditing. Logs will often need to store potentially huge amounts of information so it is important that capacity considerations are made.

A.12.4.2 Protection of Log Information

Logging facilities and log information must be protected against tampering and unauthorised access. It is also critical to ensure logs are stored in a secure and tamper-proof manner so that any evidence derived from them can be evidenced in a provable manner. This is especially important in any form of legal proceedings relating to evidence from the log. Because logs potentially contain large amounts of sensitive data, it is important that they are protected and secured adequately. It is also important to consider that if the logs contain personally identifiable information, which they almost certainly will, such as user ID and the actions performed by that UID, they are likely to fall under the requirements of data protection and privacy legislation including data retention.

A.12.4.3 Administrator & Operator Logs

A good control describes how any system administrator and system operator activities need to be logged and the logs protected and regularly reviewed. Special consideration should be given to greater levels of logging for privileged accounts such as system administrators and operators.

A.12.4.4 Clock Synchronisation

The clocks of all relevant information processing systems within an organisation or security domain must be synchronised to a single reference time source. System clock synchronisation is important, especially when evidencing events as part of an investigation or legal proceeding as it is often impossible or very difficult to prove “cause & effect” if clocks are not synchronised correctly. The auditor will be paying special attention to ensure that this has been done.

What is the objective of Annex A.12.5?

Annex A.12.5 is about control of operational software. The objective in this Annex A area is to ensure the integrity of operational systems.

A.12.5.1 Installation of Software on Operational Systems

Procedures must be implemented to control the installation of software on operational systems. As with any security related control it is important that the installation of software on operational systems is formally controlled. Whilst this may not always be possible, especially in small organisations, the principle remains true. Issues related to the inappropriate installation or change of software on operational systems can include; Malware infected software being installed; Capacity issues; or Software that can enable malicious insider activity being installed (e.g. hacking tools). Beyond restricting and limiting the installation of software on operational systems, it is also important to formally control the legitimate installation.

It is good practice to ensure wherever possible that, for example; Formal change management has taken place, including appropriate levels of authorisation; Roll-back procedures are in place; and Previous versions of software and change histories are kept securely. Each change should consider both the business requirements and the security requirements and risks in line with formal change management procedures. The auditor will expect to see records of software changes and installations that have been kept, which they will want to inspect/sample.

What is the objective of Annex A.12.6?

Annex A.12.6 is about technical vulnerability management. The objective in this Annex A area is to prevent exploitation of technical vulnerabilities.

A.12.6.1 Management of Technical Vulnerabilities

Information about technical vulnerabilities of information systems being used must be obtained in a timely fashion, the organisations exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk. Any vulnerability is a weakness in security protection and must be dealt with effectively and efficiently where risk levels are unacceptable. Technical vulnerabilities have been at the heart of many large security breaches reported in the media (and those that aren’t!) and so it is essential that formal managed process are in place at an adequate and proportionate level.

There needs to be a balance between the security imperative of implementing vulnerability patches as quickly as possible and the security imperative of testing patches sufficiently to ensure continued availability and integrity of systems and the minimisation of incompatibilities. Awareness can also play an important part and it is therefore sensible to have a communications strategy relating to updating users when vulnerabilities exist that can be managed to a degree through user behaviours. The auditor will expect to see that processes for identifying and detecting vulnerabilities are in place, especially on critical systems or those processing or storing sensitive or classified information.

A.12.6.2 Restrictions on Software Installation

Rules governing the installation of software by users need to be established and implemented. This control relates to restricting the ability of users to install software, especially on local devices (workstations, laptops etc). Installation of software by users raises a number of threats and vulnerabilities including the threat of introduction of malware and the potential breach of software licensing/IPR laws. Ideally users would not be able to install any software on organisational equipment, however, there may be business or practicality reasons why this is not possible.

Where full restriction is not possible, it is good practice to “white-list” what software may be installed. The auditor will be checking to see what restrictions have been placed on the installation of software by users. Then, where full restriction is not implemented, they will want to see evidence that the risks have been fully assessed and where possible, complementary controls such as regular software audits have been implemented and are being regularly used.

What is the objective of Annex A.12.7?

Annex A.12.7 is about information systems and audit considerations. The objective in this Annex A area is to minimise the impact of audit activities on operational systems.

A.12.7.1 Information Systems Audit Controls

Audit requirements and activities involving verification of operational systems need to be carefully planned and agreed on to minimise disruptions to the business processes. Whenever carrying out tests and audit activities (e.g. vulnerability scans, penetration tests etc) on operational systems, consideration needs to be given to ensure that operations are not negatively impacted. Additionally, the scope and depth of testing must be defined. Any such auditing or testing of operational systems must be through a formal and appropriately authorised process. The auditor will be looking for evidence that the scheduling of tests and the level of testing is agreed and authorised through a formal process.