Scribd
Upload
100 views7 pages

ReaQta-Hive Monitoring Methodology

The document discusses ReaQta-Hive, an AI-powered monitoring solution that detects threats based on behaviors rather than signatures. It focuses on the methodology for investigating incidents detected by ReaQta-Hive, including visibility, detection, triaging incidents to identify real threats vs false positives, response, and protection. The document also covers policies for prioritizing whitelists and blacklists, and considerations for enabling protection policies like ransomware protection while minimizing impacts to legitimate business operations.

Uploaded by

Hồng Quang Phan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
100 views7 pages

ReaQta-Hive Monitoring Methodology

The document discusses ReaQta-Hive, an AI-powered monitoring solution that detects threats based on behaviors rather than signatures. It focuses on the methodology for investigating incidents detected by ReaQta-Hive, including visibility, detection, triaging incidents to identify real threats vs false positives, response, and protection. The document also covers policies for prioritizing whitelists and blacklists, and considerations for enabling protection policies like ransomware protection while minimizing impacts to legitimate business operations.

Uploaded by

Hồng Quang Phan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

CONFIDENTIAL AND PROPRIETARY

ReaQta-Hive Monitoring
Methodology
29 Jul 2021
ReaQta-Hive Concept
The basic element in the ReaQta-Hive solution is event. An event is a behaviour exhibited.
Some events may trigger incidents because of the potentially malicious nature.

An incident triggered does not equate to a real threat (security incident). An analyst triaging
the incident should be the person determining whether it's a security incident or false
positive. If it's a false positive, it is the duty of the analyst to create the necessary whitelist.

To set the expectations right, it is important for analysts to understand that ReaQta-Hive’s AI
engines and NanoOS detect behaviours of malwares as part of the kill chain.

ReaQta-Hive :-

1. detects threats based on behaviours only. Hence, you may copy a malware into a machine
(PC) and if it is executed - but if it is not malicious or if it's inactive, ReaQta-Hive will not
trigger any incident. There is no business impact to the user in such a scenario. But if you
run/execute the malware, there will be event logs (regardless of whether suspicious or not)
so threat hunting allows you to find information about the suspicious application.

2. does not detect exploits but rather the malwares delivered via exploitation. The malware
that runs after it has been delivered via an exploitation will be detected the same way as
point 1.

3. is an A.I. powered solution which is agnostic to signatures, hence there will be bound to
have some detections on applications which users verified as legit. This is because a non
signature based solution like ReaQta-Hive looks at malicious behaviours / techniques used
by malwares and some legit applications use the same techniques. Hence Whitelisting is
necessary to reduce the false positives and this is an ongoing process.

CONFIDENTIAL AND PROPRIETARY


Investigation methodology
ReaQta-Hive methodology of threat handling revolves around visibility, detection, triaging,
response and protection. Besides the normal SOP within your SOC to handle real threats,
from a solution perspective, below are the descriptions of what an analyst should do within
each phase of threat monitoring using ReaQta-Hive

Visibility
● Look at the widgets to discover suspicious applications and behaviours
● Manually trigger incidents of suspicious behaviour to ascertain if there is a threat
● Understand from threat news and active threat hunt for the known IOCs

Detection
● Whenever the incident is triggered, analyst should handle the incident asap

Triaging
● Whenever an incident is triggered, clicking on the incident brings the analyst to the
incident details page. The main view will be the behavioural tree where the analyst

CONFIDENTIAL AND PROPRIETARY


can understand the activities of the incidents and the behaviours of the processes
involved.
● At this stage, the objective is to determine whether the incident is a real threat
(security incident) or a false positive.
● For incident triaging, ReaQta recommends the following “3 by 4” methodology as a
“guideline".
○ Identify the subject(s) (processes which triggers the incident), its parent and
child process(es), that's the “3” of the “3 by 4”
○ For the parent, subject and child process, verify the 4 areas are legit
■ authenticity: If its a trusted application i.e. signed by a trusted
certificate, known installed application etc
■ parameters: whether the command line parameter which is run
together with the application looks legit and harmless
■ behaviours: whether the behaviour is acceptable to the organization
■ connections: ensure the connections (if any) are legit

