ISO 27001 RISK ASSESSMENT:

HOW TO MATCH ASSETS, THREATS AND VULNERABILITIES

HOW TO DOCUMENT THE RISK IDENTIFICATION

• To make your risk assessment easier, you can use a sheet with assets, threats and
vulnerabilities in columns;
• you should also include some other information like risk ID, risk owners, impact and
likelihood, etc.
• I found it the easiest to start listing items column by column, not row by row – this
means you should list all of your assets first, and only then start finding a couple of
threats for each asset, and finally find a couple of vulnerabilities for each threat.
 RELATIONSHIP BETWEEN ASSETS, THREATS AND
VULNERABILITIES

So, let’s see what this matching of the three components could look like – for example:
• Asset: paper document:
 threat: fire; vulnerability: document is not stored in a fire-proof cabinet (risk related to the loss of
availability of the information)
 threat: fire; vulnerability: there is no backup of the document (potential loss of availability)
 threat: unauthorized access; vulnerability: document is not locked in a cabinet (potential loss of
confidentiality)
 Continued
• Asset: digital document:
 threat: disk failure; vulnerability: there is no backup of the document (potential loss of availability)
 threat: virus; vulnerability: anti-virus program is not properly updated (potential loss of
confidentiality, integrity and availability)
 threat: unauthorized access; vulnerability: access control scheme is not properly defined (potential loss
of confidentiality, integrity and availability)
 threat: unauthorized access; vulnerability: the access was given to too many people (potential loss of
confidentiality, integrity and availability)
• Asset: system administrator :
 threat: unavailability of this person; vulnerability: there is no replacement for this position (potential
loss of availability)
 threat: frequent errors; vulnerability: lack of training (potential loss of integrity and availability)
HOW MUCH IS ENOUGH?
• Very often people ask me – how many risks should they identify? If they start being
really thorough, for each asset they could find 10 threats, and for each threat at
least 5 vulnerabilities – this is quite realistic, isn’t it?
• Now if you are a small company with 50 assets, this would mean you would end up
with 2,500 risks, which would probably be overkill for this size of a company. This is
why you should focus only on the most important threats and vulnerabilities, while
including all the assets; that would mean that per each asset you should identify on
average 5 threats, and for each threat on average 2 vulnerabilities. This way you
would end up with 500 risks for a smaller company with 50 assets, which is quite
manageable.
WHY IS THIS METHODOLOGY STILL GOOD?

• I personally like this assets-threats-vulnerabilities methodology quite a bit –

not that I’m nostalgic for the 2005 revision of ISO 27001, but I think this
methodology gives a good balance between doing the risk assessment
quickly, and at the same time doing it both systematically and detailed
enough so that one can pinpoint where the potential security problem is.
• And this is what risk assessment is really about: find out about a potential
problem before it actually happens. In other words, ISO 27001 tells you:
better safe than sorry.
 CATALOGUE OF THREATS & VULNERABILITIES
This list of threats and vulnerabilities can serve as a help for implementing risk assessment within the framework of ISO
27001 or ISO 22301. This list is not final – each organization must add their own specific threats and vulnerabilities that
endanger the confidentiality, integrity and availability of their assets.
THREATS
Below is a list of threats – this is not a definitive list, it must be adapted to the individual organization:
• Access to the network by unauthorized • Eavesdropping • Misuse of audit tools
persons • Embezzlement • Pollution
• Bomb attack • Errors in maintenance • Social engineering
• Software errors
• Bomb threat • Failure of communication links • Strike
• Breach of contractual relations • Falsification of records • Terrorist attacks
• Breach of legislation • Fire • Theft
• Compromising confidential information • Flood • Thunderstroke
• Concealing user identity • Fraud • Unintentional change of data in an information
• Damage caused by a third party • Industrial espionage system
• Damages resulting from penetration testing • Information leakage • Unauthorized access to the information system
• Unauthorized changes of records
• Destruction of records • Interruption of business processes • Unauthorized installation of software
• Disaster (human caused) • Loss of electricity • Unauthorized physical access
• Disaster (natural) • Loss of support services • Unauthorized use of copyright material
• Disclosure of information • Malfunction of equipment • Unauthorized use of software
• Disclosure of passwords • Malicious code • User error
• Misuse of information systems • Vandalism
VULNERABILITIES
Below is a list of vulnerabilities – this is not a definitive list, it must be adapted to the individual
organization:
• Complicated user interface
• Default passwords not changed
• Disposal of storage media without deleting
data
• Equipment sensitivity to changes in voltage
• Equipment sensitivity to moisture and
contaminants
• Equipment sensitivity to temperature
• Inadequate cabling security
• Inadequate capacity management
• Inadequate change management
• Inadequate classification of information
• Inadequate control of physical access
• Inadequate maintenance
• Inadequate network management
• Inadequate or irregular backup
• Inadequate password management
• Inadequate physical protection
• Inadequate protection of cryptographic
keys
• Inadequate replacement of older
equipment
• Inadequate security awareness
• Inadequate segregation of duties
• Inadequate segregation of operational
and testing facilities
• Inadequate supervision of employees
• Inadequate supervision of vendors
• Inadequate training of employees
• Incomplete specification for software
development
• Insufficient software testing
• Lack of access control policy
• Lack of clean desk and clear screen policy
• Lack of control over the input and output
data
• Lack of internal documentation
• Lack of or poor implementation of internal
audit
• Lack of policy for the use of cryptography
• Lack of procedure for removing access
rights upon termination of employment
• Lack of protection for mobile equipment
• Lack of redundancy
• Lack of systems for identification and
authentication
• Lack of validation of the processed
data
• Location vulnerable to flooding
• Poor selection of test data
• Single copy
• Too much power in one person
• Uncontrolled copying of data
• Uncontrolled download from the Internet
• Uncontrolled use of information systems
• Undocumented software
• Unmotivated employees
• Unprotected public network connections
• User rights are not reviewed regularly
 What are assets according to ISO 27001?
 First, let’s clarify what assets means in the context of ISO 27001 – funny enough, neither the new 2013 revision of ISO/IEC
