ISO/IEC 27002

ISO/IEC 27002:2013 – Information technology – Security techniques – Code of practice for information security controls (2nd edition)

Introduction

The ISO/IEC 27002 standard of information security is an internationally recognized standard of good practice. A lineage of more than 30 years can be traced back to the predecessors of BS 7799.

The standard’s scope

Information security management is an important topic that impacts all organizations, as are governance and risk management. ISO/IEC 27002 addresses information security, and as such could be applied to all kinds of organizations, including commercial enterprises of all sizes (from sole proprietorships to multi-national corporations), not-for-profits, charities, government departments and quasi-autonomous bodies. Despite the differences in the details of information risk and control requirements, there are many things in common. Most organizations must address the information risks associated with their employees and those associated with contractors, consultants, and third party suppliers.

The standard addresses information security, not just the security of IT/systems and networks, but of all information (such as data, documents, knowledge, and intellectual property).

ISO/IEC 27001: Relationship

Following ISO/IEC 27001, a Security Management System primarily focuses on managing a set of security controls. Annexe A of ISO/IEC 27001 summarizes the best practices for information security controls from ISO/IEC 27002. These controls may be considered good practices generally applicable. Organizations, however, might decide to implement systems based upon what they feel are appropriate for the risks they face, or may choose entirely different control suites. The majority of organizations that adopt ISO/IEC 27001 also use Annex A and ultimately ISO/IEC 27002 for their control framework, making the necessary modifications to suit those organization’s specific information risk concerns.

ISO/IEC 27002: Structure and format

ISO/IEC 27002 is a “code of practice” – not a standardized specification like ISO/IEC 27001 but a generic, advisory document nonetheless. Specifically, it recommends information security controls for threats to data confidentiality, integrity, and availability. Organizations adopting ISO/IEC 27002 assess information risks, define control objectives, and apply controls (or alternative methods of risk management) based on guidance from the standard.

Logically, the standard is grouped into related security controls. To prevent duplication and potential conflicts, many controls could have been presented in several sections rather than being randomly assigned to the same one, or even cross-referenced.

For example, the use of a card-access-control system in a computer room or storage vault is both an access control and physical control, requiring both technology and policies and procedures for management, administration, and use. There are some oddities as a result of this (such as section 6.2 on mobile devices and teleworking being part of the organizational framework of information security), but it is at least comprehensive. Despite its flaws, on the whole, it is a good effort.

ISO/IEC 27002: Content

The following table summarizes the 19 sections or 21 chapters of the standard if you include the unnumbered foreword and bibliography. Section sizes are roughly reflected in the blocks’ areas.

– Foreword
An overview of ISO/IEC JTC1/SC 27, the committee that wrote the standard, states that this “second edition replaces the previous one (ISO/IEC 27002:2005), which has been revised structurally and technically.”

– Section 0: Preface
This provides background to information security requirements, discusses three origins of information security requirements, emphasizes the need to interpret the standard in the context of the organization, mentions the lifecycle of information systems, and refers to ISO/IEC 27000 for the detailed structure and glossary.

– Section 1: Scope
Those tasked with selecting, implementing and managing information security can use the standard to make recommendations. It can or may not be used to support the ISMSs specified by ISO/IEC 27001.

– Section 2: Standards of reference
Among ISO/IEC 27000 standards, ISO/IEC 27000 is the only one considered necessary for ISO/IEC 27002. The standard, however, cites several other standards and has a bibliography.

– Section 3: Definitions and terms
In ISO/IEC 27000, all of the specialist terms and definitions are defined, and most of them apply to the entire ISO27k family.

– Section 4: This standard’s structure
Security control clauses- Fourteen of the 21 sections and chapters of the standard specify control objectives and controls. They are known as the ‘security control clauses’.Within every control clause, there is a standard format: one or more subsections setting forth a control objective and each of those objectives supporting one or more controls. The implementation guidance for each control as well as explanatory notes may be included. This level of detail accounts for the nearly 90 A4 page standard.

