Risk Management - Case Study.

In this step is foundamental the interaction with the customer that is the expert of the domain. We have to ask questions to the customer to know which are the laws currently applicable. Conserning the external context, given the fact that the smart grid is part of a critical infrastructure it is subject to a number of national laws and regulations. For the assesor is foundamental to identify a document these laws and regulations; so a failure to comply may have significant legal and financials consequences. In estimating the impact is important to consider those consequences.

In europe they have to follow the NIS directive and in particular in italy the critcal infrastructure are part of the National Cybersecurity Border, so they have to follow additional rules.

Regarding the internal context, we have to understand the business aspects, how the system works and which are the components to protect and how to map them to the business part of the company. The first thing to consider is the mission of our customer.

The mission is composed of different subactivities:

• The service must be reliable. (availability)
• Exchange correct and timely information with the customer at all the times so that they can be charged the right amount.
• Protect the privacy of the customer.

An additional information provided is that internally most of the employees are technical skilled but few of the staff have received training in risk assesment.

The customer is asking to: assess the risk with respect to the business continuity, so the capability to provide the right service to the customer, verify the law and regulation compliance, especially in the treatment phase, (some fixes may not be possible) and lastly improve the situation awareness to increase the overall level of awareness of the employees.

We have to map the technical part to the business aspect of the company.

The system is composed by to parts, one running on the distributor side and another on the customer side. The two components exchange information using two communication methods: internet and GPRS for redundance reasons.

• Central System is the part of the system that exchange information.
• Distribution Management System is the part that manage the application logic of the infrastructure.

We need to identify which are the possible boundaries of the cyber space: what is installed locally plus what is installed on the operator side; the attacker could be in the internet, in the GPRS network and can try to attack from the distibution side or the customer side.

We have to scope the assesment and focus just on a particular part of the system, in these example we’ll focus just on the subset of the system that talks over the internet; and limit the attention only to the attacks that may comes from the internet without to consider the ones from the back-end side.

Assets	Description
Integrity of meter data	The integirty of meter data should be protected all the way from power meter to distribution system operator.
Availability of meter data	Meter data form metering node should be available for distribution system operator at all the times
Provisioning of power to electricity customer	Power should only be switched off or choked as a result of a legitimate control signals from Central systems

The likelihood scale should allow the analyst to measure the probability of the occurence of the incident. We can decide to consider the frequency over a particular time window.

Value	Description
Rare	Less than once per ten year
Unlikely	Less than once per two year
Possible	Less than twice per year
Likely	Two to five times per year
Certain	Five times or more per year

We are using a quanlitative scale because we are consdering very huge time windows, and because it helps to mange a degree of uncertainty.

Of course the granularity of the chosen scale depends on the availability of data and the preferences of the decision makers.

This scale should measure how the incident will impact the assets, so it depends on the asset. A consequence scale for every asset must be defined.

The last step of context establishment is to construct a risk matrix using the likelihood and consequence scale for each asset:

First of all we have to understand who may want to initiate attacks and why; the potential for causing harm will depend on the motive and the intention of the threat sources, their capabilities and resources.

The first thing to do is to undestand who may want to create damage to the system, we need to consider the context that we are assessing and evaluate the possible motivations, their capabilities and their avaialable resources. It is fundamental to produce documentation for all of the aspects considered to use them to compute the likelihood of an incident.

In this phase we’ll produce the same table but we’ll start from the incident identification.

Given the table that relates threat sources to the threats we compute the OWASP score for each row, considering the Script Kiddie:

Considering the cyber terrorist that triest to perform a DDoS we’ll have a different OWASP table output:

We need to map the numerical values over a qualitative scale of the likelihood:

The numbers should be verified based on the logs and the data available, so we can adjust the numerical value considering historical data. At the end we’ll have the following table:

The same process must be done for the non-malicious case, in this case having no specific threat source we’ll note use OWASP (we cant score all the four attributes). The approach used will be based on the historical data, via interviews and experience. Considering this table:

we’ll compute the likelihood of each row.

We can use a simple scale composed by three interval to perform vulnerability analysis. The information sources can be experts of the domain, vulnerability scans, security testing, pen testing and code review. Using an inspired OWASP risk rating method:

to analyze the following vulnerabilities:

1. Inadequeate attacj detection and response
2. Weak encyption and integrity check
3. Unportected local network
4. Outdated antiviruses
5. Four-eyes principle not implemented, no logging actions of individual central system operator.

Considering (1):

At the end we’ll obtain:

In this case the result of non malicious risk identification is used to identify different vulnerabilities. In the example we identifyied:

1. Single communciation channel between central system and metering terminal
2. Poor testing
3. Poor training and heavy workload
4. Inadequate overvoltage protection

In this case the assesment is done analysisng the environment and making consideration over the processes in place. For each vulnerability a rationale is presented togheter with the severity:

We’ll review one by one all the incidents taken from the table that relates the incident to the threat. For each row we’ll compile the following table:

Of course we can consider historical data, togheter with trend data, and adjust the value on the likelihood scale.

The same should be done for non malicious threats, for example, considering:

obtaining the table after some correction that are made considering historical data and similarities between the two incidents to produce a more precise output:

We must consider the consequence of an incident for each asset it harms, the consequence scale is tailored to each asset. Considering the first incident:

we review the historical data to produce a better output and then we score it. At the end we’ll produce something like this:

We need to ensure that the values associated to every risk are indeed correct. We will reconsider all the risks taking into account the possible uncertainties. The central question is not wheter each likelihood and consequence estimate is correct, but rather wheter the resulting risk level is correct. In some cases th euncertainty may change the evaluation of the risk:

Another consideration may regards if there is any risk that is both malicious and non malicious, and if this relationship moves the risk inside the risk matrix. The last thing to do is to verify if both malicious and non-malicious threat sources where considered in the right way.

Malicious:

Non-Malicious:

For all the risks present in a border color zone we may need to revise them considering uncertainties. In the non-malicious case we assume that there is no particular bias and so we can proceed to the next phase.

There are two kind of aggregation that we can perform:

1. One incident creates damange to twp different assets. The same incident will create two times the problem of an incident that harms just a single asset. In this case the likelihood of the aggregated risk remains the smae but the impact of the incident will change, and is the joint impact of the two risks, the maximun of the two or the sum. Which function to use depends on the context considered.
2. Two incident that impact the same asset. Two independent events may ahappen, if they happen togheter the impact could be huge. If the incidents are of the same time (generated by the same threat source) or if the occurrence of the two incidents are triggered by the same threat. This case is more difficoult to consider, because we have to uderstand how to change the likelihood and the impact. We need to look at the semantic of the incident and to the specific threat to produce data accordingly.

The same type of incident due two different threat sources (a malicious and a non malicious); so the risk can be generalised defining a more general case and adjusting the consiquence and the likelihood.

Similar consideration can be done for different risks, producing the following risk matrix:

In this phase we observe that several risks may benefint from the same treatment. For example:

If the vulnerability is resolved both of them could be resolved. The risk matrix will be adjusted in accordance to different considerations:

The system remains in the system without doing anythign: tradeoff between mitigation cost and indirect cost of the incident. It is fundamental to identify the correct tradeoff. We can opt for a qualitative or a quantitative analysis. Given a risk and a treatment; then perform some considerations:

• The treatment can prevent the threat?
• The treatment makes possible early detection, thus reducing the likelihood of a full incident?
• In addition a fast response implies a reduction of the attack consequence.

A mitigation that moves a red risk to the green zone is worth considering from the benefit point of view, then we have to consider the cost dimension. For each risk we’ll produce a pair: benefit, cost.