ISO/IEC 27002:2005 Information technology -- Security techniques -- Code of Practice for Information Security Management
Quick links
Introduction
ISO/IEC 27002:2005, the latest version of “Information technology - Security techniques - Code of practice for information security management”, to give it its full title, is an internationally-accepted standard of good practice for information security. Tens or hundreds of thousands of organizations worldwide follow ISO/IEC 27002.
A brief history of ISO/IEC 27002
ISO/IEC 27002 has evolved through several changes. Working backwards from today, here's the full sequence of events.
ISO/IEC 27002:???? - revision 
At the Kyoto meeting in April 2008, ISO/IEC JTC1/SC27 launched a project to revise ISO/IEC 27002 over the next year or three. Inputs are sought from ISO/IEC member bodies on what revisions might be needed. Since ISO/IEC 27002 is widely used and is referenced by the ISMS certification standard ISO/IEC 27001, major/structural changes are likely to be limited and even minor changes will have to be justified in order to retain “backwards compatibility” with the existing standard.
[We have discussed some potential revisions on the ISO27k Implementers’ Forum and will continue doing so for some time yet. Please contact your national standards body (e.g. BSI, NIST) or ISO directly for further information or to offer your assistance with the standards development process and JTC 1/SC 27 in particular. This is your big chance to get involved and influence the future direction of this well-respected information security standard!]
ISO/IEC 27002:2005
ISO/IEC 17799:2005 was renumbered ISO/IEC 27002:2005 in the middle of 2007 to bring it into the ISO/IEC 27000 family of standards. The text remains word-for-word identical to ISO/IEC 17799:2005 - in fact, for some while the ISO/IEC 17799 standard continued to be delivered to anyone who ordered ISO/IEC 27002, along with a cover sheet noting the change of number.
ISO/IEC 17799:2005
In June 2005, the 2000 version was significantly updated with new sections consolidating advice on risk and incident management and many other revisions were sprinkled liberally throughout. The format was altered to clarify the ‘implementation guidance’ under each control.
ISO/IEC 17799:2000
After a difficult period of international consideration and review, BS 7799 was finally adopted by ISO/IEC and was released as ISO/IEC 17799 in December 2000. Some members of the ISO/IEC joint committee apparently remained unhappy with this first release.
BS 7799 Part 1: 1999
The previous British Standard 7799 was joined by a new part 2 (that later became ISO/IEC 27001), the accompanying certification standard, so the original standard was renamed “Part 1” in 1999.
BS 7799:1995
The British Standards Institute BSI (now known as BSI British Standards, part of the BSI Group) released British Standard 7799.
DTI Code of Practice for Information Security Management
Pending its release as an official British Standard, the guts of BS 7799 were, in effect, pre-released by the UK Department of Trade and Industry in 1993 as an informational item, for free if I recall correctly, called BSI-DISC PD003 (British Standards Institution - Delivering Information Solutions to Customers - Public Document 003). BSI-DISC released some nifty free accompanying booklets too, one of which (PD005?) had a neat one-page flowchart summarising the implementation process which, sadly, did not make it in to any of the current-day materials.
NCC Code of Practice
I gather the UK National Computing Centre (NCC) published a Code of Practice document of some form prior to PD003 in 1993. [Do you know any more about this? My memory fails me! If you can help, please get in touch.]
Royal Dutch/Shell Group Information Security Policy Manual
Legend has it that the initial release of BS 7799 was based heavily on this internal document generously donated by the company. The standard’s emphasis on mainframe security concepts and lack of explicit references to the Internet certainly suggests that it was based on something written maybe a decade earlier.
Scope of ISO/IEC 27002
Like governance, information security is a broad topic with ramifications in all parts of the modern organization. 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 requirements may be different in each case but the point of ISO/IEC 27002 is that there is a lot of common ground.
The standard is explicitly concerned with information security, meaning the security of information assets, and not just IT/systems security per se. The IT Department is merely the custodian of a good proportion of the organization’s information assets and is charged with securing them by the information asset owners - the business managers who are accountable for the assets. A large proportion of written and intangible information (e.g. the knowledge and experience of workers) is nothing to do with IT.
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, organizations are free to select and implement other controls as they see fit. ISO/IEC 27001 incorporates a summary (little more that than the section titles in fact) of controls from ISO/IEC 27002 under Annex A.
Structure and format of ISO/IEC 27002
ISO/IEC 27002 is a code of practice - a generic, advisory document, not truly a standard or formal specification such as ISO/IEC 27001. It lays out a well structured set of suggested controls to address information security risks, covering confidentiality, integrity and availability aspects. Organizations that adopt ISO/IEC 27002 must assess their own information security risks and apply suitable controls, using the standard for guidance. Strictly speaking, none of the controls are mandatory but if an organization chooses not to adopt something as common as, say, antivirus controls, they should certainly be prepared to demonstrate that this decision was reached through a rational risk management decision process, not just an oversight, if they anticipate being certified compliant to ISO/IEC 27001.
39 control objectives
After the introduction, scope, terminology and structure sections, the remainder of ISO/IEC 27002 specifies some 39 control objectives to protect information assets against threats to their confidentiality, integrity and availability. These control objectives in effect comprise a generic functional requirements specification for an organization’s information security management controls architecture.
Few people would quarrel with most of the control objectives, or, to put that an other way, it would be difficult to argue that the organization should not conform with the stated objectives in general. However, a few are not applicable in every case, and the generic wording of the standard does not necessarily reflect each organization’s precise requirements.
In our experience, the control objectives make an excellent starting point to define a comprehensive set of “axioms” or high level principles for information security policies with only slight re-wording.
Hundreds of specific controls
Whereas ISO/IEC 27001 Annex A refers to 139 “controls”, they are in fact just sections in ISO/IEC 27002, many of which propose multiple security controls. ISO/IEC 27002 suggests literally hundreds of best-practice information security control measures that organizations should consider to satisfy the stated control objectives.
ISO/IEC 27002 does not mandate specific controls but leaves it to the users to select and implement controls that suit them, using a risk-assessment process to identify the most appropriate controls for their specific requirements. They are also free to select controls not listed in the standard, just so long as their control objectives are satisfied. We treat the ISO/IEC standard as a generic controls checklist - a “menu” from which organizations select their own set or a la carte meals.
Not mandating specific controls is a master stroke that makes the standard broadly applicable even as the technology and security risks change, and gives users tremendous flexibility in the implementation. Unfortunately, it also makes it difficult for the certification bodies to assess whether an organization is fully compliant with the standard, hence there are no formal compliance certificates against ISO/IEC 27002 itself. Organizations may instead get their information security governance/management processes, meaning the Information Security Management System as a whole, certified against ISO/IEC 27001 which describes the process for assessing risks and selecting, implementing and managing specific security controls from ISO/IEC 27002 or indeed other sources.
Contents of ISO/IEC 27002 (outline)
The mind map summarizes the main sections of the standard on one side. Click the image to download a larger version more suitable for reading and printing. The sections are outlined below.
Section 0: Introduction
Starting from ‘What is information security?’, the introduction explains how to make use of the standard.
Section 1: Scope
The standard gives information security management recommendations for those who are responsible for initiating, implementing or maintaining security.
Section 2: Terms and definitions
“Information security” is explicitly defined as the “preservation of confidentiality, integrity and availability of information”. These and other related terms are further defined. [In due course when ISO/IEC 27000 has been released and ISO/IEC 27002 is revised, this section will presumably reference definitions in ISO/IEC 27000.]
Section 3: Structure of this standard
This page simply explains that the guts of the standard contain control objectives, suggested controls and implementation guidance.
Section 4: Risk assessment and treatment
The current ISO/IEC 27002 standard covers the topic of risk management in just a page and a half, woefully inadequate coverage for such a complex and central element of information security. [When ISO/IEC 27002 is revised, it will probably reference ISO/IEC 27005. In keeping with the style of ISO/IEC 27002, ISO/IEC 27005 gives general guidance on selecting and using appropriate methods to analyze information security risk - it does not mandate a specific method since ‘appropriate’ depends on context.]
Section 5: Security policy
Management should define a policy to clarify their direction of, and support for, information security, meaning a short, high-level information security policy statement laying down the key information security directives and mandates for the entire organization. This is normally supported by a comprehensive suite of more detailed corporate information security policies, typically in the form of an information security policy manual. The policy manual in turn is supported by a set of information security standards, procedures and guidelines.
Although the standards are somewhat ambiguous on this point, the information security policy noted in ISO/IEC 27002 is generally understood to be separate and different from the ISMS policy required by ISO/IEC 27001. The ISMS policy is seen by some as a strategy or governance paper laying out management’s support for the ISMS as a whole.
Section 6: Organization of information security
A suitable information security governance structure should be designed and implemented.
6.1 Internal organization
The organization should have a management framework for information security. Senior management should provide direction and commit their support, for example by approving information security policies. Roles and responsibilities should be defined for the information security function. Other relevant functions should cooperate and coordinate their activities. IT facilities should be authorized. Confidentiality agreements should reflect the organization’s needs. Contacts should be established with relevant authorities (e.g. law enforcement) and special interest groups. Information security should be independently reviewed.
6.2 External parties
Information security should not be compromised by the introduction of third party products or services. Risks should be assessed and mitigated. when dealing with customers and in third party agreements.
Section 7: Asset management
The organization should be in a position to understand what information assets it holds, and to manage their security appropriately.
7.1 Responsibility for assets
All [information] assets should be accounted for and have a nominated owner. An inventory of information assets (IT hardware, software, data, system documentation, storage media, supporting assets such as computer room air conditioners and UPSs, and ICT services) should be maintained. The inventory should record ownership and location of the assets, and owners should identify acceptable uses.
7.2 Information classification
Information should be classified according to its need for security protection and labeled accordingly. [While this is clearly most relevant to military and government organizations handling ‘protectively marked information’ (Top Secret etc.), the concept of identifying important assets, classifying/grouping them, and applying controls that are judged suitable for assets of that nature, is broadly applicable.]
Section 8: Human resources security
The organization should manage system access rights etc. for ‘joiners, movers and leavers’, and should undertake suitable security awareness, training and educational activities.
8.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).
8.2 During employment
Management responsibilities regarding information security should be defined. Employees and (if relevant) third party IT users should be made aware, educated and trained in security procedures. A formal disciplinary process is necessary to handle security breaches.
8.3 Termination or change of employment
Security aspects of a person’s exit from the organization (e.g. the return of corporate assets and removal of access rights) or change of responsibilities should be managed.
Section 9: Physical and environmental security
Valuable IT equipment should be physically protected against malicious or accidental damage or loss, overheating, loss of mains power etc.
9.1 Secure areas
This section describes the need for concentric layers of physical controls to protect sensitive IT facilities from unauthorized access.
9.2 Equipment security
Critical IT equipment, cabling and so on should be protected against physical damage, fire, flood, theft etc., both on- and off-site. Power supplies and cabling should be secured. IT equipment should be maintained properly and disposed of securely.
Section 10: Communications and operations management
This lengthy, detailed section of the standard describes security controls for systems and network management.
10.1 Operational procedures and responsibilities
IT operating responsibilities and procedures should be documented. Changes to IT facilities and systems should be controlled. Duties should be segregated between different people where relevant (e.g. access to development and operational systems should be segregated).
10.2 Third party service delivery management
Security requirements should be taken into account in third party service delivery (e.g. IT facilities management or outsourcing), from contractual terms to ongoing monitoring and change management. Do you have suitable security clauses in the contract with your ISP?
10.3 System planning and acceptance
Covers IT capacity planning and production acceptance processes.
10.4 Protection against malicious and mobile code
Describes the need for anti-malware controls, including user awareness. Security controls for mobile code ‘associated with a number of middleware services’ are also outlined.
10.5 Back-up
Covers routine data backups and rehearsed restoration.
10.6 Network security management
Outlines secure network management, network security monitoring and other controls. Also covers security of commercial network services such as private networks and managed firewalls etc.
10.7 Media handling
Operating procedures should be defined to protect documents and computer media containing data, system information etc. Disposal of backup media, documents, voice and other recordings, test data etc. should be logged and controlled. Procedures should be defined for securely handling, transporting and storing backup media and system documentation.
10.8 Exchange of information
Information exchanges between organizations should be controlled, for example though policies and procedures, and legal agreements. Information exchanges should also comply with applicable legislation. Security procedures and standards should be in place to protect information and physical media in transit, including electronic messaging (email, EDI and IM) and business information systems.
10.9 Electronic commerce services
The security implications of eCommerce (online transaction systems) should be evaluated and suitable controls implemented. The integrity and availability of information published online (e.g. on websites) should also be protected.
10.10 Monitoring
Covers security event/audit/fault logging and system alarm/alert monitoring to detect unauthorized use. Also covers the need to secure logs and synchronize system clocks.
Section 11: Access control
Logical access to IT systems, networks and data must be suitably controlled to prevent unauthorized use. This is another lengthy and detailed section.
11.1 Business requirement for access control
The organization’s requirements to control access to information assets should be clearly documented in an access control policy, including for example job-related access profiles (role based access control). [This is an important obligation for information asset owners.]
11.2 User access management
The allocation of access rights to users should be formally controlled through user registration and administration procedures (from initial user registration through to removal of access rights when no longer required), including special restrictions over the allocation of privileges and management of passwords, and regular access rights reviews.
11.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. Systems and information should be secured when left unattended (e.g. clear desk and clear screen policies).
11.4 Network access control
Access to network services should be controlled, both within the organization and between organizations. Policy should be defined and remote users (and possibly equipment) should be suitably authenticated. Remote diagnostic ports should be securely controlled. Information services, users and systems should be segregated into separate logical network domains. Network connections and routine should be controlled where necessary.
11.5 Operating system access control
Operating system access control facilities and utilities (such as user authentication with unique user IDs and managed passwords, recording use of privileges and system security alarms) should be used. Access to powerful system utilities should be controlled and inactivity timeouts should be applied.
11.6 Application and information access control
Access to and within application systems should be controlled in accordance with a defined access control policy. Particularly sensitive applications may require dedicated (isolated) platforms, and/or additional controls if run on shared platforms.
11.7 Mobile computing and teleworking
There should be formal policies covering the secure use of portable PCs, PDAs, cellphones etc., and secure teleworking (“working from home”, “road warriors” and other forms of mobile or remote working).
Section 12: Information systems acquisition, development and maintenance
Information security must be taken into account in the processes for specifying, building/acquiring, testing, implementing and maintaining IT systems.
12.1 Security requirements of information systems
Automated and manual security control requirements should be analyzed and fully identified during the requirements stage of the systems development or acquisition process, and incorporated into business cases. Purchased software should be formally tested for security, and any issues risk-assessed.
12.2 Correct processing in application systems
Data entry, processing and output validation controls and message authentication should be provided to mitigate the associated integrity risks.
12.3 Cryptographic controls
A cryptography policy should be defined, covering roles and responsibilities, digital signatures, non-repudiation, management of keys and digital certificates etc.
12.4 Security of system files
Access to system files (both executable programs and source code) and test data should be controlled.
12.5 Security in development and support processes
Application system managers should be responsible for controlling access to [development] project and support environments. Formal change control processes should be applied, including technical reviews. Packaged applications should ideally not be modified. Checks should be made for information leakage for example via covert channels and Trojans if these are a concern. A number of supervisory and monitoring controls are outlined for outsourced development.
12.6 Technical vulnerability management
Technical vulnerabilities in systems and applications should be controlled by monitoring for the announcement of relevant security vulnerabilities, and risk-assessing and applying relevant security patches promptly.
Section 13: Information security incident management
Information security events, incidents and weaknesses (including near-misses) should be promptly reported and properly managed.
13.1 Reporting in information security events and weaknesses
An incident reporting/alarm procedure is required, plus the associated response and escalation procedures. There should be a central point of contact, and all employees, contractors etc. should be informed of their incident reporting responsibilities.
13.2 Management of information security incidents and improvements
Responsibilities and procedures are required to manage incidents consistently and effectively, to implement continuous improvement (learning the lessons), and to collect forensic evidence.
Section 14: Business continuity management
This section describes the relationship between IT disaster recovery planning, business continuity management and contingency planning, ranging from analysis and documentation through to regular exercising/testing of the plans. These controls are designed to minimize the impact of security incidents that happen despite the preventive controls noted elsewhere in the standard.
Section 15: Compliance
15.1 Compliance with legal requirements
The organization must comply with applicable legislation such as copyright, data protection, protection of financial data and other vital records, cryptography restrictions, rules of evidence etc.
15.2 Compliance with security policies and standards, and technical compliance
Managers and system owners must ensure compliance with security policies and standards, for example through regular platform security reviews, penetration tests etc. undertaken by competent testers.
15.3 Information systems audit considerations
Audits should be carefully planned to minimize disruption to operational systems. Powerful audit tools/facilities must also be protected against unauthorized use.
ISO/IEC 27002 ISMS implementation guidance
A collection of ISMS implementation guidelines and sample documents is available to download in the form of our free ISO27k Toolkit.
When released, ISO/IEC 27003 will also provide generic ISMS implementation guidance. A series of ‘sector-specific’ ISMS implementation guidelines is planned, starting with ISO/IEC 27011 for the telecomms sector. Other sectors are not yet defined/agreed, although the energy sector/utilities, financial sector and “e-government services” among others have been discussed by JTC1/SC27.
The State of California State Information Security Office’s 43-page Information Security Program Guide for State Agencies is, in effect, a guideline on implementing ISO/IEC 27002 for US government entities. It includes a template ‘acceptable use’ policy for example. The State also offers a range of risk analysis checklists, tools and advice for small/simple, medium and large/complex entities, and a guide to the role and responsibilities of information security officer.
|