35 control objectives-
The ISO/IEC 27002 standard specifies 35 control objectives relating to the need to protect information confidentiality, integrity and availability, one for each ‘security control category’.
In essence, the control objectives represent the definition of a generic set of functional requirements for the organization’s information security management architecture.
The validity of control objectives is not seriously disputed by many professionals. Or, to put it another way, it would be difficult to claim an organization is not required to meet the stated control objectives. Despite this, some control objectives do not apply to every situation, and their generic wording is unlikely to capture the precise needs of every organization, especially given the very wide range of organizations and industries covered by the standard. It is for this reason that ISO/IEC 27001 requires the statement of applicability (SoA), which clearly explains what information security controls the organization needs and what their implementation status is.

114+++ controls-
The control objectives are each accompanied by one or more controls, resulting in 114 in all. It is, however, not accurate since the implementation guidance recommends many actual controls in detail.

As for the control objective of sub-section 9.4.2, “Secure log-on procedures”, for example, is supported by:

– The selection, implementation, and use of appropriate authentication techniques;
– Logging on without disclosing sensitive information;
– Validation of data entry;
– Defending against attacks that rely on brute-force credentials stuffing;
– Logging;
– Passwords should not be transmitted over the network in cleartext;
– Timeouts when a session is inactive;
– Time restrictions for access… as well as many other controls such as policies and procedures, training, compliance management, supervision, assurance, etc.

It is up to you whether you consider that to be one control or several controls. Even though ISO/IEC 27002 recommends hundreds of control objectives, some supports multiple control objectives, in other words, some controls have multiple purposes.

It is very clear from the wording throughout the standard that it is not a comprehensive set of controls. There may be circumstances in which an organization has slightly different or completely different objectives for information security control and needs to rely on other controls (often called ‘extended control sets’), in addition to or in place of those required by a given standard. Operating theatres in hospitals, for instance, are not the best places to play around with logins and passwords. Context plays a crucial role in information security and risk.

– Section 5: Information security policies
5.1 Information security management direction
A set of guidelines should be defined by management for the direction of information security and to give support to it. A top-level “information security policy” should be established following ISO/IEC 27001 section 5.2.

– Section 6: The organization of information security
6.1 Internal organization
Organizations should define roles and responsibilities for information security and assign them to individuals. To avoid conflicts of interest and prevent inappropriate activities, duties should be separated by roles and individuals when necessary. In information security matters, external authorities (such as CERTs and special interest groups) need to be contacted. All types of projects should be managed with information security in mind.

6.2 Use of mobile devices and teleworking
Mobile devices (such as laptops, tablet computers, wearable ICT devices, smartphones, USB gadgets and other kids’ toys) and teleworking (such as telecommuting, working from home, road warriors, and remote/virtual workstations) should be secured.

– Section 7: Human resource security
7.1 Before employment
When hiring permanent employees, contractors, or temporary staff (e.g., through job descriptions and pre-employment screening), information security responsibilities should be taken into account (e.g., terms of employment, policies that define employee responsibilities, etc.).

7.2 While employed
To avoid a breach of information security, managers need to be aware of and motivate employees and contractors to comply with security requirements. Information security incidents allegedly caused by employees must be handled by a formal disciplinary process.

7.3 Employment terminations and changes of employers
When a person leaves an organization or changes roles within it, security measures should be taken, including returning company information and equipment, updating access permissions, and reminding them of their ongoing legal obligations, such as privacy and intellectual property laws, contractual obligations, etc. plus any ethical considerations.

– Section 8: Asset management
8.1 Asset management
A security inventory of all information assets and the identification of their owners should be conducted. When people leave the organization, assets should be returned based on acceptable use policies.

8.2 Information classification
It is important to classify and label information by its owners based on the level of security that is required.

8.3 Media handling
Manage, control, move and dispose of information storage media in a manner that does not compromise the content of the information.

– Section 9: Access control
9.1 Access control requirements from a business perspective
The organizational policy and procedures for access control must be delineated. Restriction of network connections and access is necessary.

