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.]

Info from BERR on the asset management section

 
  

Sponsor this page!

Contact us to advertise your business

ISO/IEC 27002:2005  Information technology -- Security tech

Information Security Management

Quick links

 Introduction to ISO/IEC 27002

o A brief history of ISO/IEC 27002 including its planned revision
o Scope of ISO/IEC 27002
o Relationship to ISO/IEC 27001

 Structure and format of ISO/IEC 27002

o 39 control objectives
o Hundreds of specific controls
 

 Content of ISO/IEC 27002 (outline)

0.  Introduction

1.  Scope

2.  Terms and definitions

3.  Structure of this standard

4.  Risk assessment and treatment

5.  Security policy

6.  Organization of information security

7.  Asset management

8.  Human resources security

9.  Physical and environmental security

10. Communications and operations management

11. Access control

12. Information systems acquisition, development and maintenan

13. Information security incident management

14. Business continuity management

15. Compliance

 ISMS implementation guidance and further resources

Introduction

ISO/IEC 27002:2005, the latest version of “Information technology - Secur

information security management”, to give it its full title, is an internationall
information security.  Tens or hundreds of thousands of organizations worldwid

A brief history of ISO/IEC 27002

ISO/IEC 27002 has evolved through several changes.  Working backwards from

ISO/IEC 27002:2011?? - currently undergoing revision

In parallel with the revision of ISO/IEC 27001, ISO/IEC JTC1/SC27 is currentl

ISO/IEC 27002 is widely used and is referenced by the ISMS certification stand
changes are likely to be limited and even minor changes will have to be justified
compatibility” with the existing standard. 

Suggestions to revise the structure of ’27002 substantially do not appear to have

lot of inertia since the standard is already widely used and hence there is widesp
structure.  On top of that, the present structure is largely adequate for purpose -
or combining sub-clauses can be done without wholesale restructuring.

Regarding the open question of what is meant by ‘policies’, there appears to be

itself to information security policies while leaving the definition of ISMS polic
this issue is under discussion and has not yet been formally resolved within SC2
proposed supplementing the existing advice about having an overarching inform
advice on adopting a comprehensive suite of supporting policies or standards at
policy’, ‘cryptographic controls policy’ and so forth) [some such lower level po
places in the standard but would probably benefit from being discussed and liste
applicable clauses for the full explanations of each one].

Several comments regarding the concepts and practices of classification and ow

