ISO27002 explained, part 3

This article describes the set of controls from ISO 27001:2013. There is a new version of the standard, ISO 27001:2022 with a new set of controls. Please check the following articles to learn about these controls:

• A5 organisational controls
• A6 people controls
• A7 physical controls
• A8 technological controles

The article is part three of a series of four articles explaining ISO 27002 and the ISO 27001 statement of applicability. The article series briefly explain each control that is mentioned in these standards. The explanation is based on ISO 27002.

—————–Article 1—————–

• Information Security Policies  A5
• Organization of Information Security A6
• Human Resource Security A7
• Asset Management A8

—————–Article 2—————-

• Access Control A9
• Cryptography A10
• Physical and environmental security A11

—————–Article 3—————– (this article)

• Operation Security A12
• Communication security A13
• System aquisition, development and maintenance A14

—————–Article 4—————–

• Supplier relationships A15
• Information security incident management A16
• Information security aspects of business continuity management A17
• Compliance A18

Should these articles pique your interest in ISO27001 then it might be good to know that ICT Institute also provides both an ISO27001 introduction course and a full ISO27001 Lead Auditor course.

Operations security

Documented operating procedures
Procedures for the operating of equipment should be documented and made available to those using the equipment. From the simple procedure of computer use (from start to shut-down) to the use of more complicated equipment there should be a guide on how to safely and correctly operate it. Due to their importance, the procedures should be treated as formal documents, meaning that any changes should be approved by management.

Change management
Any changes to and inside the organization that may affect the information security must be controlled and approved by management. Such changes can, for example, be the use of a new system or change in an important business process. For audit purposes, a changelog should be kept.

Capacity management
Capacity management actually involves quite a big part of an organization. It is vital to know how much capacity a system, human resources, offices, and facilities have, and how this is expected to change. Overcapacity of any kind can result in unpleasant or even dangerous situations, so current capacity use and change on the short and long basis should be controlled well.

Separation of development, testing and operational environments
Software and hardware exist in different stages on the work floor. It can be operational, meaning that it is in actual use by the organization. Software and hardware can also be in development, for example to make changes or improve the operational soft- and hardware or to create something entirely new. Before newly developed soft and hardware can become operational, it needs to be tested. By separating development and testing from the operational environment, one can prevent making accidental or deliberate changes to the operational environment that can negatively influence the organization.

Controls against malware
Organizations should have controls in place to detect, prevent, and recover from malware attacks. Since humans are often still the weakest link in information security, it is important to make all employees aware of the dangers of malware. They should be instructed how to work safely and keep malware out.

Information backup
A backup policy is a well-known information security measure, but what organizations often forget is that those backups need to be tested as well. A proper procedure for backing up information, software, and system images should be in place, and those backups need to be checked for completeness and whether they actually work. Due to their importance, backups need to be well secured and are best encrypted.

Event logging
To keep a good overview of what happens in an organization, event logs should be created. Most electronic devices can create logs of all user activity, and with that capture any faults, abnormalities, and security incidents. These logs can be inspected during regular checks and audits, but should retain an appropriate level of privacy.

Protection of log information
Since logs can expose any malicious user activity or system failure, they are vital in any (security) incident research. For this reason, logs should be properly protected against tampering and destruction. A good way to retain the integrity of logs is to automatically back them up to a location with extreme access controls and requirements.

Administrator and operator logs
Privileged accounts such as admin or operator accounts may have access to logs, so it is important to restrict their access to the logs of their own activity. To retain the integrity of privileged account logs, another logging system that cannot be accessed by the privileged individuals can also be put in place.

Clock synchronization
A single reference time for all information processing systems should be used. This way, activity can be accurately tracked through multiple systems which is vital for log audits. Management should document how the reference time is chosen and how synchronization is done.

Installation of software on operational systems
Installation of software on operational systems should be controlled. There should be a documented procedure of how software is checked before installation, and who installs/updates/deletes the software and how. Installing, updating, or deleting software without assessing the impact on the operational environment may have negative outcomes.

Management of technical vulnerabilities
Since it is near impossible to have a system run without any technical vulnerabilities, there should be a proper procedure for discovering them, determining the organization’s exposure to them, and how to take what measures. Having a complete overview of all assets, as described in the second chapter, is essential for determining where things can go wrong.

Restrictions on software installation
Software installed by normal personnel cannot usually be easily controlled, and should therefore be capture in a policy. Malicious or badly secured software installed by employees can put internal systems and information at risk. A good way of preventing this is to restrict the access of users so they cannot install software themselves, and have IT install additional software when requested and after approval.

Information systems audit controls
Audits might require deep access to a lot of information, which should not disrupt the day to day activities of personnel. To ensure a smooth audit, required access and scope should be approved by management beforehand, and auditors should be given read-only access.