9.2 Management of user access
Users’ access rights should be managed from the time of registration until they are removed when not needed. This should include the management of passwords (also called “secret authentication information”) and regular reviews and updates of access rights.

9.3 User responsibilities
Educating users about the importance of maintaining effective access controls should include teaching them how to choose strong passwords and preserve their confidentiality.

9.4 Access control for systems and applications
It is advisable to restrict access to data according to a company’s access control policy, for example by using a secure login, password management, controlling access to privileged utilities, and restricting access to program source code.

– Section 10: Cryptography
10.1 Cryptographic controls
A policy on encryption, as well as authentication and integrity controls such as digital signatures and message authentication codes, and cryptographic key management, should be in place.

– Section 11: Safety and security in the physical and environmental realms
11.1 Secure areas
The premises, offices, rooms, delivery/loading areas, etc. should be protected from unauthorized access by physical perimeters and barriers, with physical entry controls and working procedures. For protection against fire, floods, earthquakes, bombs, etc., one should seek expert advice.

11.2 Equipment
Secure and maintain “equipment” (that is, ICT equipment) as well as supporting utilities (such as electricity and air conditioning). It is vital that equipment and data are not taken off-site unless this has been authorized, and that both on- and off-site protection measures are taken. Storage media must be destroyed before disposal or reuse. Equipment left unattended must be locked away and a clear desk policy must be followed.

– Section 12: Operational security
12.1 Operational procedures and responsibilities
Documenting IT operating responsibilities and procedures are important. The IT infrastructure and systems should be controlled whenever possible. The capacity and performance of a company should be managed. The development, testing, and operational phases of a system should be separated.

12.2 Malware protection
Malware controls, as well as user awareness, are needed.

12.3 Backup
Per the backup policy, an appropriate number of backups should be made.

12.4 Logging and monitoring
Logging and protecting information security events, system user activities, exceptions, and errors is essential. A synchronized clock is necessary.

12.5 Control over operational software
Control should be exercised over software installations on operational systems.

12.6 Management of technical vulnerabilities
Technical vulnerabilities should be addressed, and users should be able to install the software according to a set of rules.

12.7 Considerations when auditing an information system
Audits of IT systems should be planned and controlled to avoid adverse effects on production systems or unauthorized access to data.

– Section 13: Security of communications
13.1 Network security management
Segregation of networks and services is an effective way to secure them.

13.2 Information transfer
A policy, procedure, and agreement should govern information transfer to/from third parties (e.g., nondisclosure agreements).

– Section 14: Acquisition, development, and maintenance of systems
14.1 Information systems security requirements
In addition to web applications and transactions, security control requirements should be analyzed and specified.

14.2 Security in the development and support processes
A policy should be defined to govern secure software and system development. A change to a system (both an application and an operating system) needs to be controlled. It is ideal to not modify software packages and to follow secure system engineering principles. It’s important to secure the development environment and to control the work of outsourced developers. Acceptance criteria for system security should be defined that includes security aspects.

14.3 Test data
It is important to carefully select/generate and control test data.

– Section 15: Supplier relationships
15.1 Data security in supplier relationships
In the contract or agreement, there should be policies, procedures, awareness, and other steps included to protect sensitive information that is accessible by IT outsourcers and external vendors.

15.2 Managing supplier service delivery
External suppliers’ service delivery should be monitored and audited against the contract/agreement. Control should be exercised over service changes. [The same point can also be applied to services provided by internal suppliers.]

– Section 16: Management of information security incidents
16.1 Management and improvement of information security incidents
Information security events, incidents and flaws should be managed consistently and effectively (reported, assessed, responded to and learned from), and forensic evidence should be collected.

– Section 17: Business continuity management and information security
17.1 Information security continuity
As part of the organization’s business continuity management system, the continuity of information security should be planned, implemented, and reviewed.

17.2 Redundancies
To satisfy availability requirements, IT facilities should have sufficient redundancy.

