Example of Risk Analysis Methodology

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:
  • Web Application of book selling.
  • Enterprise mail for contact with clients and doubts resolution.
  • Billing application.
• Process of book purchase to the wholesaler:
  • Web Application of book selling. (the app send a command directly to wholesaler using the corporate mail server)
  • Mail Server
• Process of book delivery to the client:
  • Web Application of book selling. (the app send a command to the courier for pick up the book and deliver it to the client).
  • Mail Server

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:

• System A (Linux + Apache)
• System B (Windows XP)
• System C (Windows 2008 Server)

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