Risk management is an equally important component of SGRC. Willingness to implement it in itself indicates a certain level of maturity in an organization. If audits answer the question “what is happening to CS now?”, risk management helps answer the question “What will happen to the organization’s CS in the future?” and also try to change that future.
Risk management is a proactive response to potential problems in the cyber security system. Of course, this process can be translated by regulators through regulatory documents requirements but it can be very difficult to approach. The reason for this is the following two factors, which are not described in detail in almost any risk assessment regulation:
– Risk assessment methodology.
– Threats catalogs.
- Risk assessment methodology
The term “risk assessment methodology” in this article refers to a list of risk parameters and how they are calculated.
There are three key points in the creation and description of assessment methodology, without which the process is not possible:
– What is considered to be the risk level – a key parameter, on the basis of which risks will be prioritized?
– On the basis of what parameters is the risk level calculated?
– On what principle are risk parameters calculated?
Depending on the way in which the values of risk parameters are derived, there are two types of methodologies: qualitative and quantitative.
The vast majority of organizations start their way with a qualitative risk assessment. In this case, parameter values are chosen from the directory or are displayed in tables. Each value corresponds to a description that allows to interpret it more accurately when choosing.
In the beginning, experts are more interested in the systematization of the results of their work, rather than in carrying out full-fledged calculations of parameters, levels, and indexes. The organization does not yet have experience in risk assessment, the process has not been built up – so for some time, the experts “agree” and try to operate with their expertise less subjectively than they could. This approach is understandable and logical – qualitative assessments generally simplify the process at the beginning and are easier to modify as experience is gained. They are a good starting point for the first steps in this area.
However, qualitative assessments have a number of drawbacks that make them unable to be the main tools for work:
– The result will always be highly subjective and poorly repeatable, regardless of the detail of value descriptions.
– Qualitative assessments are poorly scalable – increasing the number of parameters and values will not make the result more accurate but will make the experts’ work more difficult.
Sooner or later, the qualitative assessment will begin to diverge from reality. The assessment will either be too subjective or too broad. And there will be no way to improve the accuracy of the results due to the nature of this type of methodology. For this reason, a mature risk assessment process always implies a transition to quantitative assessments.
Quantitative risk assessment is an approach in which risk parameters are calculated using probabilistic or statistical methods.
Unfortunately, many experts overlook this definition and often mistake qualitative assessments for quantitative ones. Because of this, organizations can stay at the same level of maturity for a long time, wasting energy on unnecessarily complicating their methodologies instead of fundamentally revising them.
However, replacing the words “high, medium-low” with numbers “1; 2; 3” or coefficients, and performing mathematical operations on these numbers does not turn a qualitative assessment into a quantitative one. In a true quantitative assessment, the result is mathematically valid and depends minimally on the experts’ responses.
Unfortunately, quantitative assessment is not easy to get to, even having a clear understanding of its principles. Many people mistakenly believe that in the classic pair of parameters “probability and damage”, the most difficult to calculate is probability. That is not so. Calculating probability requires accumulating statistics on risk events and applying a suitable formula from probability theory – these are doable and understandable tasks.
In fact, the dark horse is the calculation of damage, and more specifically, the value of the asset included in the assessment area.
Firstly, calculating the value of an asset is a borderline responsibility area. The CS or the risk department staff may not have all the information needed for the assessment. Therefore, this step requires an additional interview with the owner of the asset.
Secondly, the value is extremely difficult to calculate objectively. It can be difficult for an asset owner to dive into the topic of risks and give a correct answer if you ask “head-on” questions (“how much damage would a data breach cause?”). People also tend to underestimate or overestimate depending on what is more profitable – for example, the owner may want to attract more attention and budget to his/her asset and overestimate the value.
Thirdly, operating with numbers feels like a higher level of responsibility than “high/medium/low” answers. People are afraid to sign off on specific numbers, which also affects the objectivity of the results.
For these reasons, compiling questionnaires for asset owners is a very difficult task, requiring the ability to work with people and process subjective responses. As a consequence, the “value” parameter often has the greatest degree of subjectivity.
With the SGRC solution implemented, experts are better able to choose an appropriate approach to risk assessment. The basic functionality, of course, is the ability to create and customize assessment schemes – both qualitative and quantitative. But thanks to the interconnection of different objects, the transition to quantitative assessment is quicker and more painless. An additional advantage is a fact that manual labor is reduced to a minimum, and experts can simultaneously test several techniques. The vendor’s expertise also plays an important role – sometimes the implementation project makes it possible to jump over several process development stages at once, thanks to pre-installed risk assessment methodologies and built-in knowledge bases.