[The current definitions of ‘asset’ and ‘information asset’ are still causing confu

 The ’27002 editors are busy consolidating a large number (256 pages!) of
text, and hence do not propose to issue another working draft until
WD is anticipated to have a simpler and more accurate scope, reflecting the actu
ISO/IEC 27001 which specifies the management system.  It may
management” or even simpler “Information security controls” but this will be di

Get involved

Please contact your national standards body (e.g. BSI, NIST) or ISO/IEC directl
your assistance with the standards development process and ISO/IEC JTC 1/SC
chance to get involved and influence the future direction of this well-respected i

The revised standard is projected to be released in 2011, hopefully at the same t

Copyright © 2010 IsecT Ltd.

released.

ISO/IEC 27002:2005 - the current, issued standard

ISO/IEC 17799:2005 was renumbered ISO/IEC 27002:2005 in the middle of 20

family of standards.  The text remains word-for-word identical to ISO/IEC 1779
ISO/IEC 17799 standard continued to be delivered to anyone who ordered ISO/
noting the change of number.

ISO/IEC 17799:2005 - 2005 revision

In June 2005, the 2000 version was significantly updated with new sections con
management and many other revisions sprinkled liberally throughout.
‘implementation guidance’ under each control.

ISO/IEC 17799:2000 - first ISO/IEC version of BS7799-1

After a difficult period of international consideration and review, BS 7799 part 1

on a ‘fast track’ process and was released as ISO/IEC 17799 in December 2000.
were not universally supportive of this first release but it was accepted as a start

BS 7799 Part 1:1999 - revised

Following a BSI review process, the standard was revised and reissued in 1999.

BS 7799 Part 1:1998 - renamed

The previous British Standard 7799 was joined by a new part 2 (that later becam
certification standard, so the original standard was renamed “Part 1” in 1998.

BS 7799:1995 - initial release as a British Standard

The British Standards Institute BSI (now known as BSI British Standards, part o
Standard 7799.

BSI-DISC PD003:1993 - DTI Code of Practice for Information Sec

release

Pending its release as an official British Standard, the guts of BS 7799 were, in
Department of Trade and Industry as a free informational item called BSI-DISC
Delivering Information Solutions to Customers - Public Document 003).
National Computing Centre (NCC) and a nascent community of information sec
evolved into the ISMS International User Group, a loose association of ISMS us
developing PD003 and hence BS 7799.  BSI-DISC released some nifty free acco
(PD005) had a neat one-page flowchart summarising the implementation proces
the current-day ISO27k materials.  The DTI later became BERR, the Departmen
Regulatory Reform, and still supports the ISO27k standards today.

DTI CCSC User’s Code of Practice: 1989 - first publication outside

Using Shell’s donor document, the UK Department of Trade and Industry’s Com
developed this information security guide for their members.  The CCSC also w
assistance from the UK Government's Communications Electronics Security Gr
ITSEC (IT Security Evaluation  and Certification) scheme for certification of se

Late 1980s Royal Dutch/Shell Group Information Security Policy M

BS 7799 and hence ISO27k owes its existence to this internal document generou
Shell.  The original emphasis on mainframe security concepts and lack of explic
origin in the previous decade or so.

Scope of ISO/IEC 27002

Like governance, information security is a broad topic with ramifications in all p

Information security, and hence ISO/IEC 27002, is relevant to all types of organ
enterprises of all sizes (from one-man-bands up to multinational giants), not-for
departments and quasi-autonomous bodies - in fact any organization that handle
specific information security requirements may be different in each case but the
lot of common ground.

The standard is explicitly concerned with information security, meaning the sec
IT/systems security per se.  The IT Department is merely the custodian of a goo
information assets and is commonly charged with securing them by the informa
managers who are accountable for the assets.  However a large proportion of wr
the knowledge and experience of non-IT workers) is nothing to do with IT.

Relationship to ISO/IEC 27001

ISO/IEC 27001 formally defines the mandatory requirements for an Infor

(ISMS).  It uses ISO/IEC 27002 to indicate suitable information security contr
27002 is merely a code of practice/guideline rather than a certification standa
implement other controls, or indeed adopt alternative complete suites of inform
ISO/IEC 27001 incorporates a summary (little more that than the section titles
under its Annex A.  In practice, organizations that adopt ISO/IEC 27001 also su

Structure and format of ISO/IEC 27002

ISO/IEC 27002 is a code of practice - a generic, advisory document, not truly a

ISO/IEC 27001. It lays out a reasonably well structured set of suggested control
covering confidentiality, integrity and availability aspects. Organizations that ad
own information security risks and apply suitable controls, using the standard fo
the controls are mandatory but if an organization chooses not to adopt somethin
they should certainly be prepared to demonstrate that this decision was reached
decision process, not just an oversight, if they anticipate being certified complia

39 control objectives

After the introduction, scope, terminology and structure sections, the remaind
control objectives to protect information assets against threats to their confiden
control objectives in effect comprise a generic functional requirement
information security management controls architecture.

There is one control objective for each second level heading in sections 6 thro
the first level headings in the main sections with no second levels(

Few people would quarrel with most of the control objectives, or, to put that an
that the organization should not conform with the stated objectives in general
every case and the generic wording of the standard is unlikely to reflect each org

In our experience, the control objectives make an excellent starting point to def
high level principles for information security policies with only slight re-wordin

Hundreds of specific controls

Whereas ISO/IEC 27001 Annex A refers to 139 “controls”, they are in fact ju
which propose multiple security controls.  ISO/IEC 27002 suggests literally
security control measures that organizations should consider to satisfy the sta
often quoted is highly misleading.

Like ISO/IEC 27001, ’27002 does not mandate specific controls but leaves
controls that suit them, using a risk-assessment process to identify the most
requirements.  They are also free to select controls not listed in the standard, ju
satisfied.  We treat the ISO/IEC standard as a generic controls checklist -
select their own set or a la carte meals.

Not mandating specific controls is a master stroke that makes the standard bro
and security risks change, and gives users tremendous flexibility in the implem
difficult for the certification bodies to assess whether an organization is fully c
are no formal compliance certificates against ISO/IEC 27002 itself.
security governance/management processes, meaning the Information Secu
certified against ISO/IEC 27001 which describes the process for assessing
managing specific security controls from ISO/IEC 27002 or indeed other source

Contents of ISO/IEC 27002 (outline)

The mind map summarizes the main sections of the standard on one side.

Section 0: Introduction

Starting from ‘What is information security?’, the introduction explains how to

 

Section 1: Scope

The standard gives information security management recommendations for th

implementing or maintaining security.

Section 2: Terms and definitions

“Information security” is explicitly defined as the “preservation of confid

information”.  These and other related terms are further defined.
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 contro
implementation guidance.

Section 4: Risk assessment and treatment

ISO/IEC 27002 covers the topic of risk management in just a page and a half, w
complex and central element of information security.  [When ISO/IEC 2700
ISO/IEC 27005 here although it has been suggested that the risk management
’27002 and moved to ’27001.  In keeping with the style of ’27002, ’27005 g
using appropriate methods to analyze information security risk - it does
‘appropriate’ depends on context.]

Section 5: Security policy

Management should define a policy to clarify their direction of, and support for
high-level information security policy statement laying down the key informat
the entire organization.  This is normally supported by a comprehensive suite
security policies, typically in the form of an information security policy manual
by a set of information security standards, procedures and guidelines.

Although the standards are somewhat ambiguous on this point, the information
is generally understood to be separate and different from the ISMS policy re
policy is seen by some as a strategy or governance paper laying out managemen
fact it may be as short at a statement by the CEO.

Section 6: Organization of information security

A suitable information security governance structure should be designed and im

6.1  Internal organization

The organization should have a management framework for information secur

direction and commit their support, for example by approving information sec
should be defined for the information security function. Other relevant function
activities.  IT facilities should be authorized.  Confidentiality agreements sh
Contacts should be established with relevant authorities (e.g. law enforcement)
security should be independently reviewed.

6.2  External parties

Information security should not be compromised by the introduction of third p

be assessed and mitigated. when dealing with customers and in third party agree

Section 7: Asset management

The organization should be in a position to understand what information asset

appropriately.

7.1  Responsibility for assets

All [information] assets should be accounted for and have a nominated owner.
hardware, software, data, system documentation, storage media, supportin
conditioners and UPSs, and ICT services) should be maintained. The inventory
the assets, and owners should identify acceptable uses.

7.2  Information classification

Information should be classified according to its need for security protection

clearly most relevant to military and government organizations handling ‘protec
etc.), the concept of identifying important assets, classifying/grouping them,
suitable for assets of that nature, is broadly applicable.]

