Please support our sponsors ...
ISO/IEC 27002:2013 Information technology — Security techniques — Code of practice for information security controls (second edition)
ISO/IEC 27002 is a popular, internationally-recognized standard of good practice for information security. ISO/IEC 27002 traces its history back more than 30 years to the precursors of BS 7799.
Scope of the standard
Like governance and risk management, information security management is a broad topic with ramifications throughout all organizations. Information security, and hence ISO/IEC 27002, is relevant to all types of organization including commercial enterprises of all sizes (from one-man-bands up to multinational giants), not-for-profits, charities, government departments and quasi-autonomous bodies - in fact any organization that handles and depends on information. The specific information security risk and control requirements may differ in detail but there is a lot of common ground, for instance most organizations need to address the information security risks relating to their employees plus contractors, consultants and the external suppliers of information services.
The standard is explicitly concerned with information security, meaning the security of all forms of information (e.g. computer data, documentation, knowledge and intellectual property) and not just IT/systems security or “cybersecurity” as is the fashion of the day.
Relationship to ISO/IEC 27001
ISO/IEC 27001 formally defines the mandatory requirements for an Information Security Management System (ISMS). It uses ISO/IEC 27002 to indicate suitable information security controls within the ISMS, but since ISO/IEC 27002 is merely a code of practice/guideline rather than a certification standard, organizations are free to select and implement other controls, or indeed adopt alternative complete suites of information security controls as they see fit. ISO/IEC 27001 incorporates a summary (little more than the section titles in fact) of controls from ISO/IEC 27002 in Annex A. In practice, most organizations that adopt ISO/IEC 27001 also adopt ISO/IEC 27002.
Structure and format of ISO/IEC 27002:2013
ISO/IEC 27002 is a code of practice - a generic, advisory document, not a formal specification such as ISO/IEC 27001. It recommends information security controls addressing information security control objectives arising from risks to the confidentiality, integrity and availability of information. Organizations that adopt ISO/IEC 27002 must assess their own information security risks, clarify their control objectives and apply suitable controls (or indeed other forms of risk treatment) using the standard for guidance.
The standard is structured logically around groups of related security controls. Many controls could have been put in several sections but, to avoid duplication and conflict, they were arbitrarily assigned to one and, in some cases, cross-referenced from elsewhere. For example, a card-access-control system for, say, a computer room or archive/vault is both an access control and a physical control that involves technology plus the associated management/administration and usage procedures and policies. This has resulted in a few oddities (such as section 6.2 on mobile devices and teleworking being part of section 6 on the organization of information security) but it is at least a reasonably comprehensive structure. It may not be perfect but it is good enough.
Contents of ISO/IEC 27002:2015
In more detail, here is a breakdown summarizing the standard’s 19 sections or chapters (21 if you include the unnumbered foreword and bibliography). Click the diagram to jump to the relevant description.
Briefly mentions ISO/IEC JTC1/SC 27, the committee that wrote the standard, and notes that this “second edition cancels and replaces the first edition (ISO/IEC 27002:2005), which has been technically and structurally revised”.
Section 0: Introduction
This lays out the background, mentions three origins of information security requirements, notes that the standard offers generic and potentially incomplete guidance that should be interpreted in the organization’s context, mentions information and information system lifecycles, and points to ISO/IEC 27000 for the overall structure and glossary for ISO27k.
Section 1: Scope
The standard gives recommendations for those who are responsible for selecting, implementing and managing information security. It may or may not be used in support of an ISMS specified in ISO/IEC 27001.
Section 2: Normative references
ISO/IEC 27000 is the only standard considered absolutely indispensable for the use of ISO/IEC 27002. However, various other standards are mentioned in the standard, and there is a bibliography.
Section 3: Terms and definitions
All the specialist terms and definitions are now defined in ISO/IEC 27000 and most apply across the entire ISO27k family of standards.
Section 4: Structure of this standard
Security control clauses
Of the 20 sections or chapters of the standard, 14 specify control objectives and controls. These 14 are the ‘security control clauses’.
There is a standard structure within each control clause: one or more first-level subsections, each one stating a control objective, and each control objective being supported in turn by one or more stated controls, each control followed by the associated implementation guidance and, in some cases, additional explanatory notes. The amount of detail is responsible for the standard being nearly 90 A4 pages in length.
35 control objectives
ISO/IEC 27002 specifies some 35 control objectives (one per ’security control category’) to protect the confidentiality, integrity and availability of information.
The control objectives are at a fairly high level and, in effect, comprise a generic functional requirements specification for an organization’s information security management architecture.
Few professionals would seriously dispute the validity of the control objectives, or, to put that another way, it would be difficult to argue that an organization need not conform with the stated control objectives in general. However, some control objectives are not applicable in every case and their generic wording is unlikely to reflect the precise requirements, especially given the very wide range of organizations to which the standard applies.
Each of the control objectives is supported by at least one control, giving a total of 114. However, the headline figure is somewhat misleading since the implementation guidance recommends numerous actual controls.
The control objective relating to the relatively simple sub-subsection 9.4.2 “Secure log-on procedures”, for instance, is supported by choosing, implementing and using suitable authentication techniques, not disclosing sensitive information at log-on time, data entry validation, protection against brute-force attacks, logging, not transmitting passwords in clear over the network, session inactivity timeouts, and access time restrictions. Whether you consider that to be one or several controls is up to you. It could be argued that ISO/IEC 27002 recommends literally hundreds, perhaps even thousands of distinct information security controls.
Furthermore, the wording throughout the standard clearly states or implies that this is not a totally comprehensive set. An organization may have slightly different or completely novel information security control objectives, requiring other controls in place of or in addition to those stated in the standard.
Section 5: Information security policies
5.1 Management direction for information security
Management should define a set of policies to clarify their direction of, and support for, information security. At the top level, there should be an overall “information security policy” as specified in ISO/IEC 27001 section 5.2.
Section 6: Organization of information security
6.1 Internal organization
The organization should lay out the roles and responsibilities for information security, and allocate them to individuals. Where relevant, duties should be segregated across roles and individuals to avoid conflicts of interest and prevent inappropriate activities. There should be contacts with relevant external authorities (such as CERTs and special interest groups) on information security matters. Information security should be an integral part of the management of all types of project.
6.2 Mobile devices and teleworking
There should be security policies and controls for mobile devices (such as laptops, tablet PCs, wearable ICT devices, smartphones, USB gadgets and other Boys Toys) and teleworking (such as telecommuting, working-from home, road-warriors, and remote/virtual workplaces).
Section 7: Human resource security
7.1 Prior to employment
Security responsibilities should be taken into account when recruiting permanent employees, contractors and temporary staff (e.g. through adequate job descriptions, pre-employment screening) and included in contracts (e.g. terms and conditions of employment and other signed agreements on security roles and responsibilities).
7.2 During employment
Managers should ensure that employees and contractors are made aware of and motivated to comply with their information security obligations. A formal disciplinary process is necessary to handle information security breaches.
7.3 Termination and change of employment
Security aspects of a person’s exit from the organization or significant changes of roles should be managed, such as returning corporate information and equipment in their possession, updating their access rights, and reminding them of their ongoing obligations under privacy laws, contractual terms etc.
Section 8: Asset management
8.1 Responsibility for assets
All information assets should be inventoried and owners should be identified to be held accountable for their security. ‘Acceptable use’ policies should be defined, and assets should be returned when people leave the organization.
8.2 Information classification
Information should be classified and labelled by its owners according to the security protection needed, and handled appropriately.
8.3 Media handling
Information storage media should be managed, controlled, moved and disposed of in such a way that the information content is not compromised.
Section 9: Access control
9.1 Business requirements of access control
The organization’s requirements to control access to information assets should be clearly documented in an access control policy and procedures. Network access and connections should be restricted.
9.2 User access management
The allocation of access rights to users should be controlled from initial user registration through to removal of access rights when no longer required, including special restrictions for privileged access rights and the management of passwords (now called “secret authentication information”) plus regular reviews and updates of access rights.
9.3 User responsibilities
Users should be made aware of their responsibilities towards maintaining effective access controls e.g. choosing strong passwords and keeping them confidential.
9.4 System and application access control
Information access should be restricted in accordance with the access control policy e.g. through secure log-on, password management, control over privileged utilities and restricted access to program source code.
Section 10: Cryptography
10.1 Cryptographic controls
There should be a policy on the use of encryption, plus cryptographic authentication and integrity controls such as digital signatures and message authentication codes, and cryptographic key management.
Section 11: Physical and environmental security
11.1 Secure areas
Defined physical perimeters and barriers, with physical entry controls and working procedures, should protect the premises, offices, rooms, delivery/loading areas etc. against unauthorized access. Specialist advice should be sought regarding protection against fires, floods, earthquakes, bombs etc.
11.2 Equipment security
“Equipment” (meaning ICT equipment, mostly) plus supporting utilities (such as power and air conditioning) and cabling should be secured and maintained. Equipment and information should not be taken off-site unless authorized, and must be adequately protected both on and off-site. Information must be destroyed prior to storage media being disposed of or re-used. Unattended equipment must be secured and there should be a clear desk and clear screen policy.
Section 12: Operations management
12.1 Operational procedures and responsibilities
IT operating responsibilities and procedures should be documented. Changes to IT facilities and systems should be controlled. Capacity and performance should be managed. Development, test and operational systems should be separated.
12.2 Protection from malware
Malware controls are required, including user awareness.
Appropriate backups should be taken and retained in accordance with a backup policy.
12.4 Logging and monitoring
System user and administrator/operator activities, exceptions, faults and information security events should be logged and protected. Clocks should be synchronized.
12.5 Control of operational software
Software installation on operational systems should be controlled.
12.6 Technical vulnerability management
Technical vulnerabilities should be patched, and there should be rules in place governing software installation by users.
12.7 Information systems audit considerations
IT audits should be planned and controlled to minimize adverse effects on production systems, or inappropriate data access.
13 Communications security
13.1 Network security management
Networks and network services should be secured, for example by segregation.
13.2 Information transfer
There should be policies, procedures and agreements (e.g. non-disclosure agreements) concerning information transfer to/from third parties, including electronic messaging.
Section 14: System acquisition, development and maintenance
14.1 Security requirements of information systems
Security control requirements should be analyzed and specified, including web applications and transactions.
14.2 Security in development and support processes
Rules governing secure software/systems development should be defined as policy. Changes to systems (both applications and operating systems) should be controlled. Software packages should ideally not be modified, and secure system engineering principles should be followed. The development environment should be secured, and outsourced development should be controlled. System security should be tested and acceptance criteria defined to include security aspects.
Note: there is a typo in 14.2.8: the reference to section 14.1.9 should read 14.2.9. See the status update below, or technical corrigendum 2 for the official correction.
14.3 Test data
Test data should be carefully selected/generated and controlled.
15: Supplier relationships
15.1 Information security in supplier relationships
There should be policies, procedures, awareness etc. to protect the organization’s information that is accessible to IT outsourcers and other external suppliers throughout the supply chain, agreed within the contracts or agreements.
15.2 Supplier service delivery management
Service delivery by external suppliers should be monitored, and reviewed/audited against the contracts/agreements. Service changes should be controlled. [Exactly the same point applies to services delivered by internal suppliers, by the way!]
Section 16: Information security incident management
16.1 Management of information security incidents and improvements
There should be responsibilities and procedures to manage (report, assess, respond to and learn from) information security events, incidents and weaknesses consistently and effectively, and to collect forensic evidence.
Section 17: Information security aspects of business continuity management
17.1 Information security continuity
The continuity of information security should be planned, implemented and reviewed as an integral part of the organization’s business continuity management systems.
IT facilities should have sufficient redundancy to satisfy availability requirements.
Section 18: Compliance
18.1 Compliance with legal and contractual requirements
The organization must identify and document its obligations to external authorities and other third parties in relation to information security, including intellectual property, [business] records, privacy/personally identifiable information and cryptography.
18.2 Information security reviews
The organization’s information security arrangements should be independently reviewed (audited) and reported to management. Managers should also routinely review employees’ and systems’ compliance with security policies, procedures etc. and initiate corrective actions where necessary.
The standard concludes with a long reading list of 27 (!) relevant ISO/IEC standards.
ISO/IEC 27002 ISMS implementation guidance
A collection of ISMS implementation guidelines and sample documents is available to download in the free ISO27k Toolkit, and implementation tips are sprinkled liberally throughout our ISO27k FAQ.
ISO/IEC 27003 provides generic ISMS implementation guidance.
There are also a few ‘sector-specific’ ISMS implementation guidelines i.e. ISO/IEC 27011 for the telecomms sector, ISO/IEC TR 27015 for financial services, ISO 27799 for healthcare and (in due course) ISO/IEC 27019 for process control in the energy sector.
Status of the standard
The revised version of ISO/IEC 27002 was published in September 2013 at the same time as the new version of ISO/IEC 27001.
The title changed from “Code of practice for information security management” to “Code of practice for information security controls” to emphasize the key difference between these two standards. 27002 concerns the information security controls whereas 27001 deals with their management.
A Technical Report ISO/IEC TR 27023 is in the works, mapping between the 2013 and 2005 versions of this standard.
SC 27’s confusion over the intended meaning of “information asset” rumbles on. The decision to drop the definition of “information asset” from the current version of ISO/IEC 27000 rather than truly bottom out this issue may prove to have been a tactical error. A technical corrigendum made minor changes to the wording of ISO/IEC 27002:2013 supposedly to clarify that “information” is indeed an “asset”: the corrigendum was published in October 2014.
A simple monodigit typo resulting in a reference from section 14.2.8 pointing back to 14.1.9 (there is no such section - shock! Horror!) instead of forward to 14.2.9 (the correct, intended reference to, yes, the very next section) was noted formally as a defect in the published standard, following the proper ISO/IEC procedures to the letter of course. Esteemed representatives of a number of national standards bodies met in person to discuss and consider this dreadful situation at some length and some cost to their respective taxpayers. What on Earth could be done about it?
UPDATE: “Agreed resolution: During the plenary held in Kuching it was decided unanimously that this mistake should be fixed by simply replacing “see 14.1.1 and 14.1.9€” with “see 14.1.1 and 14.2.9.” Remarkable! Unanimous agreement on a simple fix! What a relief!
FURTHER UPDATE: I am sorely tempted to raise a defect notice concerning the lack of a closing speech mark in the “Agreed resolution” for fear of some bureaucrat somewhere losing sleep over this oversight, or worse still steadfastly refusing to change the “1” to “2” until the matter is duly addressed ... except that I Have A Life and can’t be bothered. Life’s too short.
The second corrigendum was published in November 2015.
ISO/IEC 27002 is a massive standard covering a very broad range of information security risks and controls. There is so much content, in fact, and so many changes due to the ongoing evolution of information security, that I feel it has outstripped the capabilities of SC 27. In my considered opinion, it is no longer maintainable, hence it is no longer viable in its current form.
Take for example the mess that is section 17, “Information security aspects of business continuity management”. I argued that information security and business continuity are so tightly intertwined that this section should be rewritten from scratch to emphasize three distinct but complementary aspects (resilience, recovery and contingency). Indeed I provided a completely re-written section to the committee but, for various unsatisfactory reasons, we have ended up with a compromise that makes a complete mockery of the entire subject. Most of section 17 is concerned with maintaining information security controls during a disaster recovery-type situation (an issue that may not even deserve coverage at this level, and certainly not to the extent it is covered), while all that remains of my re-write is a garbled section on “redundancies” that is so obscure as to be practically meaningless.
Take for example the fact that revising the standard has consumed thousands of man-hours of work and created enormous grief for all concerned, over several years, during which time the world around us has moved on. In the 2013 release, there is a complete lack of reference to BYOD and cloud computing - two very topical and pressing information security issues where the standard could have given practical guidance. What’s more, the end result is inconsistent in terms of the level of detail and tone. It bears more than a passing resemblance to a racing horse designed by a committee (i.e. a camel).
The time is ripe for a back-to-basics re-think of ISO/IEC 27002.
As I see it, this could pan-out in several ways:
Option 1: divide 27002 into a multi-part standard consisting of an overview/introductory part, followed by a handful of topic-specific parts that, together, cover the entire breadth. This implies the need for a set of SC 27 projects and editors to work on the separate parts, plus an overall coordination team responsible for ensuring continuity and consistency across them all. Converting 27002 into a multi-partite standard would have several advantages:
The individual parts could be revised independently to keep pace with the evolution of information security, particularly but not exclusively the technological aspects;
The individual parts would be more manageable: reviewing, commenting and editing them would be more feasible within the constraints of an international committee working almost exclusively through just 2 face-to-face meetings per year;
The main clauses of the current and revised versions of 27002 naturally imply the scope of the subsidiary parts (though not necessarily a one-to-one relationship);
Some of those implied subsidiary parts are already in place, or under development, as separately-numbered ISO27k standards.
However, coordination across several semi-independent project teams would be an onerous task, implying a concerted effort up-front to clearly and explicitly define the ground rules, scopes and objectives of the subsidiary parts, and ongoing proactive involvement of a management team with its fingers on the pulse of all the subsidiary project teams.
Option 2: re-cast 27002 as a far more succinct, higher-level overview standard with links to other, more detailed standards to fill-in the details. 27002 itself would provide broad, generic information security guidance across the full scope of ISO27k. It would be small enough to be feasible for the current ways of working within SC 27.
Option 3: SC 27 could adopt collaborative working practices, jointly developing a revised version of 27002 through real-time collaborative development and editing of a shared document, at least as far as the Committee Drafts when the approach might revert to the existing formalized methods to complete the process and issue a revised standard. [This option could be combined with any of the others, if only SC 27 would wake up and smell the coffee. This is the 21st Century, friends!]
Option 4: retire 27002 as such, leaving behind Annex A in 27001 as the final legacy from the original code of practice and BS 7799. Cover all the aspects of information security that need to be covered through other ISO27k standards, or indeed other standards outside the remit of SC 27. Give up on 27002. Abandon it as a lost cause.
Option 5: continue as at present. This is the straw man as far as I am concerned: it will undoubtedly take SC 27 so long and so much effort to revise 27002 that we probably ought to have started working on the next revision before the 2013 version was even published!
Option 6: a formal proposal has been submitted to SC 27 for a study period on an “Information Security Architecture Library” (ISAL) standard explaining how all the ISO27k standards fit together, and how organizations might choose to use them [which sounds to me a lot like the overview function of ISO/IEC 27000!]. Internally, it would drive the development of a roadmap for the continued development of ISO27k. It is not entirely clear from the proposal whether ISO/IEC 27001 Annex A or ISO/IEC 27002 would still be required in the new structure, nor what that structure would be (the study team is expected to figure that out, I guess).
Options 7+: I’m sure there are other ways of doing this ... what would you suggest? Please join the discussion on the ISO27k Forum.