Staging

Rule staging - Main Guide

Mobula offers a wide range of content that caters to the needs of information protection and network security. To effectively control these capabilities, the Staging mechanism has been established. The primary purpose of this mechanism is to categorize various modes of operations into stages that facilitate ease of use, expand or reduce monitoring capabilities, reduce false positives, and more.

With the Staging module, the SOC Manager or Information Security Manager can define rules that trigger specific actions such as sending an email, transferring to SOAR or MOBULA application, among others. Alternatively, rules can transition from an action-creating state to a state used for collecting events targeted towards lateral network views. Stages can be set to either Rule or Entity based on specific needs.

This guide will provide a detailed overview of the capabilities and usage of Mobula Staging Module.

Rule Staging

Rule Staging Types

There are 3 types of stages and located here:

/All Active Lists/Mobula Administration/Staging/Rules

Customer stage - Customer Rule Stage V2
Platform stage - Platform Rule Stage V2
Default stage - Mobula Default Rule Stage V2

“Default stage”

Is the staging type that the rule gets when it is being created in the Master Console and it affects all the customers. In this staging type will be various of rule stages.

Any stage change made to the rule from “Default stage” will be overridden by another staging type.

“Platform stage”

Is the staging type for rules you want to include on your entire platform.

For example: The default Rule stage for some rule is “HUNTING” and you see there are 0 alerts from this rule on your platform / you have already tuned this rule and you want this rule to be active on your entities, you can configure this rule to “Active” in “Platform Rule Stage” and this will override the “Default Rule Stage” that was given to this particular rule.

Pay attention: when a new entity connects to your platform the “Platform Rule Stage” will apply to him too, and it can cause significant spamming alerts.

“Customer stage”

Is the staging type for rules you want to include on a particular entity.

This type will override any other rule stage type.

For example: The default rule stage for some rules is “HUNTING” and you have tuned this rule for a specific entity and now this rule has 0 alerts triggered, you want to make that rule active on that specific entity.

You can configure this rule to “Active” in “Customer Rule Stage” and it will override any other stage type that was configured.

Best practice for staging types

If some rule has been added to one of the non-default stages and you want to move it back to Default, just delete its rule stage from one of the lists you added it instead of changing the rules type to Default manually.

Configuring Rule Stage

In order to configure

Available Stagings

Active - Rules that are tuned and working well.
Audit - Rules based on audit events.
AuditAlert - Rules that you as SOC don't want to see but the entity wants to receive by mail. (Best with Mobula Mail Service action).
AuditReport - Rules to be sent in a focused report to the entity (Must configure Focused Report).

/All Reports/Mobula Use Cases/Auditing/Audit Activity (Stage)

HUNTING - Rules that need to be tuned.
(More stages will be added in the future)

Action by stage

ESM

Follow the path to configure an action by rule stage for your entities.

Our suggestion is to configure an “Active” and “Audit” stages to be sent to entities email, after you verified that there is a low number of alerts to avoid spamming your entity.

Follow the steps to configure the “Active” and “Audit” rules stages to take the necessary action.

/All Active Lists/Mobula Administration/Rule Actions/Actions Lists/1. Customer Actions (MSSP)/Customer Rule Actions By Stage

In “Viewer” tab top right side click on “+”
Add the information:
1. Customer: Choose the entity.
2. Stage: Set the rule stage you want to make an action on. (See Available stages)
3. ActionID: Where to send the alerts to. (Check Available Action ID’s)
4. Click Add to save.

Available Action ID’s

MOBDB - Send alerts to Mobula application
MMAIL - Send alerts to Mail
ARCSO - Send alerts to arcsight soar
MOAPP - Send push notifications to Mobula application users.

MPM - Mobula Platform Management application

Define which stage of rules each action will get.

Our best practice is to check the overall alerts count before configuring an action to avoid spamming the entity with a high number of alerts.

Available Actions

Mobula DB - will send alerts to Mobula application to be viewed there
Mobula Mail Service - will send alerts to entities mailboxes that you configured.
Arcsight SOAR - will send alerts to the soar (Only for arcsight soar)
Mobula App - will send push notifications to application users.

Example:

To send alerts in “Active stage” to entity by mail, just click on “Add” at Related Platform action by stage section.
Stage - Choose the desired rule stage (Active).
Action - Mobula Mail Service
Save.

Pay attention that the mail address for sending alerts is configured to each entity.