CHAPTER 8: INFORMATION ASSETS

The information security policy and the scoping statement, discussed in Chapter 6, describe the boundaries of the ISMS. You have to consider, at a reasonably high level, the information assets that underpin the organisation’s business processes in order to establish the scope of the ISMS. You now return to the subject, but this time the objective is to identify all those assets in detail.

Assets within the scope

The first step in meeting the ISO27001 requirements for risk assessments is to identify all the information assets (and ‘assets’ includes information systems – which should be so defined in your information security policy) within the scope (4.2.1 – a) of the ISMS and, at the same time, to document which individual and/or department ‘owns’ the asset. We discuss, in Chapter 10, the valuation of assets, particularly in relation to their business, legal/regulatory and contractual requirements.

This asset identification exercise can only take place once the scope – discussed in Chapter 6 – has been finalised.

Asset classes

ISO27002 identifies, in A.7.1.1, the six classes of assets that have to be considered, each of which should be referenced in your information security policy statement. These asset classes include the asset types we discussed in Chapter 6 and should frame your asset identification exercise. They are as follows:

There should be a link between this inventory and the organisation’s fixed asset ledger and/or its configuration management database (CMDB), and the sensitivity classification (as required by ISO27001 Annex A clause 7) of every asset, together with details of its owner, which should be recorded as well.

One of the exercises that we do in our Masterclasses⁴¹ is to analyse the information assets that are contained on the average workstation or laptop. These are likely to include, apart from the hardware itself (and, possibly, various peripheral hardware items such as keyboards, mice, etc.) the operating system, individual applications such as e-mail software, word processing and spreadsheet software, and a number of other specific applications, as well as databases, customer records, other contact records, copies of important information, files, folders, e-mail databases, and so on. Each of these assets may have a different classification level, and not all of the assets will necessarily be owned by the user of the workstation.

The objective of the corporate asset identification exercise is to analyse assets down to the level of granularity suggested by our training exercise. A usual starting point is with the key corporate information systems or bodies of information. A system consists of a number of components. A single data asset (such as a file, whether electronic or paper) is a component of a system.

These systems will include a number of IT systems (e.g. client relationship management system, payroll system, e-mail system, resource planning system, accounting system, etc.), the telecommunications systems and the paperwork filing systems. The risk analysis team should list the key systems throughout the organisation; there are software tools (for network mapping and software asset management, for instance) that can be used to ensure that all the data assets and all the IT systems have been identified. It might be necessary to deploy software tools to identify all the hardware and software that actually makes up the corporate infrastructure.

Telecommunications systems might include mobile phones as well as desk-based systems; personal digital assistants are as important a component of the IT system as are the remote access points and sub-contracted services.

The human resources filing system is as important as that used in the Chief Executive’s or Chairman’s office. All systems need to be identified and if, in the process of doing this, there are found to be significant sharings of assets or information sharings that were not identified earlier, then the scope of the ISMS may need to be revisited.

Grouping of assets

In most circumstances, it will be beneficial to group individual items and to treat that group as the ‘asset’ for the purposes of risk assessment. BS7799-3⁴² says: ‘Grouping similar or related assets into manageable collections can help to reduce the effort necessary for the risk assessment process’ (clause 5.2). The key, here, is to ensure that the aggregation of assets into groups does not override the benefit of identifying threats and vulnerabilities at an individual asset level. For instance, it would not be helpful to aggregate all operating systems if the organisation’s operating systems include multiple versions of Windows (e.g. NT4, Windows 2000 and Windows Vista) together with Linux and/or Unix, because the vulnerabilities – and therefore the threats – are likely to be different for each. Conversely, looking at all installations of Windows Vista together may be a sensible aggregation.

ISO27002, 7.1.2 identifies another such circumstance:

In complex information systems, it may be useful to designate groups of assets, which act together to provide a particular function, as ‘services’. In this case, the service owner is responsible for the delivery of the service, including the functioning of the assets, which provide it.

Asset dependencies

In some cases, the dependency of one asset on another might affect the valuation of both assets and these dependencies should be identified during this phase of the project. For instance, if the integrity of data output from a program depends on the integrity of the data input, then the value of the second depends on that of the first. The integrity of the data might also be dependent on the availability of the power supply and the air conditioning. The confidentiality requirements of a specific data asset might require other assets, in which it is manipulated or stored, to be protected to a higher degree than might otherwise be the case.

ISO13335-3 (now withdrawn) provided helpful guidance here. Its suggestion is still useful:

Asset owners⁴³

Every asset must have an owner and this is reflected in Annex A control requirement A.7.1.2 (Ownership of Assets). In this instance the term ‘owner’ doesn’t convey legal ownership of the asset to the individual and is defined (4.2.1 – d1, footnote 2) as the ‘individual or entity that has approved management responsibility for controlling the production, development, maintenance, use and security of the assets’. This could, therefore, be a system administrator or a manager who is responsible for defining how an asset or group of similar assets is used.

The owner of the asset is the person – or part of the business – who is responsible for appropriate classification and protection of the asset. In real terms, allocating ownership to a part of the organisation can be ineffective, unless that part has a clearly defined line of responsibility and individual accountability in place.

It is important to recognise that there may be a number of assets that have users, or custodians, who are not the nominated ‘owners’ of the asset: for instance, the operating system is likely to be owned by the system administrator, but it will be deployed on workstations throughout the organisation and will be used by workstation users. The system administrator will be responsible for the security (which, remember, includes availability as well as confidentiality and integrity) whereas the users are not accountable for these aspects. It may well be that, as a result of the risk assessment, specific controls (e.g. user access agreements) are imposed on the users.

Sensitivity classification

