In previous posts in this blog series we have referred to our main planning document, Rules and Regulations for Information Security Management, or RRISM for short, where our road to GDPR compliance started out. In that document we worked out the structure of the project, based on descriptions and definitions of the various components.
Obviously, risk management has to be taken very seriously, and the RRISM lays the groundwork for how we should handle this aspect of information security. The baseline is that risk management is an essential part of the company’s life, and one that comprises all its assets.
Defining and assessing risks
As usual, we first had to agree upon some definitions, and we found the following to be adequate for our purpose — directly from NIST (National Institute of Standards and Technology):
Risk is the net negative impact of the exercise of a vulnerability, considering both the probability and the impact of occurrence. Risk management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level.
Risk is a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization.
In order to assess risks, we first have to identify possible threats that may exploit vulnerabilities in our systems or our organization.
In short: Risk management shall first and foremost have as objective to protect assets that are at potential risk.
Analyzing assets
Then we outlined the methodology we adopted:
- Identify the assets that could be at risk.
- Identify possible threats and vulnerabilities.
- Identify the possible consequences of each potential vulnerability.
Each threat was characterized by probability and criticality which together gives one of four risk levels: Very High (red), High (orange), Medium (yellow), and Low (green). This helped us decide what we should prioritize regarding improvements, measures, and other actions.
Analyzing our assets we actually found more of these than anticipated, grouped in 21 different asset types, ranging from our customer base, general software in use and our own key business systems, through hardware and communication lines, and employees and partners – and more.
Threat, vulnerability, and gap analysis
Then we reviewed the vulnerability potentials (what could go wrong) for each asset and created scenarios for possible consequences if something happened that exploited a vulnerability.
The question raised thereafter was: Do we have the necessary measures and remedies in place to eliminate the potential vulnerabilities, or mitigate the consequences if things went wrong — or is there a gap?
The next step was to find out what actions should be taken in order to close the gaps in cases where we were not satisfied with the situation, and this will be the topic of future blog posts in this series.
Conclusion
Our mantra through this process has been: Threats we can imagine will sooner or later be reality, but never as we expect them to happen, and never where we expect them.
We live in an ever-changing environment, which means that risks have to be monitored continuously, and so our risk assessment and gap analysis is continually evolving as well.
