Frequently Asked Questions

Get to know more about Risk Score, risk scoring mechanism, risk quantification, and how risk score is calculated in Resolution Intelligence Cloud.

What is the Risk Score? 

Resolution Intelligence Cloud’s scoring mechanism includes multiple signals detected from source systems and correlates them into a Situation in which each signal arrives with a specific score depending on the threshold set by SOC analyst.

The scoring system is derived from well-known machine learning algorithms include - trained supervised models, active-learning models, and unsupervised models. 

How is it calculated in Resolution Intelligence Cloud?

Risk Score is quantified based on the three components mainly – Likelihood, Confidence, and Impact. Let us look at each of these components how they determine risk value of an asset within your organization.

A. Risk Quantification – What is the Confidence of an observed behavior?

In general, confidence refers to certainty of a situation in real-time analysis. For example, predicting rain on the given conditions - strong winds, thick clouds, and heavy thunders, my confidence will be 95% that it rains today. Range of Confidence measure varies from 0% to 100% based on the given conditions in real-time situation.

The main intent of confidence measure is to reduce the false positives and detect the incoming signal does really possess a potential risk to your organization. Resolution Intelligence Cloud achieves this by combining active learning, statistical modelling, and unsupervised learning. 

There are three prominent factors that contribute to a confidence measure in Resolution Intelligence Cloud. 

• Signal Confidence aggregates indicators from external tools and detection rules to gauge the “confidence measure” by external systems and rules.
• Past feedback to similar situations is an active learning (a branch of machine learning) model that feedback expert response to anomalies in the past and factors it in evaluating the current signal’s confidence i.e., was a similar signal marked as relevant by an expert? 
• Prevalent analysis looks for prevalence of the incoming signals against the organization’s past instances. This helps identify a signal frequency—an outlier or not—adapt the scoring, and keep away any biases, to the organization’s context. Resolution Intelligence Cloud carries out time-series (trend analysis) and statistical analysis (shape analysis) to determine prevalence.

The combined factors allow Resolution Intelligence Cloud to extract real-time expert behaviors and be a closed-loop system in measuring the true positivity of a signal.

B. Risk Quantification – What is the likelihood of an event?

In general, likelihood of an event refers to a chance of it occurring in real-time in a given timeframe. Understanding the likelihood of an event is crucial for decision making, risk assessment, and proactive measures.

Once the confidence level of Situation is determined, Resolution Intelligence Cloud performs the likelihood analysis of an incoming signal to determine its nature (i.e carries with a potential risk or not). Likelihood analysis involves the examining the historical data, patterns, and other contextual details of an event to determine the future attack.

Resolution Intelligence Cloud performs the following key steps to determine the likelihood of an attack:

Data Correlation: Examine the incoming signals and map them with tactics and techniques of a MITRE matrix to determine the nature of the attack. Resolution Intelligence Cloud scrapes not only the internal data but also the events from external environment to identify the likelihood of a potential attack.

Extraction of Contextual information: Consider the broader context includes threat landscape, industry trends, and other motives behind the attack to better understand likelihood.

Qualitative Assessment: Uses qualitative techniques include, statistical regression, and risk modelling to calculate the likelihood score of a situation.

C. Risk Quantification – What is the impact?

Impact refers to the harm or damage caused to your IT infrastructure due to the external cyber-attack. After determining the true nature and confidence level of a threat, it is essential to identify the level of damage caused by the external threat.

Impact of the threat is categorized into two sections in the Resolution Intelligence Cloud.

• Functional impact of the threat: Impact from the business functionality that these systems provide and the negative impact to the users of those systems— what is the direct or likely impact on your mission? (e.g., business operations, employees, customers, users) 
• Informational impact of the threat: Incidents may affect the confidentiality, integrity, and availability of the organization’s information. What is the direct or likely impact on your information/data, particularly anything sensitive? example, a malicious agent may ex-filtrate sensitive information. 

Calculating the Risk score using likelihood, confidence, and impact

The evidence contributing to each of confidence, likelihood, and impact is exposed to SOC teams allowing them to customize criticality for each piece of the evidence. Evidence are dimensional attributes of the scoring function on which teams can simply customize its importance/criticality. E.g., imagine setting criticality—low, medium, or high—for a CXO laptop or a jump server or a specific behavior, etc...

The custom criticality is then factored into the final scoring by Resolution Intelligence’s adaptive learning curve-fitting model.

How is it associated with an ActOn?

As evidence roll up to confidence, likelihood, and impact scores, SOC teams can define policies on top of each of these dimensions to denote “what combinations of these three should constitute a threat.” 

To illustrate, here below are instances of three different SOC teams defining what they must ActOn:

Likelihood	Confidence	Impact	Threat description
Undefined	>90	>90	In this instance, the team considers any alert with a confidence and impact score greater than 90 as a threat; irrespective of its likelihood.  e.g. A CFO getting a phishing email. Though, in this case, the likelihood of the phishing threat is minimal, the confidence and impact are high and so is raised as a threat.
>90	<50	>90	The SOC team wants to be alerted for any anomaly with a high likelihood and impact even though the possibility of a false positive is high from low confidence score.
>65	>60	>70	In this instance, a medium-high posture on all three dimensions is considered a threat by the SOC team.

How do we determine the default priority of an ActOn? 

Initially, the default priority of an ActOn is defined by the internal algorithm based on the ontology of multiple signal(s). If new signals are added to an ActOn with multiple priorities, then the internal algorithm recomputes the priority levels and an updated priority will be assigned to an ActOn.

However, you can change the default priority of an ActOn to your desired one manually by configuring the Processing Rules at signal level or ActOn Policies at Situation level.

What is the mapping that determine whether an ActOn will be tagged to P0, P1, P2 or other priorities when marked as an ActOn? 

ActOn will be assigned with the same priority as the Situation when it is converted to an ActOn.

How do we determine likelihood and impact of a Situation?

Refer to the Risk score using likelihood, impact, and confidence.

How do you check the priority of a Situation?

The Situations relevant to Security will not have any priority levels until it is converted to an ActOn. However, the Situations relevant to DigitalOps have multiple priority levels assigned to them based on the score evidence. For more information, refer to score evidence in Situations.

What actions should be avoided to keep CMS and Chronicle in sync?

The following are the actions to be avoided to keep the CMS and Chronicle in sync:

User Actions	Consequence
Older rule versions should not be disabled before creating and publishing a new rule version	This will disable the new version after creation in Chronicle.
Older rule versions should not be removed from the pack before creating and publishing a new rule version	The older rule version will move to the 'Approved' state in CMS and the 'Disabled' state in Chronicle. Consequently, the new version will be published to Chronicle as a new rule, disrupting version management.
No actions should be performed in Chronicle on Rules published from CMS.	If a rule is modified or updated in Chronicle after being published from the CMS, it cannot sync the new changes to CMS, and any further actions taken from the CMS will not apply to those rules.