Introduction
The objective of this post is explain a risk analysis methodology
that I used in the past successfully in different kind of clients. It
is similar to other standard methodologies like the Spanish
Magerit or ISO31000 but it has some particularities that permits make
simply but robust analysis.
In first place let's to introduce the fictitious scenario that we will
use as example to develop this risk analysis methodology.
The company Moreculture INC, is an on-line bookshop. It is dedicated
only to shop physical books via its web page. It don't has book stock
since it buy the books directly to a vendor after each purchase.
Moreculture's CEO is aware that information security is basic for his
business, so he decided to make a risk analysis to know what risk
affects his business and what he needs to do to avoid them.
Threats
Catalog
First thing to do is prepare the catalog of threats to consider in
our analysis. What I normally do is simplify an exhaustive threat catalog as Magerit's catalog ignoring these threats that are not
relevant for our business or process to analyze. Also, I normally
group some similar threats with the objective of do the analysis as
simple as possible.
Work with a large catalog multiply the effort and the time required
to finish the risk analysis. My recommendation is don't use more than
10 threats in the analysis.
In our example case, we will consider just this 6 threats:
-
Natural Disasters
-
Users errors
-
Programming errors
-
Administration errors
-
Malware
- Intentional attack
If we group threats to simplify the analysis, is important guarantee
that all the threats categories that really could affect the business
information are included in our catalog to do a rigorous analysis
and don't underestimate relevant risks. In addition, to elaborate the catalog, we should consider the internal and external context where
the organization operates. For example, threats as fraud, theft or
industrial disaster could or not apply depending of the organization.
Following with our example, now that we have our threats catalog
defined, let's to assess the standard probability value for each
threat. This value will be the probability that we will consider by
default, but could be modify for each asset depending of its
vulnerabilities. For evaluate the probability (and the rest of
variables in the analysis) I will use a scale of 5 values. Depending
on the detailed that we want for our risk analysis we could user just
3 values or use a model with a broader scale (7, 10 or even more
values):
5- Extremely probable
4- Very probable
3- Probable
2- Unlikely
1- Negligible probability
Thus, our catalog of threats will be as follows (in brackets the
dimension or dimensions that can affect the threat):
Natural Disaster (Availability): 1
Users Errors (Confidentiality, Integrity, Availability): 4
Programming errors (Confidentiality, Integrity, Availability): 3
Administration errors (Confidentiality, Integrity, Availability): 3
Malware (Confidentiality, Integrity, Availability): 5
Intentional attacks (Confidentiality, Integrity, Availability): 4
Process Map
Now that we have our threat catalog defined, let's to develop our BIA
(Business Impact Analysis). For do it, if we haven't one yet, we will
need a map of our business process.
To simplify the example, we suppose that our company has just this
process, but any real company will have much more process, specially
support process. We will identify also the applications that are
supporting each of the process:
Selling book to client Process:
Process of book purchase to the wholesaler:
Process of book delivery to the client:
BIA
(Business Impact Analysis)
The first thing that we will do for elaborate our BIA is assess the
impact that we could have if the confidentiality, integrity or
availability of the information related with our business processes
would be compromise. We will do this evaluation in different areas.
Some examples of possible areas are:
Financial
Legislative / regulatory
Operating
Environmental
Damage to persons
Damage to company image or loss of customer confidence
Etc..
In our example, as some areas don't apply (environmental, people
damage, ..) we will just assess next areas:
|
|
Financial
|
Legislative /regulatory
|
|
Very Low
|
Less than 500€
|
-
|
|
Low
|
Between 500€ and 2500€
|
-
|
|
Medium
|
Between 2500 and 7500€
|
Subpoena
|
|
High
|
Between 7500 y 20000€
|
Fine or penalty
|
|
Very High
|
More than 20000€
|
License revocation
|
Let's analyze the impact for each business process:
If we analyze the sales
process's confidentiality we can see that a compromise will have a
Very High impact because the app process personal data of clients and
the Data Privacy law fines in its lower range could get 40.000€.
In legislative impact we will be in High level because we could get a
data privacy fine or penalty.
We will do the same kind of
analysis for Integrity and Availability dimensions (in availability
case we will assess the impact if the process isn't available for 1
hour, 1 day or 1 week):
|
Sales Process
|
Financial
|
Legislative
|
|
Confidentiality
|
Very High (5)
|
High (4)
|
|
Integrity
|
Very High (5)
|
High (4)
|
|
Availability
|
1 hour
|
Very Low (1)
|
-
|
|
1 day
|
Low (2)
|
-
|
|
1 week
|
Medium (3)
|
-
|
Lastly, for each dimension we select the biggest impact between the assessed categories. Our BIA will be like this:
|
|
Confidentiality
|
Integrity
|
Availability
|
|
|
|
|
1 hour
|
1 day
|
1 week
|
|
Sales
|
5
|
5
|
1
|
2
|
3
|
|
Purchases
|
1
|
5
|
0
|
0
|
1
|
|
Delivery
|
5
|
5
|
0
|
0
|
2
|
Acceptable
level of risk
With the BIA prepared we are ready
to establish which is the acceptable level of risk for our company. I
mean, where are we going to set the line that separates acceptable
risks for those requiring urgent actions for resolution. The company
sets that don't want to take risks that exceed 7,500 € or likely
would pose fines or penalties and, of course, the revocation of his
license to sell books online. So, the acceptable level of risk for
Moreculture Inc, is don't tolerate risks with a value of 4 or 5.
Inventory of
Assets and Map of Dependencies
Now, with the BIA prepared and the tolerate level of risk defined, we
need an inventory of assets and the dependencies map before to start
the risks evaluation process.
This will be our Assets inventory (simplifying, because we don't consider people or locations as assets in this example):
Applications:
Sales Web Application (APP_Sales)
Corporate mail (App_Mail)
Billing Application (App_Billing)
Data Bases:
Data base of clients (DB_clients) (SQL Server)
Data base with books master (DB_Maestro)(SQL Server)
Data base with the history of operations (DB_Operations)(SQL Server)
Systems:
All the applications are executed in System A, System B supports the
e-mail server and System C runs the SQL Server with the three data
bases.
The dependencies map will be as follow:
SALES process -> App_Sales -> System A
-> DB_Clients -> System C
-> DB_Master -> System C
-> App_Mail -> System B
-> App_Billing -> System A
-> DB_Clients -> System C
PURCHASINGprocess -> App_Sales -> System A
-> DB_Master -> System C
-> App_Mail -> System B
DELIVERY process -> App_Sales -> System A
-> DB_Clients -> System C
-> DB_Operations -> System C
-> App_Mail -> System B
-> App_Billing -> System A
-> BD_clientes -> System C
Now we will make inherit assets inherit the impact classification
under the dependency map. The result of impacts that we obtain will
be as follow:
|
|
Confidentiality
|
Integrity
|
Availability
|
|
|
|
|
1 hour
|
1 day
|
1 week
|
|
Sales
|
5
|
5
|
1
|
2
|
3
|
|
Purchasing
|
1
|
5
|
0
|
0
|
1
|
|
Delivery
|
5
|
5
|
0
|
0
|
2
|
|
APP_Sales
|
5
|
5
|
1
|
2
|
3
|
|
APP_Mail
|
5
|
5
|
1
|
2
|
3
|
|
APP_Billing
|
5
|
5
|
1
|
2
|
3
|
|
BD_Clients
|
5
|
5
|
1
|
2
|
3
|
|
BD_Master
|
5
|
5
|
1
|
2
|
3
|
|
BD_Operations
|
5
|
5
|
0
|
0
|
2
|
|
System A
|
5
|
5
|
1
|
2
|
3
|
|
System B
|
5
|
5
|
1
|
2
|
3
|
|
System C
|
5
|
5
|
1
|
2
|
3
|
Next step is take each asset of our inventory (or typology of asset
if we want simplify) and analyze if are or not vulnerable to each of
the threats identified in our catalog.
|
|
Applications
|
Data Bases
|
Systems
|
|
Natural disasters
|
Not Vulnerable
|
Not Vulnerable
|
Vulnerable
|
|
Users errors
|
Vulnerable
|
Not Vulnerable
|
Not Vulnerable
|
|
Programmers errors
|
Vulnerable
|
Not Vulnerable
|
Not Vulnerable
|
|
Administration errors
|
Not Vulnerable
|
Vulnerable
|
Vulnerable
|
|
Malware
|
Not Vulnerable
|
Not Vulnerable
|
Vulnerable
|
|
Intentional attacks
|
Vulnerable
|
Vulnerable
|
Vulnerable
|
Let us now calculate the intrinsic risk for the assets of our
inventory, ie the risk regardless of the security controls that exist
to reduce the impact or likelihood of risk. To avoid too lengthen
this post, we will make the example of a single asset: system A.
To calculate the risk we will use the following matrix as a function
of impact and likelihood. This is a fully customizable array given
depending on the type of business that is being analyzed, since in
certain sectors, it may make sense to give more weight to the impact
that to the likelihood in order to consider possible 'black swans'.
|
|
|
Impact
|
|
|
|
5
|
4
|
3
|
2
|
1
|
|
Likelihood
|
5
|
5
|
5
|
4
|
3
|
2
|
|
4
|
5
|
4
|
4
|
3
|
2
|
|
3
|
4
|
4
|
3
|
3
|
2
|
|
2
|
3
|
3
|
3
|
2
|
1
|
|
1
|
2
|
2
|
2
|
1
|
1
|
Let us see the inherent risk of our 'System A':
|
System A – Inherit
Risk
|
Impact
|
Likelihood
|
Inherent Risk
|
|
Natural disasters
|
Availability: 2
|
1
|
1
|
|
Users errors
|
Not Vulnerable
|
|
Programmers errors
|
Not Vulnerable
|
|
Administration errors
|
Confidentiality: 5
|
3
|
4
|
|
Integrity: 5
|
|
Availability: 2
|
|
Natural disasters
|
Confidentiality: 5
|
5
|
5
|
|
Integrity: 5
|
|
Availability: 2
|
| Intended attacks |
Confidentiality: 5
|
4
|
5
|
|
Integrity: 5
|
|
Availability: 2
|
Thus, we see that the risk inherent in our system is Very High (5).
Let's see what controls have implemented the system to find out what
is the actual risk:
Daily updated anti-virus signature update. (significantly reduces the
likelihood of the threat of malware).
Hosted on internal network separate from the DMZ and the Internet
via well-managed firewalls. (reduces the chance of malicious
attacks).
The company performs an annual scan of vulnerabilities, and although
in the latter showed vulnerabilities, the most critical are already
corrected. (as is annual, we decided not to further lower the
likelihood of malware or malicious attacks. If the process was at
least quarterly correcting vulnerabilities in short time, could
further reduce the likelihood of these threats).
The organization has a solid management process changes that reduce
the likelihood of administration errors and their impact, since
there is always a process for reverse the changes.
So, the effective risk of System A is:
|
System A –
Effective Risk
|
Impact
|
Likelihood
|
Inherent Risk
|
Effective Risk
|
|
Natural Disasters
|
Availability: 2
|
1
|
1
|
1
|
|
Administration errors
|
Confidentiality: 4
|
2
|
4
|
3
|
|
Integrity: 4
|
|
Availability: 2
|
|
Malware
|
Confidentiality:
5
|
3
|
5
|
4
|
|
Integrity: 5
|
|
Availability: 2
|
|
Intended attacks
|
Confidentiality: 5
|
3
|
5
|
4
|
Risk
Treatment Plan
Now that we have the risks map
(inherent and effective) for all assets of our organization, we can
elaborate the Risk Treatment Plan. With this objective, we determine
actions to do with those risks that exceed the threshold of
acceptable risk.
For each one of these risks, we have the next alternatives:
Avoid: Stop making the
activity giving rise to the risk. For example, turn off the A system
and disconnect it from the network.
Assume: Assume that you can not do anything to mitigate this risk.
This strategy may be valid when the asset is about to be discharged
or when the alternatives to reduce its level of risk are excessively
expensive and could even exceed the potential cost of the risk
occurring.
Transfer: Sometimes there are risks that can be transferred to third
parties by hiring insurance or outsourcing of certain services.
Mitigate: In most cases this will be the optimal strategy. Is to
establish or improve asset security controls to reduce risks to
acceptable levels, either by reducing the likelihood of threats or
reduce the impact these would have if they materialize.
In our example, we have two risks to treat:
|
System A
|
Impact
|
Likelihood
|
Inherent Risk
|
Effective Risk
|
|
Malware
|
Confidentiality: 5
|
3
|
5
|
4
|
|
Integrity: 5
|
|
Availability: 2
|
|
Intent Attacks
|
Confidentiality: 5
|
3
|
5
|
4
|
And the associated treatment plan could be the next one:
Increment frequency of vulnerability scans over the system scanning
it in a monthly basis.
Solve the detected vulnerabilities on the system in 2 or less
months.
Hardening the server disabling or unistalling all the unnecessary
services.
Ideally, when setting the risk treatment plan will prioritize actions
based on the risk to help mitigate and, where possible, be grouped in
transversal projects to mitigate the risks of all types of assets
rather to address them individually in each case.
After analyzing the impact these measures will have on the risks,
we can establish the residual risk level, that is the risk that will
remain effective once implemented the measures described:
|
System A – Residual Risk
|
Impact
|
Likelihood
|
Effective Risk
|
Residual Risk
|
|
Natural Disasters
|
Availability: 2
|
1
|
1
|
1
|
|
Administration Errors
|
Confidentiality: 4
|
2
|
3
|
3
|
|
Integrity: 4
|
|
Availability: 2
|
|
Malware
|
Confidentiality: 5
|
2
|
4
|
3
|
|
Integrity: 5
|
|
Availability: 2
|
|
Intended Attacks
|
Confidentiality: 5
|
2
|
4
|
3
|
I hope you enjoy and find useful this post. If you find any error or
you wish propose any improvement, please, don't hesitate to propose
it in a comment.
Twitter: @omarbenjumea
http://about.me/omarbenjumea