– Section 18: Compliance
18.1 Adherence to legal and contractual requirements
Documenting the organization’s obligations to external authorities and other third parties in the areas of intellectual property, [business] records, privacy/personal can identifiable information, and cryptography is a requirement for information security.

18.2 Information security reviews
An independent review (audit) of a company’s information security plans should be carried out and reported to management. Additionally, managers should review employee and system compliance with security policies, procedures, etc. as well as initiate corrective actions where necessary.

Bibliography
At the end of this chapter is a reading list of 27 (!) ISO/IEC standards, over half of which are ISO27k standards.

ISO/IEC 27002 ISMS implementation guidelines

In the free ISO27k Toolkit, you can download planning guidelines and sample documents for ISMS implementation, and our ISO27k FAQ is a great resource for implementation tips.

Rather than focusing on security controls, ISO/IEC 27003 provides generic ISMS implementation guidance.

Several ‘sector-specific ISMS implementation guidelines are available, for example, the telecommunications sector uses ISO/IEC 27011, the healthcare industry ISO 27799, and the energy utilities sector ISO/IEC 27019.

The standard’s status

This was the second edition of ISO/IEC 27002 published in 2013, released simultaneously with ISO/IEC 27001.

Dropping the definition of “information asset” from ISO/IEC 27000 instead of truly bottoming out this issue may turn out to have been a tactical error. In 2014, an application corrigendum published by ISO/IEC 27002:2013 made minor changes to the wording, supposedly to clarify that “information” is referred to as an “asset”.

Following ISO/IEC procedure to the letter, a simple monodigit typo in section 14.2.8 caused a reference to point back to 14.1.9, instead of forward to 14.2.9 (which is the intended reference to the following section). It was attended by representatives of various national standards bodies who discussed and debated this dreadful situation at length and considerable expense to their taxpayers. What could be done about it? The Kuching plenary decided unanimously to simply replace “see 14.1.1 and 14.1.9€” with “see 14.1.1 and 14.2.9.” A remarkable initiative! The solution is unanimously agreed upon!
In 2015, a second corrigendum was published.

As of 2018, the standard is currently being revised to take into account changes such as the adoption of BYOD, cloud computing, virtualization, crypto-ransomware, social networking, pocket ICT, and Internet of Things, to name just a few.

There will be a radical change in the structure of the standard and the name “Information security controls”:

ISO IEC 27002 2021 structure 800

For the third edition, controls will be divided into these “themes”:

– Organizational controls : a catch-all category of controls with an unclear definition that doesn’t fit neatly into the remaining themes;
– People controls: controls that involve or affect people, for example, behaviour, activities, responsibilities, terms and conditions of employment, etc.;
– Physical controls: physical controls used to protect tangible [information] assets;
– Technological controls: controls that are based on technologies, such as information technology.

The third edition is at the stage where it is ready for international adoption, with a strong leadership team and wide consensus. In any case, it will take time to process *350 pages of comments on the DIS and then (if all goes well!) approve the FDIS version, so publication is unlikely until 2022.

After that, it is foreseen that ISO/IEC 27001 Annex A and other ISO/IEC 27002-based technical standards will need to be updated as needed.

Commentary

Among the most distinctive and innovative features of the original Shell policy, DTI Code of Practice, and BS 7799 is that they explicitly address information security, offering recommendations for securing information in any form, not only computer data, applications, networks, or technology. The focus was on protecting the valuable, intangible and vulnerable content of the information.

Having been adopted as an international standard by ISO/IEC many years ago, this standard is now a tech-centric standard covering information technology, Internet technology, and cyber-security. Based on the proportion of the blobs in the diagram above, the third edition of 27002 follows the same trajectory.

