The second step in the ISO27001 risk assessment process is to identify the threats to the identified assets. The third step is to identify the vulnerabilities those threats might exploit. Threats and vulnerabilities go together and, for that reason, we are addressing them together in this chapter.
The difference between ‘threats’ and ‘vulnerabilities’ is not always immediately clear to people new to the subject and, as a risk assessment process is implemented within an organisation, it will not be immediately clear to everyone involved in it. It is very important to always differentiate clearly between these two attributes of a risk, because the existence of the risk itself is dependent on the co-existence of a threat and a vulnerability.
The simple difference is this:
• vulnerabilities are flaws or weaknesses in an asset, whereas,
• threats can accidentally trigger or intentionally exploit a vulnerability to compromise some aspect of the asset.
The first thing to remember is that there are very many threats that have absolutely no relevance to many organisations. A simplistic example would be an organisation that has no Internet connectivity: it can be blithely unconcerned with the huge array of Internet-based threats, because there is no vector that those threats can exploit to attack the network and, therefore, it has no exposure to them.
The moment that it connects to the Internet, it does need to be concerned; the point of connection is by definition a possible point of vulnerability and, therefore, an area where controls might be required. As we shall see later, control selection should depend on the organisation’s assessment of the likelihood and potential impact of specific Internet threats and should be focused on trying either to reduce the level of the threat or to reduce the extent of the vulnerability.
Threats, in other words, are external to information assets, and vulnerabilities are typically attributes of the asset – aspects of the asset that the threat can exploit. While threats tend to be external to the assets, they are not necessarily external to the organisation. The majority of information security incidents today originate within the organisation’s secure perimeter.
The range of threats includes: hostile outsiders, such as hackers, non-hostile outsiders, such as suppliers or cleaning contractors, and insiders, both the disaffected and the committed, but also the careless or just the poorly trained. Vulnerabilities are security weaknesses in the existing systems, which can either be exploited by threats or which allow damage, accidental or otherwise, to information assets.
For example, dropping a laptop is a threat to the asset (the laptop), and the vulnerability exploited by that could be the lack of robustness in the laptop’s design. Similarly, a liquid spillage may be a threat to a laptop and the vulnerability would be its lack of keyboard waterproofing.
For each of the assets within the scope of the ISMS, it is necessary to identify the potential threats and the possible vulnerabilities. The essential relationship, from an information security point of view, between threats and vulnerabilities leads us to think of them as ‘combinations’. We’re not concerned with either threats or vulnerabilities on their own, but with them in combination. We therefore speak of ‘threat-vulnerability combinations’. There are a number of threat-vulnerability combinations that apply to any one asset, and any one threat typically may have more than one vulnerability that it can exploit. It should also be noted that a threat to one asset is not necessarily a threat to another. For example, a fire in the server room is a threat to a number of systems based there, but is unlikely to be a threat to an organisation’s externally-hosted mobile phone network.
There are very many threats and the range of possible vulnerabilities is also substantial. Examples of threats and vulnerabilities are contained in ISO27005, BS7799-3 and NIST SP 800-30. Whilst threat and vulnerability databases are not widely available, any good risk assessment tool should contain both.
Some threat-vulnerability combinations will be unique to specific industries, which may lead to the introduction of controls additional to those in ISO27001 Annex A. Many of the threats and their related vulnerabilities will also be technical in nature. Technical vulnerabilities need special treatment, and these are further discussed below.
The requirements of the standard are as follows:
As we’ve said, threats45 are things that can go wrong or that can ‘attack’ the identified assets. They can be either external or internal. Examples might include fire or fraud, virus or worm, hacker or terrorist. Threats are always present for every system or asset – because it is valuable to its owner, it will be valuable to someone else. You could assume that, if you cannot identify a threat to an asset, that it is not really an asset. So the next stage, mandated by ISO27001, is to identify the potential threats to the systems and assets listed in compliance with A.7.1.1, and identified in the previous chapter.
Essentially, threats for each of the systems should be considered under the headings of:
• threats to confidentiality,
• threats to integrity, and
• threats to availability.
Some threats will fall under one heading only, others under more than one. It is important to have carried out this analysis systematically and comprehensively, to ensure that no threats are ignored or missed. The quality of the controls that the organisation eventually implements will reflect the quality of this exercise, and of the overall risk assessment.
A number of external threats might be classified under all three headings. A hacker might be able to steal confidential data and then disrupt the information system so that data is no longer available or, if it is, it is corrupted. A virus can not only affect the integrity and availability of data but also, because it could mail out a copy of an address book, confidentiality as well. A business interruption, such as a fire in the server room, or a filing cabinet, is initially likely to affect the availability and integrity of information.
Identify, on an individual basis, threats to the confidentiality, integrity and availability of every asset within the scope of the ISMS. You can do this through a brainstorming exercise or by using an appropriate threat database; technical expertise is essential if the threat identification step is to be carried out properly.
It is, as we’ve said, likely that an individual threat may appear against a number of assets but, crucially, ISO27001 requires the ISMS to be erected on the foundation of a detailed identification and assessment of the threats to each individual information asset that is within the scope. From a practical point of view, if a number of assets fall within the same class and are exactly the same (e.g. desktop computers that have the same hardware specifications, software build, connectivity configuration and user exposure) they might be considered a group of assets and the subsequent phases of this exercise could be carried out treating them on that basis. Where there is any doubt or uncertainty, however, resort to assessing threats on an individual asset basis.
Vulnerabilities46 leave a system open to attack by something that is classified as a threat, or allow an attack to have some success or greater impact. For example, for the external threat of ‘fire’, a vulnerability could be the presence of inflammable materials (e.g. paper) in the server room. In the language of ISO27001, a vulnerability can be exploited by a threat.
The next stage in the assessment process, therefore, is to identify – for every single one of the assets that you have identified and for each of the threats that you have listed alongside each of the assets – the vulnerabilities that each threat could exploit. Clearly, a single asset could face a number of threats, and each threat could exploit more than one vulnerability.
A common question is: Should we identify vulnerabilities with or without those controls that are currently in place? Does the fact, for instance, that we have a firewall mean that we do not have a vulnerability to hacking attacks?
The correct answer is that you should do both. You should identify the vulnerability that would be exploited by the threat if you didn’t have any controls in place, because you want to assure yourself that those controls which are in place are appropriate for the identified risks (in some cases, implemented controls are in excess of those identified as actually required in the light of the assessed risks and the organisation’s risk appetite). You also want to identify the controls that are currently in place, and you want to be in a position to identify any residual risk (see Chapter 13), in order to consider whether or not additional controls may be required. Those controls that are already in place will be operated as part of the organisation’s ISMS and the confirmation that they are appropriate controls, and are to be retained, must come from the formal risk assessment.
Many of the threats related to information technology arise because of technical vulnerabilities. A number of information systems are sold with in-built and widely known vulnerabilities. All wireless (WiFi) products, for example, are designed to communicate ‘out of the box’ with one another and, therefore, come without any security settings configured. Routers and other access control units come with default password settings that are widely known. All software has imperfections, and the more complex the software, the more imperfections it will have. Each imperfection is a potential vulnerability. CVE47 identifies in excess of 23,000 unique, standardised names of vulnerabilities and security weaknesses. Bugtraq48 has over 700 pages listing publicly-known software vulnerabilities, across all operating systems and applications.
Attacks are often devised to exploit specific vulnerabilities.49 An increasing number of attacks are made before patches are available, and exploit code for many of the most popular attacks is commonly available on the Internet. Many attacks are automated and indiscriminate (geographically, sectorally and size-wise) in their target selection. Integrity and availability of data are, often, more likely to be compromised by these threat-vulnerability combinations than is confidentiality. The SANS Top Cyber Security Risks50 is a list of the most popular current attacks on information systems.
Your risk assessment should not, however, attempt to individually identify every single one of these threat-vulnerability combinations. There are too many of them. New ones are constantly appearing while old ones continuously evolve. What you should do is identify the generic threat (hacking, malicious code or malware) and the generic vulnerability (software weaknesses), with a generically high likelihood and a medium or high impact.
The control that you would apply is the generic control A.12.6.1 (Control of Technical Vulnerabilities). The baseline implementation of this control should be to ensure that all vulnerabilities identified in the SANS Top Cyber Security Risks are secured. Thereafter, appropriate external vulnerability or penetration tests should be run on a regular basis (weekly, monthly or quarterly – depending on your risk assessment), to identify whether or not newly identified vulnerabilities have appeared in the software deployed on your network, and these should be patched to a priority determined by their potential risk.
Today’s combination attacks, and the growing usage of Trojans and key loggers, suggests that external vulnerability testing should be combined with some form of software scanning, this side of your secure perimeter, to discover whether or not any malware that has the potential to open your network to the outside has installed itself on the inside.
45 ISO27001 clause 4.2.1 – d2.
46 ISO27001 clause 4.2.1 – d3.
47 CVE, the Common Vulnerabilities and Exposures dictionary, is at http://cve.mitre.org.
48 Bugtraq is at www.securityfocus.com/vulnerabilities.
49 There is a description, in Chapter 13 of IT Governance: A Manager’s Guide to Data Security and ISO 27001/ISO 27002, Alan Calder and Steve G Watkins (Kogan Page, 2007), of malware; Chapter 18 of that book deals with hackers and their various motivations.
50 Published by the SANS Institute, at www.sans.org/top-cyber-security-risks
18.119.158.74