How security risks are assessed in UserZoom

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.

Introduction

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’.

The risk management process

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:

• Follows international risk management best practices.
• Does not require specific tools.
• Is simple, avoiding complex calculations and a big effort from the team.
• Is flexible enough to allow for changes/improvements in the future if needed.
• Allows successive iterations and compares the results between iterations.
• Can be easily integrated and tracked in UserZoom cooperative tools for ticket/issue management.

In this post, we will focus on steps 1 to 5. To execute them, we took two different approaches:

• For steps 1 to 4, ‘Establishing the context’ and ‘Risk Assessment’, we decided that the best way was to keep it simple and to conduct a series of online meetings involving only the Director of the Security Team and the Leads of the two Security Squads. 
• However, for step 5, the entire Security Team was involved (further information later).

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.

Establish the context

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.

Risk Identification

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’).

• Intentional threats are generated by the deliberate intent of an attacker to cause trouble and can involve the use of computer code or other technical devices. Examples of intentional threats are malicious software, such as ransomware, denial of service attacks and social engineering attacks, like phishing.

• Unintentional ones result from human errors, environmental hazards or computer failures.

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:

• For intentional threats, a couple of lists from MITRE Corporation (Massachusetts Institute of Technology Research and Engineering):  the MITRE ATT&CK SaaS (Software as a Service) and IaaS (Infrastructure as a Service) matrixes.
• For unintentional threats, a selection of the Threat taxonomy from ENISA (The European Union Agency for Cybersecurity).

Risk Analysis

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:

• Qualitative Risk Analysis applies a subjective assessment based on a person’s judgment or experience. It is typically used to identify high-level risks and is less time-consuming.
• Quantitative Risk Analysis, on the other hand, calculates risks based on numbers ( i.e. costs, losses, etc.) and statistical models. It is used to identify more specific risks but requires greater effort and data.

For our methodology, we selected a qualitative approach. First, we defined scales for:

• Likelihood (0-5, being 0 when the event never happens and 5 when it happens several times per month) and 
• Impact (0-5, being 0 when the impact of the threat materializing is null and 5 when the impact is greater than 5M$).
  
  

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:

• The first time we calculated the likelihood and impact of the threat in the absence of any mitigation or control. This is what we call ‘Inherent Risk’. 
• The second time we calculated the likelihood and impact of the threat, but taking into account the existing measures in place to reduce:
  1) the probability of occurrence (for instance, removing inflammable objects from a data center decreases the risk of having a fire) and/or 
  2) the impact if the threat happens (fire extinguishing systems in place).

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. 

Risk Evaluation

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:

• Avoidance: Elimination of the cause of the risk (for instance, completely remove one functionality that is ‘vulnerable’ or become a paperless organization to reduce the risk of fire). 
• Mitigation: Reduction of the risk likelihood (such as enhanced security training for developers or applying security patches) or of its impact (backups to recover in case of data loss). 
• Transfer: Sharing of risk with partners (as with cyber insurance)
• Acceptance: Formal acknowledgment of the presence of risk with a commitment to monitor it. It is up to each organization to determine the balance between the benefits of accepting a risk (such as a competitive advantage) against the potential cost, adverse impact and disadvantage of implementation.

In our case, we have defined the following risk treatment criteria: 

• For ‘Very High’ residual risks: Mitigate immediately or avoid
• For ‘High’ residual risks: Mitigate in less than 1 year or transfer
• For ‘Medium’ residual risks: Mitigate or ‘accept and monitor’.
• For ‘Low’ or ‘Very Low’ residual risks: Accept

Risk Treatment

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:

• Selecting the measures/controls to treat the prioritized risks
• Creating an action plan with dates and owners
• Executing the plan
• Assessing the new residual risk once the actions are implemented
• Determining further controls if the residual risk is still too high

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.

Next steps

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.