Section 8: Human resources security

The organization should manage system access rights etc. for ‘joiners, mov
suitable security awareness, training and educational activities.

8.1  Prior to employment

Security responsibilities should be taken into account when recruiting permanen

staff (e.g. through adequate job descriptions, pre-employment screening) and
conditions of employment and other signed agreements on security roles and res

8.2 During employment

Management responsibilities regarding information security should be defined.

IT users should be made aware, educated and trained in security procedures.
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
rights) or change of responsibilities should be managed.

Section 9: Physical and environmental security

Valuable IT equipment should be physically protected against malicious or acci

of mains power etc.

9.1  Secure areas

This section describes the need for concentric layers of physical controls
unauthorized access.

9.2  Equipment security

Critical IT equipment, cabling and so on should be protected against physical
and off-site. Power supplies and cabling should be secured. IT equipment shou
of securely.

Section 10:  Communications and operations management

This lengthy, detailed section of the standard describes security controls for syst

10.1  Operational procedures and responsibilities

IT operating responsibilities and procedures should be documented. Changes

controlled. Duties should be segregated between different people where rel
operational systems should be segregated).

10.2  Third party service delivery management

Security requirements should be taken into account in third party service del
outsourcing), from contractual terms to ongoing monitoring and change mana
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.

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 ot

