Building a security roadmap
Risk management is a key tool to build up an organization's cyber defense. It helps to identify potential hazards and weaknesses as well as to select cost-effective controls, and if systematically used, it will improve the organization’s security posture. In this post I’ll explain the different phases of the risk management process, the approach taken by the Security Team to manage risks at UserZoom, and how the results obtained are the core of the annual security plan.
Risk is a concept commonly associated with unwanted and negative events that are an inherent part of our daily lives.
Any of us continuously analyze situations and make decisions, sometimes almost unconsciously. This process is what we call a ‘risk assessment’. It allows us to control undesirable impacts on a situation, taking into account the different options and selecting the best one according to the moment.
As an example, when you take your car and realize that the gas level is low, you can decide to modify your route and drive to a gas station to reduce the risk of being stuck on the road.
Or, if you have chest discomfort for a couple of days, you can decide to visit the doctor to minimize the risk of having to stay in bed for a few days.
In the same way, companies are exposed to unexpected events that can impact their operations. However, due to the complexity of the activity or the complexity of the organization itself, a more formal process of risk assessment is required, as well as specific capacities for this activity. If this process is not in place, unexpected events can negatively impact the organization.
The set of activities carried out within an organization to identify, understand and control risks is known as ‘Risk Management’.
There are dozens of different risk assessment methodologies, some more generic and some more detailed or tailored to specific sectors or types of risks. Some are more complex, some simpler. The European Union Agency for Cybersecurity (ENISA) has also published a list of the most widely used methodologies for information security risk management.
In 2009, the International Organization for Standardization (ISO) published a standard on the implementation of risk management, ISO 31000. This standard is applicable and adaptable for ‘any public, private or community enterprise, association, group or individual’ and provides best practice structure and guidance to all operations concerned with risk management.
Instead of selecting one of the existing specific security risk management methods, in UserZoom we decided to align with the recommendations provided in ISO 31000 and generated a customized methodology that satisfies the following objectives:
In this post, we will focus on steps 1 to 5. To execute them, we took two different approaches:
In future iterations, our idea is to involve representatives from other relevant teams in the latest steps (3 and 5) like, for instance, the CloudOps Team or other teams within Engineering, depending on the Service in scope.
Finally, before going into detail about the process, I would like to make a special mention to Miquel Fairman, who set up the methodology at UserZoom and who has made the adaptations in our corporate tracking tool to allow its use for risk management.
Establishing the context defines the scope for the risk management process (what is ‘in’ and ‘out’ of the assessment) and sets the criteria against which the risks will be assessed.
Instead of undergoing a full Company risk assessment, we decided to perform smaller assessments aligning each scope with the Service offered by the company (UserZoom Enterprise, IntelliZoom, Enjoy HQ, etc.).
All functionalities are considered for each service. Also, all elements involved in the provision of the service are in scope. This includes the application, its full cloud infrastructure stack, the datacenters and the team managing the service and the supporting services.
In this step we had to decide which were the set of potential ‘threats' that could prevent the elements in the scope from achieving its objectives.
Since the scope was a Service, we selected the circumstances or events that could adversely impact the way the product works; be it a total failure of the product or its degradation or loss of functionality.
From an IT / Security perspective, we identified two big groups of threats: ‘Intentional’ (also known as ‘adversarial’) and ‘Unintentional’ (also known as ‘non-adversarial’).
We wanted to define our own threat list, not reinvent the wheel, so we selected applicable threats from existing lists maintained by recognized organizations in the world of cybersecurity. In our case, we chose:
Once the threats that could have an unwanted impact on the elements in our scope were identified, we wanted to understand the nature of each threat and its characteristics to obtain a risk level.
Following ISO 31000, we defined Risk as ‘Likelihood * Impact’, being ‘Likelihood’ an estimate of how often the threat happens and ‘Impact’ an estimate of the potential losses associated if a specific threat successfully takes place.
By calculating each selected threat's likelihood and impact, we understood which threats pose the biggest risk.
At this point, we had to determine the most appropriate analysis method to use. ‘Qualitative’ and ‘quantitative’ are the most widely used classifications:
For our methodology, we selected a qualitative approach. First, we defined scales for:
These scales were selected taking into account the nature and characteristics of our business and could be adapted for other exercises or types of risk analysis. However, it is convenient to maintain the scale for the same kind of risk assessment on different Services and in successive iterations to compare the results.
With the scales defined, each threat was analyzed twice:
To do this, we applied a (subjective) percentage reduction to any or both of these variables depending on the effectiveness of the controls in place. This is what we call ‘Residual Risk’.
Essentially, ‘Residual Risk’ = ‘Inherent Risks’ - Impact of Risk Controls.
This way, all threat risks are assigned a numeric value from 0 to 25 (Likelihood (0-5)*Impact (0-5)) and classified from Very Low up to Very High, depending on the risk value obtained.
All identified and assessed risks are documented in the Security Risk Registry (in JIRA) for traceability purposes and follow-up.
At this stage, we needed to decide whether an action was required for a given risk. We defined risk treatment criteria to determine which risks require an action and then we compared the risk analysis results against it.
There are four strategies we may apply to a risk:
In our case, we have defined the following risk treatment criteria:
Once risks have been identified, analyzed, and evaluated, an appropriate risk treatment must be applied.
We can’t tackle all risks at the same time, so it is fundamental to prioritize them and focus on the most important ones, starting with the ones with the highest residual risk. Once actions are implemented to treat them, the rest of the threats with a residual risk over the acceptance level (in our case ‘low’ and ‘very low’) can be managed in successive iterations.
Risk treatment involves:
In order to select the appropriate measures to treat the most relevant risks, a 2-day workshop was held in our Barcelona office, where all of our Security Team members had the opportunity to propose and discuss different mitigation options and reach an agreement on the action plans to implement.
As resources are limited, we had to prioritize. The main criteria when selecting the measures/controls to implement was the balance between ‘cost of controls’ and ‘risk reduction’.
To help us classify these actions and to decide which ones to tackle first, a 2x2 prioritization matrix was used. This matrix had the ‘estimated cost’ in the X-axis and the ‘effectiveness in reducing the risk’ in the Y-axis.
All identified actions were placed in the matrix, and the actions with the highest reduction effectiveness and lower cost (quick wins) were the first ones selected for implementation.
An action plan was created using the selected actions with owners and target dates. Since we are tracking tasks in JIRA, we also leveraged it to link each action to the corresponding risk.
At UserZoom we have adopted a risk-based approach to information security. The result of this risk assessment and risk treatment process gives us a clear picture of what we need to implement to improve the security of our services.
Since security risks are the drivers of our security program, the resulting action plan is the main input to the Security Roadmap, which defines the security projects that our Security Team will address during the year.
The periodic follow-up on actions and on the evolution of the risks is equally important. The operating environment can change anytime (new functionalities, platform changes, etc.) and these changes can introduce new risks. It’s also worth remembering that, as actions are executed to address identified risks, the risks can themselves evolve and change.
Now that you have seen how risk assessment and treatment have helped us to build our plans to increase security at UserZoom, it’s time to ask:
Can risk management also help you with your projects?
And the answer is… of course it can!’. Risk management is an amazing tool that will allow you to identify potential problems before they occur and which can be used for lots of different activities, not only for security planning.
The same methodology presented in this post can be easily adapted to the activities and characteristics of each specific team and can be used to handle the risks of any kind of project.
Start managing risks in a proactive and systematic way if you want to increase the likelihood of success of your projects.
Did you enjoy reading this blog post and the way we work at UserZoom? Make sure you check out our open roles in the security team, and our other departments.