Our world depends on technology almost entirely. One will have to say: Our life does not go smoothly without technical equipment and devices. That said, we must protect those devices against a various number of risks or threats. That is expensive and costly. At present risk analysis is mainly focussed on technical boxes. Every single device is protected against any risk you can think of. At least they try to do so. In the following I will sketch an approach that narrows towards the problem from the business processes point of view rather than hardware.
In that context I wonder whether there is a way to cut down costs of protective measures. What, if we could minimize areas to be protected? What, if we could decrease the number of areas to be protected? We would have to protect only one single room rather than the entire house. We would have to protect only ten houses instead of twenty. I think, the costs of our protective measures would drop dramatically.
With this process oriented approach I do not look at all technical components and their risk factors. Instead of that, I filter those parts of the process that are really important. And only the technical components that are involved in those parts have to be guarded – by all means possible.
Business process modelling and first risk analysis
In terms of risk analysis we have to take two aspects into account:
- What is the probability of a risk to occur?
- What is the damage, if a threat occurs?
In the first step I model the business processes. I use to do that with BPMN. In addition to my normal proceeding now I have to do a risk analysis for every activity and sub process. Therefore, I rate the probability of a risk to occur and it’s possible damage severity. I give every activity or sub process a rate between 1 and 5. 1 stands for a very low probability / severity. In opposite, 5 indicates either an extremely high probability of occurrence or a dramatic severity of consequences. In doing so, I deduce the activity risk:
Activity risk = Probability of occurrence * severity of damage.
In this example we see an activity risk with a middleweight probability and a more likely low severity. This estimation of risk we have to do for every activity (or sub process) that lies within our responsibility. Please, take into account that this is not necessarily reduced to the lanes and pools that stand for the company or authority under discussion. It is very likely that external participants are using equipment, which was made available by our company or authority.
Example: In terms of a process like “Establish an internet connection” one activity “Dial in” is located at the site of an external participant – for instance a private person. To dial in this person uses a modem, which was provided by the telephone company. If this very telephone company wants to secure it’s processes, it must not forget this external activity. Otherwise, this process or even the entire company could be threatened by a manipulated modem.
In case you model BPMN with intensive use of so-called throwing events (especially in BPMN 2.0) consider enclosing those events into your risk analysis. This is due to the point that such events implicate an activity, namely the activity of sending. And very often this requires some kind of technical device, which we want to protect.
Nevertheless, in the following I would like to speak only of activities and sub processes to not confuse you too much.
With the next step I like to introduce another term: the process risk (as opposed to the activity risk).
As you might know, in the entire landscape of processes a single activity or sub process can appear several times. This has an impact on the relevance of that specific item. The more processes include a given activity the more relevant it is to our company. Therefore, I multiply the activity risk by the number of usages. This gives us the process risk of an activity:
Process risk = activity risk * number of usages
Whereas the two parts of the activity risk (probability and severity) are entered manually, the modelling suite will count the number of usages automatically.
In this example a sub process is involved into two processes. Therefore, we multiply the activity risk (6) by 2 and we get the process risk of 12.
Speciality of sub processes
Usually sub processes are a collection of several activities. They are used for a better understanding and more clearness of large processes. If you rate a sub process the modelling suite transfers its process risk to all enclosed activities. As a result all enclosed activities share the same risk of treatment. But, is that really the case? Normally that is not the case.
For this reason we have to distinguish between jeopardized and irrelevant activities. We will identify irrelevant activities as such. Endangered activities will keep the process risk of the sub process where they belong.
First interim result
After we have executed these steps for all of our processes we know which activities are endangered and which not. Based on that process risk we can differentiate between high-risk and low in risk activities.
In the next step we have to make towards technical devices and equipment to which endangered activities refer. For this purpose we will dive deeply into the now known activities. Read more in Part 2 of this process based risk analysis approach.Proceed to part 2 of process based risk analysis: Identifying sensitive technical components >>