The asset owner is also responsible for determining the sensitivity classification of the asset. Control A.7.2.1 requires every information asset to be ‘classified in terms of its value, legal requirements, sensitivity and criticality to the organization’. While there are comprehensive descriptions, elsewhere,⁴⁴ of how such guidelines should be developed and applied, there needs to be a direct relationship between the allocated sensitivity classification of an asset and the impact of its security being breached. We discuss impact valuations in Chapter 10. As a general guide, those assets that have a high impact valuation are likely to have a high sensitivity classification, although other factors may also need to be considered.

The key point to note here is that, early in the risk assessment (and, if you are using a risk assessment tool, early in the tool set-up process), you will need to define your classification guidelines and ensure that asset owners are adequately trained to apply both the guidelines and any related asset labelling scheme developed to meet the requirements of control A.7.2.2 (Information Labelling and Handling).

Are vendors assets?

We identified one of the classes of information assets as ‘services on which computer systems depend: computing and communications services, and general utilities such as heating, lighting, power and air-conditioning’. This gives rise to a simple question: are the suppliers/vendors of these essential services also assets?

There are two practical answers to this question. The best solution is probably to use a mix of the two, but in doing so it is essential that the exact approach to be used in each specific case is determined by a common set of rules. These should be defined in the risk assessment documentation.

One option is to decide that the vendor itself is not an asset – the organisation that is within the scope of the ISMS does not own the vendors – but that the services provided by the vendor and, possibly, the relationship with the vendor are both assets within the scope of the ISMS. The logic behind this option is that a relationship with a vendor can be an asset if it is a key supplier in terms of the information aspects of whatever it is they supply.

For example, a stationery supplier would not, we suggest, be a key relationship for the purposes of information security (even if you argue that without pencils you cannot write, since you can easily go and buy pencils from someone else). On the other hand, if you have invested a lot of time and effort (and hence money) in selecting, educating and building a relationship with a specific supplier, then that relationship has value to you and is therefore, by definition, an asset.

A word of warning however: it is advisable to set clear criteria for inclusion in, or exclusion of suppliers from, the risk assessment process or the process will become unmanageable. So, if it is relatively easy and cost-free to find an alternative provider for any one vendor, without compromise of confidentiality, integrity or availability, then we suggest the relationship is excluded from the asset register. You might like to set some figures for ‘relatively easy and cost-free’ so that all asset owners apply the criteria consistently when deciding to include/exclude a supplier.

For example, the service provided by a disaster recovery (DR) company is an asset. A contractual relationship with a DR company is part of a control that brings identified risks within an acceptable tolerance, and therefore, of course has value to your company – you pay for it, so it must have.

Vendors, however, bring a whole host of threats with them and these may well provide the context for how you accommodate them in your risk assessment methodology by considering the threat to other assets of them not doing exactly as you might want.

The second approach to vendors is, therefore, to consider them, or rather the danger of them not providing what you require, as a threat. For example, if you have a bespoke piece of software developed by a one-person contractor, the danger is that the one person or source of expertise to service the software becomes unavailable one way or another. This threat could exploit the vulnerability that the software may have e.g. code weaknesses or requires regular maintenance, and you should be able to determine the likelihood of the asset being compromised in this way. The impact is determined by the value of the asset to the business; consequently, the risk can be determined.

What about duplicate copies and backups?

Security breaches in respect of duplicate or backup copies will not necessarily have the same impacts as they would in respect of the originals. Duplicates are usually kept in different media or environments, and are subject to different threats from the originals. The impact on the organisation of compromise in respect of a copy might be the same as, less than or more than the original.

For instance, destruction of a backup copy of an exchange folder will not have the same impact on information availability as would destruction of the original – unless the original was already unavailable. Conversely, data confidentiality may be more easily compromised if off-premise backup tapes are attacked than if the servers are threatened. The duplicate copy of an asset must, in other words, be assessed as an asset in its own right.

An alternative approach – more suited to paper copies and digital duplicates of information assets – is to treat the existence of duplicate copies as vulnerabilities in the security of the original asset. The logic is that a photocopy, or an e-copy, will contain all the information that is in the original, but will be beyond the security perimeter devised for the original. The existence of the copy is, therefore, a vulnerability in respect of the original; one logical control is to disable all copying capability.

There is a relevant sub-question in relation to backups, which concerns the security of the various information assets that are backed up to a single source.

Backups should be considered as a specific asset. Backups are kept and generated in order to mitigate a specific risk, but the backups themselves face risks, either the same ones as the original assets they back up and/or different ones, but those risks have to be identified and mitigated. With regards to the ISMS and the information risk assessment you can treat a backup tape (say) as one asset, even though it contains duplicates of many separate assets. This makes sense as any controls applied to the backup will typically be applied to the whole, rather than sub-sections of it. Yes, it contains many assets, all of which have their own classification and impact value, but the challenge of assessing backups of each and every asset separately would be impractical and would add no real value.

The important thing to remember is that when applying controls relating to confidentiality to the individual assets that are backed up, the same degree of restriction should be applied to that part of the backup media on which they are stored – and, where a backup contains assets of varying sensitivity, the classification level appropriate to the most sensitive should be applied to all.

Identification of existing controls

ISO27001 says that the risk assessment must take account of existing controls. This means that you need to identify the controls that are in place at the point you commence your risk assessment. You do this, as ISO27005 points out, to ‘avoid unnecessary work or cost, e.g. in the duplication of a control’ (8.2.1.4) and recommends that this step should be carried out at the time of identifying the assets. This makes sense; you will find it useful to have to hand information about existing controls as you start considering threats and vulnerabilities. Information about existing controls should be included with the asset information; sensible risk assessment tools will enable you to gather this information in a format that reflects the controls contained in Annex A of ISO27001.