commercial network services such as private networks and managed firewalls

10.7  Media handling

Operating procedures should be defined to protect documents and computer me

etc. Disposal of backup media, documents, voice and other recordings, test da
Procedures should be defined for securely handling, transporting and storing bac

10.8  Exchange of information

Information exchanges between organizations should be controlled, for examp

legal agreements. Information exchanges should also comply with applicab
standards should be in place to protect information and physical media
(email, EDI and IM) and business information systems.

10.9 Electronic commerce services

The security implications of eCommerce (online transaction systems) shou

implemented.  The integrity and availability of information published online (

10.10 Monitoring

Covers security event/audit/fault logging and system alarm/alert monitoring to d

need to secure logs and synchronize system clocks.

Info from BERR o

Section 11: Access control

Logical access to IT systems, networks and data must be suitably controlled

another lengthy and detailed section.

11.1  Business requirement for access control

The organization’s requirements to control access to information assets shou

control policy, including for example job-related access profiles (role based
obligation for information asset owners.]

11.2  User access management

The allocation of access rights to users should be formally controlled throu

procedures (from initial user registration through to removal of access right
special restrictions over the allocation of privileges and management of passwor

11.3  User responsibilities

Users should be made aware of their responsibilities towards maintaining effec

passwords and keeping them confidential. Systems and information should be
desk and clear screen policies).

11.4  Network access control

Access to network services should be controlled, both within the organization a

be defined and remote users (and possibly equipment) should be suitably a
should be securely controlled. Information services, users and systems shou
network domains.  Network connections and routine should be controlled where

11.5  Operating system access control

Operating system access control facilities and utilities (such as user authentica
passwords, recording use of privileges and system security alarms) should be u
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 accordanc

Particularly sensitive applications may require dedicated (isolated) platforms, an
platforms.

11.7  Mobile computing and teleworking

There should be formal policies covering the secure use of portable PCs, PDAs
(“working from home”, “road warriors” and other forms of mobile or remote wo

Section 12: Information systems acquisition, development and main

Information security must be taken into account in the Systems Develop

specifying, building/acquiring, testing, implementing and maintaining IT system

12.1  Security requirements of information systems

Automated and manual security control requirements should be analyzed and

stage of the systems development or acquisition process, and incorporated in
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 authentica
associated integrity risks.

12.3  Cryptographic controls

A cryptography policy should be defined, covering roles and responsibiliti

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

12.5  Security in development and support processes

Application system managers should be responsible for controlling access

environments.  Formal change control processes should be applied, including te
should ideally not be modified. Checks should be made for information leaka
Trojans if these are a concern. A number of supervisory and monitoring
development.

12.6  Technical vulnerability management

Technical vulnerabilities in systems and applications should be controlled b

relevant security vulnerabilities, and risk-assessing and applying relevant securi

Section 13: Information security incident management

Information security events, incidents and weaknesses (including near-miss

properly managed.

13.1  Reporting in information security events and weaknesses

An incident reporting/alarm procedure is required, plus the associated respo

should be a central point of contact, and all employees, contractors
responsibilities.

13.2 Management of information security incidents and improvements

Responsibilities and procedures are required to manage incidents consistently a

improvement (learning the lessons), and to collect forensic evidence.
 

Section 14:  Business continuity management

This section describes the relationship between IT disaster recovery planning

contingency planning, ranging from analysis and documentation through to
These controls are designed to minimize the impact of security incidents that
noted elsewhere in the standard.

Section 15:  Compliance

15.1  Compliance with legal requirements

The organization must comply with applicable legislation such as copyright, dat
and other vital records, cryptography restrictions, rules of evidence

15.2  Compliance with security policies and standards, and technical compl

Managers and system owners must ensure compliance with security policies and
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 syste

also be protected against unauthorized use.

Possible areas for revision

Potential revisions to ISO/IEC 27002 have been discussed on the

suggestions:

1. Section 4 on "Risk assessment and treatment" is particularly weak.

relevant content from ISO/IEC 27005 and emphasise the importance of risk an
PDCA.  [Some have suggested that the risk assessment activities are part of th
be covered in ISO/IEC 27001 not ’27002.]
2. New ISO27k standards (e.g. ISO/IEC 27000, ’27003, ’27004, ’27007
’27002 is updated.
3. Section 5 on "Security policy" is confusing.  Terms such as 'overarching securit
more detailed policies are needed covering particular security requirements a
 discussion on this point in Beijing but the resolution is unclear at this point.]
4. Section 7.1.2 on "Ownership of assets" should expand on the concept of 'pers
There is also some confusion around the use of 'information assets' - is this IT
something else?  [Again there was a lot of discussion in Beijing and we await t
5. Section 9.2 does not cover typical computer room 'environmental protection'
environmental monitoring with local and remote alarms (for fire, water, intrus
presumably other ISO/IEC standards in this area, as well as national standards
mentioned.
6. Section 10 is a bit of a mixed bag, covering issues such as outsourcing/3rd part
and network management.  Some rationalisation of these items may be appro
information" seems outdated, with a lot going on these days in terms of mobi
etc.  [In Beijing, a radical restructuring of ’27002 was proposed but we had ins
during the meeting, so this major issue was held over until the next SC27 mee
7. Section 11.2 on "User access management" ought to include more on identific
remote users, federated identity management etc.
8. Section 11.4 covers "Network access control" without mentioning the term "fi
some specific reason but maybe we have the opportunity to reconsider.
9. Section 12 does not explicitly cover security testing of new/changed applicatio
Pragmatic advice on security testing would be worthwhile, covering issues suc
the security elements of system specifications (e.g. using boundary conditions
unstructured testing (penetration testing and so on).
10. Section 14 on "Business continuity management" says very little about specify
particularly the need to consider and if necessary provide or improve resilienc
section would also benefit from more explanation of "contingency", namely p
incidents that arise if/when other controls fail.
11. Various changes may be needed in section 15 to reflect legal and regulatory ch
discovery", document/email retention and increasing use of computer data as
12. Section 15.3 "Information systems audit considerations" merely covers securin
auditing in reviewing and making improvement suggestions for the ISMS shou
of Legal, Risk, Compliance and Governance specialists in the ISMS design and o
or elsewhere.

ISO/IEC 27002 ISMS implementation guidance

A collection of ISMS implementation guidelines and sample documents

Toolkit, and implementation tips are sprinkled liberally throughout the

ISO/IEC 27003 provides generic ISMS implementation guidance.

guidelines follow, starting with ISO/IEC 27011 for the telecomms sector (relea
in progress) providing guidance for the financial services sector (banks, insu
gives ISMS implementation guidance for the healthcare sector.  Guidelines for
by JTC1/SC27.

Other resources

The State of California State Information Security Office’s 43-page

Agencies is, in effect, a guideline on implementing ISO/IEC 27002 for U
template ‘acceptable use’ policy for example.  The State also offers a range of
for small/simple, medium and large/complex entities, and a guide to the
officer.