Response
● If its a false positive, analyst should create the appropriate white list
● If its a real threat, analysts should
○ if necessary, isolate the endpoint to prevent the threat from spreading and/or
exfiltrating sensitive data
○ terminate the threat and its related malicious process
○ remediate to remove the threat
○ hunt the threat within the organization to determine if the threat or variants
of the threat has spread to other machines
● Close the incident indicating whether its a security incident or false positive

Protection
● Creating the necessary blacklist to prevent the threat from happening again

CONFIDENTIAL AND PROPRIETARY


Policies
Policies Priority
1. Group Blacklist
2. Group Whitelist
3. Group Protection
4. Global Blacklist
5. Global Whitelist
6. Global Protection

Example 1
There may be scenarios where you need to create whitelists to prevent anti-ransomware
engines to cause a spike in endpoint resources or slowness in user PC experience. If they
have a protection enabled for a specific group and you want to whitelist something for that
trigger condition, you have to create a policy for the group(s) because otherwise, if you are
going to create a Global whitelist, the Group Protection policy still has a priority over it, and
in the anti-ransomware engine check still happen and the slowness remains.

Example 2
When creating a whitelist, we want the whitelist to be future-proof. As such, an analyst may
consider creating a Trusted App whitelist, where the qualifiers are the Original Filename of
the app and the Signer name. Any future upgrades of the software will also be covered by the
same whitelist since its Original Filename never changes and the Signer is the same.

CONFIDENTIAL AND PROPRIETARY


Consideration for enabling (Ransomware) Protection Policies
ReaQta-Hive out-of-the box does not block any app detected. Auto blocking of detected
apps can be achieved using blacklists or protection policies. A blacklist can be based on app
hash or behaviour. When a behaviour is chosen, a directory needs to be specified. A blacklist
based on hash blocks the running of the specific app while a blacklist based on behaviour
allows the app to run but terminates the process only when the specified behaviour is
exhibited. Protection policies are based on behaviours but do not require a directory to be
specified because the coverage is system wide. Its should be noted that blocking
(terminating) a process based on blacklist hash, behaviour or protection policy is performed
during when the app process is created (in a case of hash blacklist policy) or when the
behaviour is exhibited (in a case of behaviour blacklist or protection policy) and does not
block (terminate) existing running process.

It is recommended for customers to eventually enable ransomware protection policy to


prevent possible ransomware attacks, in which the human analysts will not be able to
respond fast enough. Besides Ransomware protection policy, enabling the rest of the
protection policies are subjective to customers requirements as typically the analysts have
time to respond to the threat. In many cases an organization would want to observe and
gather more threat intel before blocking it.

CONFIDENTIAL AND PROPRIETARY


Legit customer apps could sometimes also exhibit suspicious or malicious behaviours. As
such, it is important to communicate with the customer and let them understand the risks
before enabling protection policies. Generally we suggest two approaches and the risks are
stated.
1. Approach 1: Deploy ReaQta-Hive to at least 80% of all the customers endpoint
(including servers). Observe and handle the alerts and create the necessary whitelists
constantly (at least on a daily basis, recommended to do this 3 times a day) for at least
2 weeks. Until a time when the daily ransomware alerts are manageable, customers
may choose to enable the ransomware protection policy. This approach means that
before the ransomware protection policy is enabled and if the organization
encounters a ransomware attack, ReaQta-Hive could potentially detect but does not
block the ransomware.
2. Approach 2: Customers provide a list of mission critical or commonly used apps for
ransomware whitelist creation. After that, the ransomware protection policy is
enabled to protect the organization. This approach allows organizations to be
protected from ransomware attacks at an early stage but constant monitoring and
creation of whitelists for legit apps must be considered to minimize the business
impact.

As organizations evolve with their business, the software used within the organization
changes as well. As such, it is important for customers to understand that creation of
whitelists is an on-going process. In the case of a ransomware protection policy when
enabled, any app not whitelisted (in accordance with policy priority) and exhibits the
behaviour or ransomware (detected by ReaQta A.I. engine) will be blocked automatically.
This may result in the organization’s business operation.

CONFIDENTIAL AND PROPRIETARY

You might also like