Communications security

Network controls
All networks in an organization should be controlled. To protect information in systems, there should be a proper overview of all networks and how they are protected. Examples of such protection measures are the separation of networks, authentication of systems on the networks and systems should not have access to a whole network if not needed.

Security of network services
Service agreements need to be established for all networks, no matter whether the service is provided in-house or from outside. These agreements should state what security mechanisms are in place, what the service levels are, and any requirements set up by management. The service provider is responsible for the fulfilling of all (reasonable) demands.

Segregation in networks
A good way to manage networks and lower the risk of unauthorized access is segregating networks. This can be done by distinguishing between different groups of network access, and creating different networks or parts of a network for those groups. External partners have, for example, no need and reason to access the printer network or internal management document storage.

Information transfer policies and procedures
Information is shared inside and outside the organization. There should be a protocol for all types of information sharing, including digital documents, physical documents, video, but also by word of mouth. Clear rules on how information can be safely shared helps lower the risk of information contamination and leaks.

Agreements on information transfer
Information that is shared between the organization and external parties needs to be preceded by an information transfer agreement. This way, the source, content, confidentiality, transfer medium, and destination of the information transfer is known by and agreed upon by both parties.

Electronic messaging
Business communication often happens by means of electronic messaging. Organizations are advised to have an overview of approved types of electronic messaging and should document how these are protected.

Confidentiality or non-disclosure agreements
There should be a clear and well documented policy for confidentiality or non-disclosure agreements. Different organizations might have different requirements for keeping information confidential, so it is important for organizations to identify, formalize, and update those requirements.

System acquisition, development and maintenance

Information security requirements analysis and specification
Information systems have different security requirements attached to them, stemming from business requirements, legal requirements, and compliance with other standards or regulations. These requirements should be documented and implemented in new information systems or updates to current ones.

Securing application services on public networks
Public wifi networks should not be trusted, since that are can be controlled by hackers. One should not use such networks, unless one uses a Virtual Private Network (VPN) software.

Protecting application services transactions
Transactions are popular targets for ill-willing individuals, and any information involved in them should be protected against unauthorized reception, re-routing, duplication, or alteration. Essential basic steps for safe transactions are an encrypted communication path, and electronic signatures of both sides.

Secure development policy
Information security starts with safe systems. A system cannot be safe if information security has not been kept in mind during development. Rules for safe software and systems development should be documented by an organization, and implemented during the development of new software and systems.

System change control procedures
Even in the development lifecycle of systems, change should be formally documented to ensure integrity. The importance of separating the developmental environment from the operational environment has been discussed in a previous subchapter called “Separation of development, testing and operational environments”. Organizations should be apprehensive with automatic update to critical systems, as they might cause the system to fail.

Technical review of applications after operating platform changes
After a change, operational systems should be reviewed on their performance and security. The change might have negatively influenced the system or overall information security and/or performance. Making this a company policy ensures the process is executed consistently and can prevent unnecessary work interruption and risks.

Restrictions on changes to software packages
Software packages require updates every once in a while, which can be minor or major. A procedure for updating software should be in place, where the updater critically assesses the necessity and impact of the update. Patches should only be applied when tested and considered useful.

Secure system engineering principles
Similar to a previous subchapter called “Secure development policy”, the principles on how the engineer secure systems need to be formalized and applied to any information system development. It is important to implement security in all system layers and anticipate what risks the system might have.

Secure development environment
In order to be able to develop new software and systems safely, management needs to create a secure development environment. This includes technical, organizational, and human resource efforts. Different development environments may require different levels of security, to which the processes and measures in those environments should be adapted. Examples of a heightened security level are constant monitoring of the activities in and access to the environment.

Outsourced development
Not all development can take place inhouse, so organizations need to establish procedures and closely keep an eye on said external development. A thorough agreement should be set up prior to the collaboration, the requirements should be crystal clear, the organization should be able to audit the development process, and deliverables tested before acceptance.

System security testing
During development, the security of the new/updated system should be thoroughly tested. Testing is done best by using realistic test-inputs to the system, and critically assessing the output. Security testing and acceptance testing should be segregated, even for in-house products. The more critical a system is, the more thorough security testing should be.

System acceptance testing
There should be a well-documented and strictly applied procedure for the acceptance testing of new/updated systems. The testing itself should be done independently of development and check on compliance to development and organizational security requirements.

Protection of test data
As discussed in a previous subchapter, testing should happen in a realistic situation with realistic test data. To mirror real world application, anonymized and non-sensitive operational data should be used for testing and authenticated before use. Testing should be well documented and logged for auditing, and any operational test data has to be removed after the testing is complete.

Image credit: @kellybrito via Unsplash