27001, nor the 2014 revision of ISO/IEC 27000 gives a definition of assets, but the 2005 revision of ISO/IEC 27001
defines an asset as “anything that has value to the organization.”
 Since ISO 27001 focuses on preservation of confidentiality, integrity and availability of information, this means that assets
can be:
• Hardware – e.g. laptops, servers, printers, but also mobile phones or USB memory sticks.
• Software – not only the purchased software, but also freeware.
• Information – not only in electronic media (databases, files in PDF, Word, Excel, and other formats), but also in paper and
other forms.
• Infrastructure – e.g. offices, electricity, air conditioning – because those assets can cause lack of availability of information.
• People are also considered assets because they also have lots of information in their heads, which is very often not
available in other forms.
• Outsourced services – e.g. legal services or cleaning services, but also online services like Dropbox or Gmail – it is true that
these are not assets in the pure sense of the word, but such services need to be controlled very similarly to assets, so they
are very often included in the asset management.
Why are assets important for information security management?
• 1) Assets are usually used to perform the risk assessment – although not mandatory by
ISO 27001:2013, assets are usually the key element of identifying risks, together with
threats and vulnerabilities. See also ISO 27001 risk assessment & treatment – 6 basic
steps.
• 2) If the organization doesn’t know who is responsible for which asset, chaos would
ensue – defining asset owners and assigning them the responsibility to protect the
confidentiality, integrity and availability of the information is one of the fundamental
concepts in ISO 27001.
• This is why ISO 27001:2013 requires the following: an inventory of assets needs to be
developed (A.8.1.1), owners of the assets need to be nominated (A.8.1.2), and
acceptable use of assets must be defined (A.8.1.3).
 How to build an asset inventory?
• If you didn’t develop your asset inventory previously, the easiest way to build it is during the initial risk assessment process (if
you have chosen the asset-based risk assessment methodology), because this is when all the assets need to be identified,
together with their owners.
• The best way to build asset inventory is to interview the head of each department, and list all the assets a department uses.
The easiest is the “describe-what-you-see” technique – basically, ask this person e.g. to list all the software that he or she
sees that are installed on the computer, all the documents in their folders and file cabinets, all the people working in the
department, all the equipment seen in their offices, etc.
• Of course, if you already do have some existing asset inventories (e.g. fixed asset register, employee list, licensed software
list, etc.), then you don’t have to duplicate those lists – the best would be to refer to your other lists from your information
security Asset register.
• ISO 27001 does not prescribe which details must be listed in the asset inventory – you can list only the asset name and its
owner, but you can also add some other useful information, like asset category, its location, some notes, etc.
• Building the asset register is usually done by the person who coordinates the ISO 27001 implementation project – in most
cases, this is the Chief Information Security Officer, and this person collects all the information and makes sure that the
inventory is updated.
 Who should be the asset owner?
• The owner is normally a person who operates the asset and who makes sure the information related to this
asset is protected. For instance, an owner of a server can be the system administrator, and the owner of a
file can be the person who has created this file; for the employees, the owner is usually the person who is
their direct supervisor.
• For similar assets used by many people (such as laptops or mobile phones), you can define that an asset
owner is the person using the asset, and if you have a single asset used by many people (e.g. an ERP
software), then an asset owner can be a member of the board who has the responsibility throughout the
whole organization – in this case of ERP, this could be the Chief Information Officer.
• Read also Risk owners vs. asset owners in ISO 27001:2013.
• So, the point is – building an asset register can seem like a bureaucratic job with not much practical use,
but the truth is that listing assets helps clarify what is it valuable in your company and who is responsible
for it. And, without knowing what you have and who is in charge, don’t even think that you will be able to
protect your information.