In the draft third edition of the guide, there are ample opportunities missed to help users consider information risks to determine whether various controls are really necessary to avoid or mitigate risks, and if so, which controls would be most effective, considering their effectiveness, cost, value, reliability, etc. According to the standard, the controls outlined aren’t simply good practices worth considering in different circumstances but required or mandatory to the extent that not implementing them might perhaps be construed as unprofessional, inept or incompetent. Despite the diversity of organizations in scope and information risks, there is a subtle presumption that most if not all of the controls should be applied to them all.

BS 7799 was particularly notable for its “control objectives,” which explained what the controls were expected to achieve in a business-related way. This enabled them to be interpreted in the specific context of an organization. Controls are a good place to start as examples of what can be put in place to achieve a valid objective, not just in the sense of being mandatory or even recommended, rather than as the only way to achieve that objective.

In addition to ‘themes’, controls in the third edition are to be tagged with further parameters so that they can be grouped or selected in other ways as well. This complicates the project, and the standard, but reflects the level of complication:

– Depending on its application, a control may have several benefits (e.g. backups prevent malware, hacks, bugs, accidents, mechanical breakdowns, and fires., and also have deputy backups of critical personnel, alternate providers for information technology, and data backups);
– There are typically several controls required for any given application or situation (e.g. malware can be prevented using backups, awareness, antivirus, network access controls, intrusion detection and prevention systems, authenticating, patching, testing, and maintaining the integrity of the system, etc., can achieve the desired goal of avoiding infections when supported by controls such as policies, blacklisting etc.);
– Controls that we commonly think about (such as backups) are more complex and composed of several components (including strategies, policies and procedures, software, hardware, incident response, and physical protection of backup media).

Some security controls are tagged arbitrarily and allocated to themes: for example, a commercial card access lock on an entrance may pertain to any or even all four of the themes listed above; if it and other similar controls were covered several times, the standard would become cumbersome. Physical controls with references to other elements are more likely to be classified as such.

It will be possible for users to refine the categories and tags, defining their own if they wish. It’s great that ISO/IEC allows us this freedom!

Even though the restructured standard is meant to be able to be read and used on paper, it is strongly recommended that users use a database application (even an Excel spreadsheet) that allows users to filter and sort the controls by criteria – for instance, “What physical security controls are relevant for privacy?” or “What preventive controls are not dependent on technology?”. Usually, database applications are more concerned with categorizing, tagging, and describing controls than they are with the sequence. This should be an interesting experiment.

The fact that the standard has been infected with the “cyber” virus creates problems of definition and interpretation almost instantly. Many contributors have cited information security and cybersecurity as distinct domains and want a standard that covers both, while others are more interested in understanding how the two differ before classifying controls… I, for one, fall into the second category. What does the term “cybersecurity” really mean and encompass? Let’s start with SC 27, then!

By using “information and other associated assets” throughout the standard, the committee hopes to solve its long-standing problem with the term “information asset”. That might not settle the matter, but I get the impression everyone is tired of arguing about it, and the publication deadline is fast approaching, so it will have to do for now.

As with the 2nd edition, the committee hopes to resolve confusion over the definition of “policy,” offering three variants for the 3rd edition:

– At the top of the classic policy pyramid, at the top of the information security pyramid, “Information Security Policy” would be the corporate policy.
– “Topic-specific policies” will be used for mid-level policies, such as “access control and clear desk and clear screen policies”. (I would think of the latter as more of a rule than a policy … and indeed, according to the project team, topic-specific policies include guidelines and rules, making this level a blend, transition or link between the upper and lower layers). In line with the high-level policy, these will be approved by “the appropriate management level,” and where appropriate, can be adapted/interpreted locally by departments, business units, etc., where their specific context (related to information risks, security requirements, business scenarios, etc.) deviates from the corporate context in general;
– The definition of a rule will be the lowest level, which consists of an accepted principle or instruction clearly stating what the organization expects, what is allowed, and what should not be allowed” (I’m not certain an organization can ‘expect’ anything, or should have expectations on rather than of anything: it is common for management to impose rules on behalf of their organization and their stakeholders … but this definition has been a source of argument, so as long as the compromise is generally accepted, it’ll do. Let’s get going!).