Annex A represents the series of controls and objectives needed to implement ISO 27001 ISMS. Annex A:12 is all about the 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 is about Operational Procedures and Responsibilities. The objective of this Annex A area is to ensure correct and secure operations of information processing facilities.
Annex A:12.1 Operational Procedures and responsibilities
The objective of this control to ensure that correct and secure operations of informations facilities are protected.
Annex A:12.1.1 Documented procedures operating
Documented operating procedures help to ensure an effective operations systems. It is important that are documents are maintained in a correct manner to avoid it’s consequential loss to remove obstacles from the operations systems for new staff or changing resources. For the cloud-based services, it is important to maintain all documents on cloud-based services and accessible to each staff member who need them. This comes under the availability of resources under ISO 27001.
Annex A:12.1.2 Change Management
All the threats that could develop in an organization, business procedures, information processing facilities and systems that affect information security should be controlled. With the changes, you can simply capture the evidence of amendments that were changed. Formal management responsibilities and procedures should be in place to ensure satisfactory control of all changes. When changes are made, an audit log containing all relevant information should be retained.
Annex A:12.1.3 Capacity management
ISO 27001 Control requires he management should have the capacity to understand these procedures. It also requires that the procedures that must be followed check system performances. 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 plans 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 organizational, 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 are therefore desirable to reduce the risk of accidental change or unauthorized access to operational software and business data
The following items should be considered:
- Sensitive data should not be copied into the testing system environment unless equivalent controls are provided for the testing system;
- 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 Objective
Malware these days are the 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 adequate management team. For e:g: Installing and regularly updating malware and repair software as precautionary or routine test for scanning computers and media.
Implementing malware information verification procedures to ensure the accuracy and information quality of advisory bulletins Creating a formal policy defining the powers of authorized act, can spare a business from Malware.
The following guidance should be considered:
- establishing a formal policy prohibiting the use of unauthorized software
- implementing controls that prevent or detect the use of unauthorized software (e.g. application whitelisting)
- implementing controls that 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 either from or via external networks or on any other medium, indicating what protective measures should be taken;
- reducing vulnerabilities that could be exploited by malware. 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 at a distance, if there is certain danger of disaster.
“By failing to prepare, you are preparing to fail”
When designing a backup plan. the following items should be taken into consideration:
- accurate and complete records of the 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 organization, the security requirements of the information involved and the criticality of the information to the continued operation of the organization;
- 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
A.12.4.1 Event Logging
Event logs can contain sensitive data and personally identifiable information. Appropriate privacy protection measures should be taken. Where possible, system administrators should not have permission to erase or de-activate logs of their own activities. All the organization record the activities in event logging must include:
- IDs of User;
- Activities of the system;
- successful and unsuccessful data records and other attempts to access resources;
- system configuration alterations;
- utilization 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 purposes, the copying of appropriate message types automatically to a second log, or the use of suitable system utilities or audit tools to perform file interrogation and rationalization should be considered. System logs need to be protected, because if the data can be modified or data in them deleted, their ‘existence may create a false sense of security. Real-time copying of logs to a system outside the control of a system administrator or operator can be used to safeguard logs.
Annex A:12.4.3 Administrator and Operator Logs
There must be an administrator to process the key entries to specific entry or any operational logs.The logs must have secured key for its private user only. The logs of the information processing facilities, must not be shared with anyone in the organisation. It is important to keep logs safe and reviewed to ensure the privileged users are kept accountable.
Annex A:12.4.4 Clock Synchronization
Documentation of external and internal time representation requirements and synchronization. These requirements could be legal or regulatory governed by technical authorities. System logs generated by servers and other various network apparatus can create data is in vast quantities, and sooner or later, attempts at managing such information in an off-the-cuff fashion are no longer viable. Effective logging allows us to reach back in time to identify events, interactions, and changes that may have relevance to the security of information resources. A lack of logs often means that we lose the ability to investigate events (e.g. anomalies, unauthorized access attempts, excessive resource use) and perform root cause analysis to determine causation.
Annex A:12.5 Control of Operational Software
Its 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 such investigations and damage the credibility of such evidence.
Annex A:12.5.1 Installation of Software on Operational Systems
- Permissions required from management to upgrade softwares on the computer systems.
- Only approved executable code and non-developed code or compilers should exist in operating systems;
- User-friendly functions for easy testings;
- Ensure that each of the corresponding program source libraries has been 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) within the organization responsible for the software.
The following controls guides management to process for technical vulnerabilities:
- Switching off vulnerability related services or capabilities;
- Adapting or adding network firewalls;
- Enhanced surveillance for real attacks
- Increase vulnerability awareness;
A.12.6.2 Restrictions on Software Installation
The organization should deﬁne and enforce a strict policy on which types of software users may install. It’s the management and ICT’s responsibility to identify the risks and make strategies to prevent the same. Taking into account the role of the users concerned, these privileges should be given.
Annex A:12.7 Information Systems Audit Considerations
It is highly important that audit standards for access to systems and data should be negotiated with appropriate management. A technical Audit team must updated and control the information if there is any changes to the technical networks.
No other user can access and edit these policies. The criteria for adding any new clause or change must be acted by ICT Lead Auditor.