Configure alerts
Enable or disable alert deduplication
Product | Guardian |
Syntax | conf.user configure alerts deduplication enable [true|false] |
Description | Enable or disable the alert deduplication capabilities. The feature is enabled by default. |
Where | CLI |
To apply | It is applied automatically |
Check the communication ports for alert deduplication
Product | Guardian |
Syntax | conf.user configure alerts deduplication check_ports
[true|false] |
Description | This option lets you choose whether or not the ports must be taken
into account when deduplicating alerts. Setting the value to
true (default), two alerts must have the same source
and destination ports for them to be considered duplicate and be
deduplicated into a single alert (more selective deduplication effect).
Setting the value to false , the user obtains
a potentially broader deduplication effect.
|
Where | CLI |
To apply | It is applied automatically |
Size of the buffer for alert deduplication
Product | Guardian |
Syntax | conf.user configure alerts deduplication buffer_size
<num> |
Description | By default, 2000 different alerts with their corresponding counter are stored in memory and written to the DB at a regular interval. This number can be tweaked depending on the appliance memory limits and on the number of different alerts that need to be deduplicated in the environment. The default should be generous enough for all production environments. |
Parameters | num : Size of the deduplication buffer |
Where | CLI |
To apply | It is applied automatically |
Update interval for alert deduplication
Product | Guardian |
Syntax | conf.user configure alerts deduplication update_interval
<num> |
Description | By default, the counter for every deduplicated alert is written to the database every 5 minutes (300 seconds). The deduplication counter of a single alert is also updated on the database when the maximum size of the duplication buffer is reached; the corresponding alert goes out of scope and is removed from the buffer, but the counter is updated to persist the information. Afterwards, if a similar new alert is raised, the counter for the previous alert will not be updated but the creation of a new alert will be triggered. |
Parameters | num : Update interval for the alert deduplication in seconds |
Where | CLI |
To apply | It is applied automatically |
Disable alert deduplication for specific alert types
Product | Guardian |
Syntax | conf.user configure alerts deduplication disabled_types
<arr> |
Description | By default, alert deduplication is on for all alert types. However, the
feature can be disabled for some alert types. For example: configure alerts
deduplication disabled_types ["SIGN:MULTIPLE-UNSUCCESSFUL-LOGINS",
"SIGN:MULTIPLE-ACCESS-DENIED"]
|
Parameters | arr : Array of disabled alert types for the alert deduplication
feature |
Where | CLI |
To apply | It is applied automatically |
Configure maximum number of victims
Product | Guardian |
Syntax | conf.user configure alerts max_victims <num> |
Description | Define the maximum number of victims that each alert can contain. Victims exceeding the given value are not stored. Default value is 10. |
Parameters | num : Maximum number of victims stored for each alert |
Where | CLI |
To apply | It is applied automatically |
Configure maximum number of attackers
Product | Guardian |
Syntax | conf.user configure alerts max_attackers <num> |
Description | Define the maximum number of attackers that each alert can contain. Attackers exceeding the given value are not stored. Default value is 10. |
Parameters | num : Maximum number of attackers stored for each alert |
Where | CLI |
To apply | It is applied automatically |
Show/hide credentials
Product | Guardian |
Syntax | conf.user configure alerts hide_username_on_alerts
[true|false] |
Syntax | conf.user configure alerts hide_password_on_alerts
[true|false] |
Description | This flags determine whether usernames or passwords should be presented in
the alert. By default, the credentials are visible. Affected alert types:
SIGN:MULTIPLE-ACCESS-DENIED ,
SIGN:MULTIPLE-UNSUCCESSFUL-LOGINS , SIGN:PASSWORD:WEAK .
|
Where | CLI |
To apply | It is applied automatically |
Configure maximum length of description
Product | Guardian |
Syntax | conf.user configure alerts max_description_length
<nchars> |
Description | Define the maximum number of characters that can contain the description of each incident. When an incident is appendding an alert description, the append is performed only if the incident description length is smaller then the limit. |
Parameters | nchars : Maximum number of characters allowed in the description of
each incident |
Where | CLI |
To apply | It is applied automatically |
Configure MITRE ATT&CK mapping rules
Product | Guardian |
Syntax for MITRE ATT&CK for ICS mappings | conf.user configure alerts mitre_attack ics_mapping
<path> |
Syntax for MITRE ATT&CK Enterprise mappings | conf.user configure alerts mitre_attack enterprise_mapping
<path> |
Description | Customize the rules used to assign MITRE ATT&CK techniques to alerts by
means of an external file. The file has the following format. Each line defines a
rule; the rule specifies an alert type ID followed by a semicolon and a
comma-separated list of MITRE ATT&CK technique IDs. For instance, the line
SIGN:PROGRAM:TRANSFER;T0843,T0853 instructs Guardian that alerts of
type SIGN:PROGRAM:TRANSFER must be assigned both the T0843 and
T0853 MITRE ATT&CK techniques.
|
Parameters | path : The path to the file containing the rules |
Where | CLI |
To apply | It is applied automatically |
Enable storing of alerts not visible under the current security profiles
Product | Guardian |
Syntax | conf.user configure alerts save_invisible_alerts [true|false] |
Description | Alerts are not stored into the database, if they are not visible under the current security profile and they are not part of an incident. This command can change this behavior and allow the above alerts to be stored. |
Where | CLI |
To apply | In a shell console execute: |
Configure red assertions behavior
Product | Guardian |
Syntax | conf.user configure assertion_element_monitoring
[enabled|disabled] |
Description | By default, an assertion is boolean; it is either red or green, and upon
turning red the assertion may send alerts. This configuration allows the
assertions to actively monitor lists of elements (such as nodes, labels, etc.),
and send new alerts for any additional elements that break the assertion, and when
an alert is closed and the triggering asserted element is still present.
Disabled by default. |
Where | CLI |
To apply | It is applied automatically |
Configure packet rules alerts limit
Product | Guardian |
Syntax | conf.user configure packet_rules alerts_per_session [limit] |
Description | Alerts risen by packet rules have a limit per alert class and per session This limit, which is 1 by default, can be relaxed or removed entirely. A value of -1 means unlimited. A value of 0 will completely disable these alerts. |
Where | CLI |
To apply | It is applied automatically |
Configure how Threat Intelligence contents are handled
Product | Guardian |
Syntax | conf.user configure alerts contents <json_value> |
Description | This command configures how Threat Intelligence contents are to be loaded. The JSON object can have the following attributes:
Contents available are:
As an example, the following command will disable completely contents loading:
As a further example, the following command will allow only stix indicators rules to be loaded:
As another example, the following command will configure the usage of the system database for storing STIX indicators related information, reducing the application memory footprint:
|
Parameters | json_value : A JSON object to configure how Threat Intelligence
contents are loaded |
Where | CLI |
To apply | In a shell console execute: |