Alerts Module

Creating alerts

Introduction to Alerts Module

The Alerts Module in CYBERQUEST provides a flexible and customizable system for monitoring events. Users can define specific criteria to trigger alerts tailored to their needs, enhancing accuracy and minimizing false positives. Alert configurations are managed through the Alerts section in the Settings menu.

Customization settings for each option are explained in the following sections.

How to create new alerts

This section outlines the process for setting up new alerts within CYBERQUEST. Defining custom alert criteria enables proactive monitoring of critical events and timely response to potential security issues. The following steps guide the configuration of alerts tailored to organizational needs.

To create a new alert, follow these steps:

Step 1. Authentication

Open a web browser and enter the application’s address or DNS name. By default, the Web Interface is accessible at https://CyberquestIPAddress (example).

The browser will then redirect you automatically to CYBERQUEST’s authentication page:

Step 2. Navigate to Alerts

Navigate to the Settings menu and select Alerts > Realtime. The Alerts customization page will open within the Alerts module interface.

Step 3. Create new alert definition

On the "Alerts" page, select the "Create new alert definition" button to create a new alert.

Step 4. Complete the form

Complete the form with the appropriate information and press "Save Alert & Exit" button:

Alert Name: Specifies the name of the new alert.

Alert Active: Enable the ALERT ACTIVE checkbox to activate the alert, or disable it to deactivate the alert.

Default Deduplication: This toggle enables or disables automatic deduplication for the alert. When activated, the system will suppress duplicate alert triggers based on repeated or similar event patterns within the same rule logic. This helps prevent multiple alerts from being raised for the same root cause. When deactivated, all matching events will trigger alerts individually, regardless of duplication.

Time Frame TTL(sec.) : Defines the duration (in seconds) for which the alert remains active after being triggered.

Alert Security Score: Sets the baseline security score for the alert when triggered. The actual real-time score adjusts dynamically based on defined rules and the number of related events, but cannot fall below the baseline or exceed 100.

Alert Security Level: Functions similarly to the security score, with matching color coding to indicate severity levels.

Sent as Alert: When unchecked, the alert remains active but does not generate visible notifications. This option allows backend correlation of anomaly analysis across multiple events, triggers, and alerts. It behaves similarly to the ALERT ACTIVE checkbox.

Enable the Has Action checkbox to associate the alert with either a script or predefined automated actions. Only one custom script can be created and applied, and it is always evaluated last, overriding other rules in the alert logic.

Enables configuration of alert deduplication when Has Action is active. Alerts are grouped based on selected fields and a defined time interval.

Send via Email: Enable this checkbox to send the alert notification via emailto defined recipients.

Notification Template: Select a notification template for the alert. Options include built-in and custom templates. The default selection is “Default notification.”

Rules Section

Rules define the detailed behavior of the alert, ranging from single event conditions to complex correlations between multiple events, including event order, correlation to missing an event from a logical succession of events.

• Previous: Navigate to the previous alert condition.

• Next: Navigate to the next alert condition.

• Add Rule: Adds a new rule. The rule is configured in the Rule Settings pane on the right.

Rule Settings Pane

This pane facilitates defining the logic of each rule. Rule logic consists of field, report, and correlation conditions combined using logical operators AND, OR, and NOT.

Each rule includes:

• Description: Provide details about the rule’s behavior or the conditions it monitors.

• Add field condition: elect an event field from the drop-down menu, choose the appropriate operator, and enter the value to compare.

• Add report condition: Select a report from the drop-down list of existing reports to include as a condition.

• Delete: Remove a specific rule condition.

When adding rule conditions, a logical operator is automatically inserted to correlate the new condition with the previous one. The default operator is AND. Click the AND switch to toggle between AND and OR.

If needed by the logical chain, a NOT operator is available as a checkbox. It is unselected by default. Click NOT to enable the operator.

Real time alerts

Real time alerts customization

To access real-time alert settings, go to Settings > Alerts > Realtime. This opens the Alerts customization page within the Alerts module. All existing alert definitions are displayed and can be edited, deleted, cloned, or exported as a CQO.

Click the button to create a new alert definition. The Alert Settings window will open, enabling the creation of a custom alert tailored to specific requirements. This window has the same features as the alert editing interface, which is detailed later in this chapter.

Click the button to import an alert definition from an existing CQO file.

At the top of the page, a drop-down list labeled Select Tags allows filtering alert definitions by categories

A drop-down filter at the top of the page that displays alerts assigned to a specific user or team, helping to quickly identify and manage alerts based on ownership.

At the bottom of the page, a navigation selector enables browsing through pages with alert definitions.

Editing an alert definition

Press button to edit an existing definition. Alert Settings window opens:

Under Alert Name section, you can set the following options:

• Enter an alert name, change or leave unchanged.

• Notification Template: Select a notification template for the alert. Options include built-in and custom templates. The default selection is “Default notification.”

• Alert Active: Enable the ALERT ACTIVE checkbox to activate the alert, or disable it to deactivate the alert.

• Default Deduplication: This toggle enables or disables automatic deduplication for the alert. When activated, the system will suppress duplicate alert triggers based on repeated or similar event patterns within the same rule logic. This helps prevent multiple alerts from being raised for the same root cause. When deactivated, all matching events will trigger alerts individually, regardless of duplication.

• Time Frame TTL(sec.) : Defines the duration (in seconds) for which the alert remains active after being triggered.

• Alert Security Score: Sets the baseline security score for the alert when triggered. The actual real-time score adjusts dynamically based on defined rules and the number of related events, but cannot fall below the baseline or exceed 100. Security Score Color Codes:

• Green – Represents a low-severity alert, with a score up to 30.

• Yellow – Indicates a medium-severity alert, with scores ranging from 31 to 60.

• Red – Denotes a high-severity alert, with scores between 61 and 100.

• Alert Security Level: Functions similarly to the security score, with matching color coding to indicate severity levels.

• Sent as Alert: When unchecked, the alert remains active but does not generate visible notifications. This option allows backend correlation of anomaly analysis across multiple events, triggers, and alerts. It behaves similarly to the ALERT ACTIVE checkbox.

• Enable the Has Action checkbox to associate the alert with either a script or predefined automated actions. If automated actions are configured in the alert, they will execute only after all rule conditions within the alert definition have been fulfilled. These actions represent the final response stage triggered by the alert logic.

• Enables configuration of alert deduplication when Has Action is active. Alerts are grouped based on selected fields and a defined time interval.

• Send via Email: Enable this checkbox to send the alert notification via emailto defined recipients.

For additional details on configuring Action Parameters, refer to: How to activate automatic Actions in Realtime Alerts

Under the Rules section, alert behavior can be precisely defined using granular rule configurations. This includes single-event rules, correlations between multiple events, event sequence logic, and detection of missing events within an expected pattern.

The left pane displays the list of defined rules. The following actions are available:

• To add a new rule, click the button. The rule will appear in the Rule Settings pane on the right.

• Use the buttons to navigate through the existing rules. The currently selected rule is highlighted in yellow, and its configuration is displayed in the Rule Settings pane

• To remove a rule, click the button.

The Rule Settings pane is used to define the logic behind each alert rule. Rule logic consists of field conditions, report conditions, and correlation parameters, combined using the logical operators AND, OR, and NOT.

Each rule includes the following elements:

• Description: A text field for detailing the purpose or behavior of the rule.

• Rule Trigger Type: A drop-down menu offering several trigger types

  • Single Event Trigger - activates the alert when a single event meets the defined conditions. No threshold or accumulation is required.

  • Count until MaxThreshold (the maximum number of events counted) before TTL value expires, or TTL expires and count MinThreshhold (the minimum number of events counted) value is achieved - how many (for e.g. 3 customers with 25% discount if you group by discount)

  • Sum PivotField (the arithmetic sum for a specific field) until MaxThreshold (the maximum amount) before TTL value expires or TTL expires and Sum PivotField MinThreshold (the minimum amount) value is achieved - how much (for e.g. for business applications: if the total value discount for region is more than 1000 euro)

  • Average on PivotField until TTL has MinThreshold value

  • (Distinct values on PivotField until MaxTreshold before TTL expires) OR (TTL expires and Distinct values count on PivotField MinTreshold achieved) - number of distinct values (for e.g. how many distinct IP addresses send events, made attack for specific field)*

• MaxThreshold, MinThreshold, and TTL (sec.) values for the rule’s trigger type

  

MaxThreshold – the maximum number of events required to trigger the alert.

MinThreshold – the minimum number of events required to trigger the alert.

PivotField – the sum of a specific field (e.g., total monetary value or number of transactions in business applications)

Rule conditions can be added, edited, or deleted as follows:

• To add a field condition, press the button. In the Select Field drop-down, choose a relevant event field. Then, select the appropriate value operator from the next drop-down, and enter the corresponding value in the third field.
• To add a report condition, press button. A drop-down list will appear, allowing selection from all existing reports.
• To add a correlation condition, press button. This opens two Select Field drop-downs for selecting event fields to correlate, a comparison operator drop-down—providing options such as equal, not equal, less than, less than or equal, greater than, greater than or equal, along with additional operators like isInList, isNotInList, startsWith, endsWith, contains, range, containsAnyOf, containsAllOf, and regexMatch. A corresponding rule condition can also be selected for the correlation to apply.

The script rule is evaluated last in the sequence of rule conditions and, together with any configured automated actions, is executed only after all other alert rule conditions are fullfiled.

To delete a rule condition, press the button located at the far right of the rule condition entry.

When adding a new rule condition, a logical operator is automatically inserted to correlate it with the previous condition. The default operator is AND. Click the toggle to switch the operator to OR; click again to revert to AND.

If required by the logic structure, a NOT operator is also available as a checkbox. By default, it is not selected. Click to enable it. The resulting logical expression will be interpreted as AND NOT.

All rule conditions are added sequentially, in the order they are defined.

Once configuration is complete, click the button at the top to save the rule and return to the alert definitions list. To discard all changes, click the button.

Example of a script rule:

   var currentAlertState =  JSON.parse(Alert);
   return false; // triggers current alert instance supression. If return is NOT used, the alert is not triggered as well.

Alert Deduplication

Alert deduplication is a mechanism that consolidates multiple alert instances triggered by identical or similar event patterns within a specified time interval. It helps optimize alert handling by preventing redundant alert generation for recurring conditions that match the same rule logic.

To access the deduplication settings, the Has Action option must be enabled. Once enabled, the button becomes available for configuration access.

Configuration options include:

• Interval: Defines the time window during which similar alerts are grouped and treated as a single occurrence. Available options include 1 minute, 10 minutes, 1 hour, and 1 day.

• Deduplication fields: Specifies the fields used to determine if alerts are considered duplicates. These fields must be configured so CYBERQUEST can accurately group alerts based on matching criteria.

• When duplicate alerts are detected within the specified interval and fields, the alert count is incremented, and the LastSeen timestamp is updated accordingly.

Once configuration is complete, Set saves and applies the deduplication settings, while Cancel discards any changes and closes the configuration window.

Manual alert deduplication is also available to mark duplicates: Alerts Manual Deduplication

Create a Logon alert scenario example

This scenario outlines how to configure an alert that triggers when a specific user experiences two failed logon attempts within a 60-second interval.

Step 1: Navigate to Settings > Alerts > Realtime.

To create a new alert, click the CREATE ALERT button on the Alerts page.

Step 2:

Configure the alert definition with the following settings:

• Name: Default - Audit policy change
• Alert Active: Enabled
• Send as Alert: Enabled
• Security Score: 40
• Security Level: 5

Step 3:

Add a new rule with these parameters:

• Description: Audit policy change events
• EventID: 4719 Note: Event IDs can be referenced in the Event Dictionary

Step 4:

Save the alert definition.

The new alert will now appear listed on the Alerts page.

Step 5:

When conditions are met - specifically, when two failed logon attempts by the specified user occur within 60 seconds - an alert is generated in real time. This alert corresponds to Event ID 4719 (Audit policy change) retrieved from the Windows Security Log and is visible in the Alerts module interface.

How to activate automatic Actions in Realtime Alerts

To use predefined automatic actions, first create a new alert or open/edit an existing scenario or alert.

For instructions on creating a new alert, please refer to the provided link: How to create new alerts

To access Action Parameters, open the ALERT SETTINGS menu by navigating to Settings > Alerts > Realtime. The Alerts customization page will open within the Alerts module interface.

When creating or editing an alert, the Has Action checkbox will be available:

Press to open the Action Parameters window, which includes a drop-down list of automated actions and provides access to the Script Editor for creating a custom script.

Selecting a specific action (e.g., disabling a Linux user account) enables an automated response scenario. These actions can include enabling or disabling user accounts, sending notifications via email or messenger, and more.

An action is executed in response to alerts triggered by specific event conditions.

The following predefined automated actions are currently available:

1.LinuxActions.DISABLE_USER**

This automated action disables or removes specified Linux user accounts from the target host, based on the defined parameters:

• Target User - Specifies the user account to be disabled.

• Host - Defines the system where the action is to be applied.

• CredentialsGUID Specifies the credentials used by the CYBERQUEST server to perform the action.

This action requires root password to execute.

Upon execution, the specified user will be removed from the target system and will no longer be able to authenticate or log in.

Target User:

• Static Value - A fixed username can be provided directly in the field. The specified user will be disabled based on this static input:

• Properties - Allows dynamic selection of the user based on event data. Use the UserName field from a specified rule and event index to determine which user will be disabled:

Host:

• Specifies the target system where the user account will be disabled. This can be the host from which the event originated or a specific machine (e.g., DC09)

CredentialsGUID:

Specifies the credentials used by the CYBERQUEST server to execute the action. The appropriate credential (e.g., AgentWindows) is selected from a predefined list:

2.LinuxActions.ENABLE_USER

This action activates or restores a specific Linux user account, allowing the user to log in again. It operates based on the following parameters:

• Target User - Specifies the user account to be enabled

• Host - Indicates the host where the account will be reactivated

• CredentialsGUID - Defines the credentials used to perform the action

This action requires root password to execute.

Target User:

• Static Value - A fixed username can be provided directly in the Static Value field to specify the user account to be enabled.

• Properties - A dynamic selection that allows choosing a username from a specific rule and event instance using the UserName field. This enables the action to target users identified at runtime.

Host:

• Specifies the target system where the action will be executed. This can be the originating host or a specific system like a domain controller (e.g., DC09).

CredentialsGUID:

• Indicates which stored credentials from the CYBERQUEST server are used to perform the action. The credentials are selected from an available list (e.g., AgentWindows).

3.LinuxActions.EXPIRE_USER_PASSWORD

This action enforces password expiration for a specified Linux user, preventing further logins using the current password. Configuration requires the following parameters:

• Target User - The user whose password will be expired

• Host - The system where the action is applied

• CredentialsGUID - The credentials used to perform the operation

Execution can be carried out by a group administrator or a user with sufficient privileges; root access is not mandatory.

Target User:

• Static Value - Enter a specific username whose password should be expired.

• Properties - Dynamic values can be applied by selecting the rule and event number from the list. For example, the UserName field can be used to dynamically identify the target user.

Host:

• Specifies the target system where the action will be executed. This can be the originating host or a specific system like a domain controller (e.g., DC09).

CredentialsGUID:

• Select the credentials (e.g., AgentWindows) from the CYBERQUEST server that will be used to execute the password expiration action.

4.LinuxActions.DISABLE_PASSWORD_EXPIRE

This action disables password expiration for a specified Linux user, allowing the user to log in without being restricted by an expired password. The action is performed based on the following parameters:

• Target User - The Linux user account for which password expiration is to be disabled.

• Host - The system where the action will be executed.

• CredentialsGUID - The credentials used by CYBERQUEST to perform the action on the target host.

Could be done by group administrator.

Target User:

• Static Value - A fixed username can be specified directly. In this case, the user name is manually entered into the Static Value field.

• Properties - Dynamic values can be used by selecting a rule and event number from the list. For example, the UserName field can be referenced to dynamically identify the account for which password expiration should be disabled.

Host:

Specifies the target system where the action will be executed. This can be the originating host (where the triggering event occurred) or a designated system like a domain controller (e.g., DC09).

CredentialsGUID:

Indicates the credentials to be used by the CYBERQUEST server when executing the action. A credential entry (e.g., AgentWindows) must be selected from the predefined list available in the system.

5.Notifications Email/ Teams/Slack/Jira

These actions trigger automatic notifications through selected communication channels, including Email, Microsoft Teams, Slack, or Jira, based on the alert conditions defined.

The custom message defined by the user, which will be delivered when the alert is triggered by a matching event. This message typically includes context about the detected risk or condition.

6.PlayBooks.RUN_PLAYBOOK

This action triggers the execution of a defined playbook in response to the alert instance. When the alert conditions are met, the associated playbook is automatically initiated, enabling a structured and automated response workflow. Playbooks may include a series of predefined tasks, actions, or decisions designed to handle specific security events or operational scenarios.

AlertSecurityThreshold - Sets a static numeric value to define the security impact level of the alert.

Run Playbook - Selects a playbook from the list of available entries defined in the Playbooks module to be executed when the alert is triggered.

7.LinuxActions.MANIPULATE_SERVICE

This action performs operations on a specified Linux service - starting, stopping, or restarting it - based on defined parameters.

ServiceName – Identifies the name of the Linux service to be manipulated

Action – Specifies the type of service operation (start, stop, restart)

Host – Indicates the host on which the service operation will be executed

CredentialsGUID – Indicates the credentials to be used by the CYBERQUEST server when executing the action. A credential entry (e.g., AgentWindows) must be selected from the predefined list available in the system.

This action requires root password access to execute successfully.

ServiceName:

• Static Value – A fixed service name can be entered directly (e.g., sshd, nginx).
• Properties – Enables dynamic selection of the service name from a rule and event instance, allowing flexible automation based on event data.

Action:

• Static Value – Allows selecting the desired operation from a predefined list (e.g., start, stop, restart).
• Properties – Enables dynamic selection of the operation by referencing a specific field from the triggering event or rule, allowing the action to adapt based on runtime data.

Host:

• Specifies the target system where the action will be executed. This can be the originating host (where the triggering event occurred) or a designated system like a domain controller (e.g., DC09).

CredentialsGUID:

• Indicates the stored credentials from the CYBERQUEST server used to authenticate and execute the service command. Credentials are selected from a list (e.g., AgentLinuxRoot).

8.LinuxActions.BLOCK_IP_ADDRESS

This action blocks a specific IP address on a designated Linux host using defined parameters. It is typically used to prevent communication from potentially malicious sources.

IpAddress – Specifies the IP address to be blocked.

Host – Indicates the host on which the block action will be applied.

CredentialsGUID – Defines the credentials used to perform the action.

This action requires root access to execute.

IpAddress:

• Static Value – A specific IP address can be manually entered to apply a fixed blocking rule.
• Properties – Enables dynamic selection of the IP address from a rule and event instance (e.g., using the SourceIP field) to block addresses identified at runtime.

Host:

• Specifies the Linux host where the IP address will be blocked. This can be the host from which the triggering event was collected or a designated target system (e.g., Server02).

CredentialsGUID:

• Indicates which stored credentials from the CYBERQUEST server will be used to execute the command. Select from the available list (e.g., AgentLinux).

9.LinuxActions.REMOVE_BLOCK_IP_ADDRESS

This action removes a previously applied block on a specific IP address on a designated Linux host, based on the provided parameters.

• IpAddress – Specifies the IP address to unblock.
• Host – Indicates the host where the block removal will be performed.
• CredentialsGUID – Defines the credentials used to execute the action.

IpAddress:

• Static Value – A fixed IP address can be entered manually to specify which address to unblock.
• Properties – Allows dynamic selection of the IP address from a rule and event instance (e.g., SourceIP field), enabling unblock actions based on real-time event data.

Host:

• Specifies the Linux host where the block on the IP address will be removed. This can be the original host or another target system.

CredentialsGUID:

• Indicates which stored credentials from the CYBERQUEST server will be used to run the unblock command. Choose from the available list (e.g., AgentLinux).

10.LinuxActions.KILL_PROCESS_BY_PID

This action terminates a specific process on a Linux host using its Process ID (PID), based on the provided parameters.

• PID – Specifies the Process ID of the process to be terminated.
• Host – Indicates the host where the process termination will be executed.
• CredentialsGUID – Defines the credentials used to perform the action.

Root access is required to execute this action.

PID:

• Static Value – A fixed Process ID can be entered manually to specify which process to kill.
• Properties – Enables dynamic selection of the PID from a rule and event instance, allowing process termination based on real-time event data.

Host:

• Specifies the Linux host where the process termination will be carried out. This can be the originating host or a designated system.

CredentialsGUID:

• Indicates which stored credentials from the CYBERQUEST server are used to perform the kill operation. Select from the available list (e.g., AgentLinux).

11.LinuxActions.KILL_PROCESS_BY_NAME

This action terminates a Linux process based on its name, using the following parameters:

• ProcessName – Specifies the name of the process to be terminated.
• Host – Indicates the host where the process will be killed.
• CredentialsGUID – Defines the credentials used to perform the action.

ProcessName:

• Static Value – A fixed process name can be entered directly to specify which process to terminate.
• Properties – Supports dynamic selection of the process name from a rule and event instance, enabling process termination based on real-time event data.

Host:

• Specifies the target system where the action will be executed. This can be the originating host or another designated system.

CredentialsGUID:

• Indicates which stored credentials from the CYBERQUEST server are used to execute the action. Credentials are selected from the available list.

12.LinuxActions.CQ_SERVICES_STATUS

This action checks the status of CyberQuest services on a specified host, using the following parameters:

• Host – Specifies the target system where the service status check will be performed.
• CredentialsGUID – Defines the credentials used to execute the status query.

Host:

• Selects the system on which the CyberQuest service status will be checked. This can be the originating host or another designated system.

CredentialsGUID:

• Indicates which stored credentials from the CYBERQUEST server are used to perform the action, selected from the available list.

13.LinuxActions.VALIDATE_CERTIFICATE

This action validates SSL/TLS certificates on a specified host using the following parameter:

• Host – Specifies the target system where the certificate validation will be performed.

Host:

• Selects the system on which the certificate validation process will be executed. This can be the originating host or another designated system.

14.LinuxActions.CHECK_IF_OS_IS_WINDOWS

This action checks whether the specified host is running a Windows operating system, based on the following parameter:

• Host – Specifies the target system to verify the OS type.

Host:

• Selects the system on which the OS check will be performed. This can be the originating host or another designated system.

15.WindowsActions.DISABLE_USER

This action disables a specific Windows user account on the target host, based on the following parameters:

• TargetUser – Specifies the user account to be disabled
• Host – Indicates the system where the user account will be disabled
• CredentialsGUID – Defines the credentials used to perform the action

TargetUser:

• Static Value – A fixed username can be provided directly to specify the user account to disable.
• Properties – Supports dynamic selection of the user account from rule and event data (e.g., UserName field), enabling the action to target users identified in real time.

Host:

• Static Value – A fixed host name or IP address can be set as the target system.
• Properties – Allows dynamic selection of the host from rule and event information where the action will be executed.

CredentialsGUID:

• Specifies the stored credentials used by CYBERQUEST to perform the action, selected from an available list.

16.WindowsActions.ENABLE_USER

This action enables a specific Windows user account on the target host, based on the following parameters:

• TargetUser – Specifies the user account to be enabled
• Host – Indicates the system where the user account will be enabled
• CredentialsGUID – Defines the credentials used to perform the action

TargetUser:

• Static Value – A fixed username can be provided directly to specify the user account to enable.
• Properties – Supports dynamic selection of the user account from rule and event data (e.g., UserName field), enabling the action to target users identified in real time.

Host:

• Static Value – A fixed host name or IP address can be set as the target system.
• Properties – Allows dynamic selection of the host from rule and event information where the action will be executed.

CredentialsGUID:

• Specifies the stored credentials used by CYBERQUEST to perform the action, selected from an available list.

17.WindowsActions.START_SERVICE

This action starts a specified Windows service on the target system, based on the following parameters:

• TargetService – Identifies the service to be started
• Host – Indicates the system where the service should be started
• CredentialsGUID – Defines the credentials used to execute the action

TargetService:

• Static Value – A specific service name can be provided directly (e.g., Spooler) to be started.
• Properties – Allows dynamic identification of the service name using rule and event fields, enabling contextual response.

Host:

• Static Value – A predefined hostname or IP address can be manually entered.
• Properties – Allows dynamic selection of the host from rule and event information where the action will be executed.

CredentialsGUID:

• Specifies which stored credentials from CYBERQUEST are used to start the service. The credentials are selected from a predefined list.

18.WindowsActions.STOP_SERVICE

This action stops a specified Windows service on the target system using the parameters below:

• TargetService – Specifies the service to be stopped
• Host – Indicates the system where the service is running
• CredentialsGUID – Defines the credentials used to execute the action

TargetService:

• Static Value – Enter the exact name of the service to be stopped (e.g., Spooler).
• Properties – Dynamically determines the service name from event context fields, allowing context-aware service control.

Host:

• Static Value – Manually specify a fixed host (hostname or IP).
• Properties – Allows dynamic selection of the host from rule and event information where the action will be executed.

CredentialsGUID:

• Selects the credential from the CYBERQUEST server to authorize the action. Credentials are chosen from a predefined list.

19.WindowsActions.RESTART_SERVICE

This action restarts a specific Windows service on a designated host, based on the following parameters:

• TargetService – Defines the Windows service that will be restarted
• Host – Specifies the system where the service restart will be executed
• CredentialsGUID – Indicates the credentials used to authenticate and perform the action

TargetService:

• Static Value – A fixed service name can be entered directly in the Static Value field to identify the service to restart.
• Properties – Allows dynamic selection of the service name from a rule and event instance, making the action responsive to contextual event data.

Host:

• Static Value – A specific host name can be entered directly to identify where the service will be restarted.
• Properties – Dynamically retrieves the host from the rule or event data, targeting the system that triggered the alert.

CredentialsGUID:

• Specifies which stored credentials from the CYBERQUEST server will be used to perform the operation. The appropriate credential (e.g., AgentWindows) is selected from a predefined list.

Alert Detail Properties

Clicking the icon in the Alert Name column opens the Alert Viewer pop-up, where detailed alert information and configuration options are available for review and adjustment.

Alert Summary Panel

This panel provides a quick overview of the alert’s key metadata, including the alert name, creation and modification timestamps, security score and level:

• Alert Name - Displays the name of the alert. Example: UBA - User Logon from Multiple IP Addresses.

• Added - Shows the date and time when the alert was created or added to the system.

• Modified - Indicates the last date and time when the alert configuration was updated.

• Sec. Score - Displays the calculated Security Score, a numerical value that reflects the severity or impact level of the alert based on predefined scoring rules.

• Sec. Level - Represents the Security Level, a simplified classification of alert severity (e.g., from low to critical), determined by the system based on scoring thresholds.

Alert Configuration Panel

This panel allows further classification and contextualization of the alert. Users can assign tags, associate the alert with MITRE ATT&CK techniques, specify alert folders, assign ownership, and view normalization settings.

• Tags - Allows assigning custom tags to the alert, enabling efficient categorization, filtering, and management based on operational context or threat attributes. Tagging can support compliance and reporting requirements aligned with standards such as ISO 27001, NIS2, NIST 800-53, GDPR, and CIS Control V8, by helping classify alerts according to security controls, data types, or regulatory impact.

• MITRE ATT&CK - Allows mapping the alert to a corresponding MITRE ATT&CK tactic or technique. This supports alignment with industry-standard threat intelligence and aids in threat classification.

• Alert Folders - Lets users organize the alert into specific folders for easier management, access control, or workflow segmentation.

• Alert Assignee - Assigns responsibility for the alert to a specific user. This helps with task ownership and facilitates alert triage and resolution.

• Normalization - Displays the applied normalization profile. This defines how raw event data is standardized to a consistent schema, enabling effective correlation and analysis.

Alert Normalization

Alert Normalization ensures consistency across alerts by assigning predefined values to specific fields. This process simplifies alert categorization, integration with external systems, and compliance with organizational or regulatory standards.

Normalization is especially useful when alerts originate from various data sources with differing formats. By mapping fields to standardized values, alerts become easier to correlate, filter, and report.

Accessing Normalization Settings To configure normalization:

• Navigate to the Normalization section.

• In the dropdown list, a default normalization profile is displayed (named default).

​ Note: The default profile is not editable.

• To create a custom normalization, type a new name in the input box below the dropdown.

• Clicking the newly entered name opens the Add Alert Normalization interface for customization.

• Click the button to add field-to-value mappings for alert normalization.

Name: Specifies the name of the normalization profile (e.g., default). It identifies the configuration applied to alerts when normalization is triggered.

Field: The path to the actual data within the alert structure (e.g., TriggeredRules[0].AssociatedEvents[0].UserName).

Value: Specifies the normalized label (e.g., UserName, SourceIP, LogonTime) that will represent this data in a standardized format.

Once the configuration is complete, click Save to apply the alert normalization settings. To discard any changes and close the configuration window, click Cancel.

• Options are available to edit or delete the alert normalization configuration.

Summary alerts

Summary alerts customization

Summary alerts are used to group historical event data based on defined conditions within reports.

For example, when using CYBERQUEST to monitor business applications, summary alerts can be configured to group discount values by country or other relevant fields.

Unlike real-time alerts, which are generated instantly by the Data Correlation service as events are ingested, summary alerts operate on processed historical data. These events are aggregated every 10 minutes and can be grouped using custom-defined keys for statistical analysis.

To manage summary alerts, navigate to Settings > Alerts > Summary. This opens the Registered Summary Alerts page, where you can:

• View all configured summary alerts
• Create new summary alert definitions
• Edit or delete existing alerts
• Toggle alert activation status (active/inactive)

The Actions menu provides quick access to these management options for each alert entry.

Click the button, to modify the alert. Below is a detailed overview of each configuration available on the Edit registered summary alert page:

• Name - Displays the name of the registered summary alert.

• Report - indicates the report for which current summary alert is generated

• Security Score and Security Level - Define the baseline risk level associated with this summary alert. These values contribute to internal anomaly scoring, as also used in real-time alert definitions.

• SummaryOn Level n, Time, TimeInterval Unit, Summary Type, Split Into Groups of, and Threshold – Parameters used to define how data is grouped and evaluated for the summary alert.

• Notifications - Specifies the recipient email addresses for alert notifications. Enter one address per line without separators.

• Template Used for Notification - Drop-down menu listing available templates for formatting email notifications.

• Is Active? - Specifies whether the summary alert is currently enabled.

• Active - The alert is running and will generate summary events based on the defined conditions.

• Inactive - The alert is turned off and does not evaluate or generate any summary results.

• Active Post Process - This section allows you to define post-processing logic for the summary alert, applying additional filtering or evaluation through a simple algorithm. When enabled, the following configuration fields appear:

• Algorithm Type - Drop-down list with available post-processing algorithms.

  • DistinctCount - Counts the number of distinct values in a specified field within the alert's summary dataset.

• Field – The field on which the algorithm operates (e.g., LocalTime).

• Precision – Defines the level of time granularity for evaluation.

Available options:

HOUR – Group results per hour.

DAY – Group results per day.

• Threshold – The minimum value required to trigger the post-processing condition.

  Example: 3 means the condition is met if there are 3 or more distinct values based on the selected field and precision.

• Has Script - Specifies whether a custom script is associated with the alert.

• Enabled – A script is attached and will be executed as part of the alert’s processing workflow.
• Disabled – No script is assigned to the alert.

Press the Save button to save changes and return to the Registered Summary Alerts page, or press the Cancel button to discard changes and exit without saving.

Creating a new registered summary alert

To create a new summary alert, select the Add Registered Summary Alert option available on the pages mentioned above. This will open the New Summary Alert page, where the available settings are similar to those described in the Edit Summary Alert section.

• Enter a unique name for the new summary alert in the Name field.
• From the Report drop-down list, select the report for which the summary alert will be generated.
• Specify baseline values for the summary alert's security threat in the Security Score and Security Level fields. If unsure, a default value of 50 for Security Score and 5 for Security Level is recommended.
• In the SummaryOn Level n drop-downs, select the event fields to summarize. At least a value for Level 1 is required for the summary alert to function.
• Set the Time value and corresponding TimeInterval Unit (minutes, hours, days, weeks, months, quarters, or years) to define the time window for the summary- counting backward from the current moment (e.g., 3 days ago).
• Choose the Summary Type (count, sum, or average) based on the required aggregation.
• Define the Split Into Groups of value to determine how results are grouped. The default grouping is by minutes.
• Enter a Threshold value representing the maximum number of grouped events that will trigger the alert (e.g., 1000 for a region).
• In the Notifications field, list email addresses for summary alert delivery, one address per line without separators.
• Optionally, select a Template Used for Notification to format the alert message.
• Is Active? - Determines if the summary alert is enabled.
• Active: The alert runs and generates summary events.
• Inactive: The alert is disabled and not evaluate or generate any summary result
• Active Post Process - Enables additional filtering or evaluation using a selected algorithm on the summary data. Configure algorithm type, target field, precision (hour/day), and threshold to control how the post-processing affects alert triggering.
• Has Script - Indicates if a custom script is linked to the alert.
• Enabled: Script runs during alert processing.
• Disabled: No script assigned.

Press the Save button to save changes and return to the Registered Summary Alerts page, or press the Cancel button to discard changes and exit without saving.

Configuring a Logon summary alert scenario example

This scenario notifies the security officer when a user fails to authenticate more than 50 times within a day.

Step 1: Create the Report

Develop a report that filters relevant events—in this case, “An account failed to log on.” When run, the report will identify all matching events and send notifications containing details such as network address, username, date, and time. To create this report:

• Open the Browser module.

Search for EventID:4625 (the Windows event ID for “An account failed to log on”). Use Filter Data to display matching events.

Click Save and select Save as New Report.

Enter “An account failed to log on” as both the Name and Description.

By default, the report will be saved in the Custom Reports folder under the Reports module.

Step 2: Create the Summary Alert

Create a new summary alert based on the report:

• Navigate to Settings > Alerts > Summary.
• Click New Registered Summary Alert.
• Configure the following settings:
• Select the custom report created in Step 1.
• Set Security Score to 50 and Security Level to 5.
• Set SummaryOn Level 1 to UserName.
• Set SummaryOn Level 2 to Computer.

Step 3: Review Results

Monitor the alert results for triggered notifications.

DTS Alerts

DTS Objects

Data Transformation Service (DTS) enables alert generation by evaluating internal object lists. These objects support operations including log enhancement, data enrichment, decision-making, alerting, and other processing tasks.

A CYBERQUEST event has the following format:

{
  "EventID": "1-2000000000",
  "LocalTime": "yyyy-mm-dd hh:mm:ss.fff",
  "GMT": "yyyy-mm-dd hh:mm:ss.fff",
  "UserName": "blacklisted.user1",
  "UserDomain": "Demo",
  "SrcIP": "xxx.xxx.xxx.xxx",
  "DestIP": "xxx.xxx.xxx.xxx",
  "VersionMajor": "6",
  "VersionMinor": "2",
  "Computer": "A-PC.Demo.local",
  "Source": "Microsoft-Windows-Security-Auditing",
  "EventLog": "Security",
  "Category": "Logon",
  "EventType": "8",
  "Description": "An account was successfully logged on.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-0-0\r\n\tAccount Name:\t\t-\r\n\tAccount Domain:\t\t-\r\n\tLogon ID:\t\t0x0\r\n\r\nLogon Type:\t\t\t3\r\n\r\nImpersonation Level:\t\tImpersonation\r\n\r\nNew Logon:\r\n\tSecurity ID:\t\tS-1-5-21-1009658894-4016096118-1013530418-1275\r\n\tAccount Name:\t\tblacklisted.user1\r\n\tAccount Domain:\t\tDemo\r\n\tLogon ID:\t\t0xC2C9FA762\r\n\tLogon GUID:\t\t{00000000-0000-0000-0000-000000000000}\r\n\r\nProcess Information:\r\n\tProcess ID:\t\t0x0\r\n\tProcess Name:\t\t-\r\n\r\nNetwork Information:\r\n\tWorkstation Name:\tRemoteWorkstation\r\n\tSource Network Address:\t10.10.10.10\r\n\tSource Port:\t\t44214\r\n\r\nDetailed Authentication Information:\r\n\tLogon Process:\t\tNtLmSsp \r\n\tAuthentication Package:\tNTLM\r\n\tTransited Services:\t-\r\n\tPackage Name (NTLM only):\tNTLM V1\r\n\tKey Length:\t\t128\r\n\r\nThis event is generated when a logon session is created. It is generated on the computer that was accessed.\r\n\r\nThe subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\r\n\r\nThe logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).\r\n\r\nThe New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.\r\n\r\nThe network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\r\n\r\nThe impersonation level field indicates the extent to which a process in the logon session can impersonate.\r\n\r\nThe authentication information fields provide detailed information about this specific logon request.\r\n\t- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.\r\n\t- Transited services indicate which intermediate services have participated in this logon request.\r\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\r\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.",
  "S1": "S-1-0-0",
  "S2": "-",
  "S3": "-",
  "S4": "0x0",
  "S5": "S-1-5-21-1009658894-4016096118-1013530418-1275",
  "S6": "blacklisted.user1",
  "S7": "Demo",
  "S8": "0xc2c9fa762",
  "S9": "3",
  "S10": "NtLmSsp ",
  "S11": "NTLM",
  "S12": "RemoteWorkstation",
  "S13": "{00000000-0000-0000-0000-000000000000}",
  "S14": "-",
  "S15": "NTLM V1",
  "S16": "128",
  "S17": "0x0",
  "S18": "-",
  "S19": "10.10.10.10",
  "S20": "44214",
  "S21": "%%1833",
  "S150": ""
}

S1 to S150 are extended string fields commonly used to store extracted, meaningful information from events. This data can then be correlated in dashboards or used to define alerting conditions.

Example: A DTS object can evaluate against a dynamic or static list of blacklisted or unknown users. The getter function checks whether the current user appears in a specified list (e.g., blacklist or whitelist).

• Case 1: If the user exists in a blacklist, an alert can be triggered using the RaiseAsAlert function to signal unauthorized access.

• Case 2: The user is on a whitelist: no alert is generated; however, relevant data can still be parsed and stored if necessary.

• Case 3: If the user is not found in either list, the setter function can be used to automatically add the unknown user to a blacklist.

To allow a DTS object to process an event, the following three prerequisites must be met:

Create a DTS object

A new DTS object can be created by navigating to the Settings > Rules > DTS Objects page. Use the Add button on the page to define and create a new DTS object.

Create a Filter rule

A filter rule defines the conditions that incoming events must meet to be processed by one or more DTS Objects.

To create a new filter rule, navigate to Settings > Rules > Filter Rules. Use the ADD button on the page to configure and save the rule.

Create a DA rule (data acquisition rule)

A DA rule defines the decision-making process that routes events - filtered by previously defined Filter Rules - through DTS Objects and forwards them to the Data Storage and/or Data Correlation services.

To create a new DA rule, go to Settings > Rules > DA Rules and click the Add button to configure and save the rule.

For more details on DTS objects, refer to the following section: DTS.

DTS Objects Built-in methods

DTS objects support built-in functions designed to interact with Redis lists and the alerting module. One of the available methods is:

1)setter function

Used to insert or update values in Redis lists.

Parameters: [list_name],[list_key],[list_value][TTL]

Example:

setter('UserLists', Event.UserName, Event.SrcIP, 360);

This example checks the "UserLists" Redis list for the value of the event’s UserName field.

• Case 1: If the key (UserName) already exists, the function updates its value with SrcIP and resets the TTL (time to live) to 360 seconds.
• Case 2: If the key does not exist, a new entry is created with UserName as the key, SrcIP as the value, and a TTL of 360 seconds.

2)getter function

This function obtains values from Redis lists.

Parameters: [list_name], [list_key]

Example:

getter('IPLists', Event.SrcIP);

In this example, the DTS object queries the IPLists Redis list using the value of the event’s SrcIP field as the key and returns the associated value, if present.

3)RaiseAsAlert function

This function triggers an alert event based on custom parameters.

Parameters: [event_list] (JSON format), [alert_name], [email_address(es)], [security_score], [security_level], [alert_template]

Example:

RaiseAsAlert(Event.getAsJSON(), "MultipleLogins(10)", "[email protected]", "7", "7", "Multiple Logins(10)");

In this example, the DTS object sends an alert named "Multiple Logins (10)" to [email protected], assigning it a security score of 7 and a security level of 7.

4)backEvents function

This function searches past events based on a specified string and returns matching results in JSON array format.

Example:

backEvents('SearchString', NumberOfDays, NumberOfEvents);

• SearchString – The query string used to filter historical events.

• NumberOfDays (optional) – Time window to look back; defaults to 100 days if not specified.

• NumberOfEvents – Maximum number of events to return.

5)backCount function

Returns the number of events that match a specified search query within a given time range.

Example:

backCount('SearchString', NumberOfDays);

SearchString – The term or condition used to filter past events.

NumberOfDays – The time range (in days) to look back when counting matching events.

6)ConsoleLog function

Writes the specified string to the acquisition log file.

Example:

ConsoleLog(String);

The message is logged to: /var/log/data-acquisition.log

Alert scenarios

Alerts examples

Example 1. Create a Logon alert scenario example

This scenario demonstrates how to configure a real-time alert that triggers when a specific user experiences two failed logon attempts within a 60-second window.

Step 1:

Navigate to Settings > Alerts > Realtime.

Click CREATE ALERT to begin configuring the new alert.

Step 2:

Create an alert definition with the following parameters:

• Name: Default - Audit policy change
• ALERT ACTIVE: Active
• Alert Security Score: 40
• Alert Security Level: 5
• Send as Alert: Active

Step 3:

Add a new rule to the alert definition using the criteria below:

• Description: Audit policy change events

• Event ID: 4719

Event IDs can be referenced in the Event Dictionary

Step 4:

Save the alert definition. It will now appear in the Alerts list.

The new definition shows in Alerts page

Step 5:

Once configured, the system will generate alerts in real time whenever the defined conditions are met. In this example, the alert triggers upon detecting Windows Event ID 4719 (Audit Policy Change) from the Windows Security Log.

Example 2. Configuring a Logon summary alert scenario example

This scenario sets up an alert to notify the security officer when a user fails to authenticate more than 50 times within a single day.

Step 1:

Create a report that defines the alert conditions - for example, events where authentication fails (EventID 4625: An account failed to log on). This report identifies matching events and can be configured to send notifications containing key details like the network address, username, date, time etc.

• Open the Browser module
• Search for EventID:4625 (Windows event ID for failed logon)
• Click Filter data to display relevant events
• Click Save and select Save as New Report
• Enter a name and description such as An account failed to log on
• By default, the report will be saved under Custom Reports in the Reports module

Step 2:

Create a new summary alert using the previously saved report:

• Navigate to Settings > Alerts > Summary

• Click ADD REGISTERED SUMMARY ALERT

• Configure the summary alert with the following settings:

• Report: the saved custom report
• Security Score: 50
• Security Level: 5
• SummaryOn Level 1: UserName
• SummaryOn Level 2: Computer

Step 3:

Monitor the results to verify that alerts are triggered when the threshold is exceeded.

Example 3. Distributed Denial of Service (DDoS)

Alert description

This alert is designed to trigger when 100 or more communication events are directed to the same IP address and port within one minute, originating from different source IPs. The scenario identifies potential Distributed Denial of Service (DDoS) attempts.

Required Data Sources

• Firewall NetFlow events must be collected and available in CYBERQUEST for this alert to function correctly.

Alert setup

From the Settings menu, navigate to Alerts > Realtime.

1)Rule 1 - Identify NetFlow Events

• EventID: 63805, 63809

• Use the isinList operator to detect events with the specified IDs.

2)Rule 2 - Set DDoS Detection Criteria

In the Rule 2 section, configure the following:

• Min Threshold: 100

• Max Threshold: 150

• TTL: 60 seconds

• SrcIP ≠ Rule No. 1 **SrcIP **

• AND

• DestIP = Rule No. 1 DestIP

To export the alert settings as a CQO configuration file, use the following link: Alert Object.

Example 4. Application credentials sharing

Alert description

Detects a scenario where a Windows logon is followed by an application logon from the same IP address but with a different user account - indicating potential credential sharing.

Required Data Sources

To configure this alert, the following data sources must be collected in CYBERQUEST:

• Windows Security Log with Logon auditing enabled via Group Policy (GPO)

• Application logon audits that include both username and source IP address

Alert setup

Navigate to Settings > Alerts > Realtime.

1)Rule 1 - Windows Logon Event

Identify Windows Success Logon events using Event ID 4624. Configure as follows:

• EventID = 4624

2)Rule 2 - Application Logon Event

Capture application login activity with different credentials from the same source IP:

To do that:

• EventID = ApplicationLoginEventID
• AND
• SrcIP = Rule No. 1 SrcIP
• AND
• UserName ≠ Rule No. 1 UserName

To export the alert configuration as a .cqo file, use this link: Alert Object.

Example 5. Malicious IP or domain

Alert description

This alert triggers when communications occur between internal IP addresses and those listed in a blacklist containing known malicious IPs and domains.

Required Data Sources

To enable this alert, the following data must be collected in CYBERQUEST:

• Network communication events;
• Blacklist and/or security feeds.

Alert Configuration

Navigate to Settings > Alerts > Realtime.

In Rule 1, enter the following settings:

• SrcIP isinList @BlackListDomains

• AND

• DestIP isinList @BlackListDomains

To export the alert configuration as a CQO format file, use the following link: Alert Object.

Example 6. Successful login after multiple attempts

Alert description

Triggers an alert when a user successfully logs in after at least five failed attempts within a 10-minute window.

Data Sources Required

To enable this alert, ensure the following data source is being collected in CYBERQUEST:

• Windows Security Log with Logon auditing enabled via Group Policy.

Alert Setup

• Open the CYBERQUEST Web Interface.

• Navigate to Settings > Alerts > Realtime.

• Create a new alert by clicking the button.

• Add the first rule to detect Windows Failed Logon events by clicking and setting EventID = 4625.

• Add the second rule by clicking , and configure UserName = Rule No. 1 UserName.

• Add the third rule with a correlated condition:
• UserName = Rule No. 1 UserName
• EventID = 4624 (successful logon)

• Click the button at the top-left to save the alert configuration.

To export this alert setup in CQO format, use the following link: Alert Object.

Example 7. Traffic to infected domains

Alert Purpose

This alert is triggered when access to malicious domains listed in @BlackListDomains is detected.

Data Sources Needed

• Web access events

Description

• Open the CYBERQUEST Web Interface.

Navigate to Settings > Alerts > Realtime.

Click the button to create a new alert.

• Rule 1 – Configure the condition as follows:

EventID = [Event ID for web access events]

Accessed domain field isinList @BlackListDomains

To export this alert setup in CQO format, use the following link: Alert Object.

Example 8. VPN Login and RDP with different users

Alert Purpose

This alert is triggered when a VPN login is followed by an RDP connection from the same host but using a different user account than the one used for the VPN session.

Required Data Sources

• VPN login events
• Windows Security Log

Configuration Steps

• Open CYBERUEST Web Interface.

• Navigate to Settings > Alerts > Realtime.

• Click the button to create a new alert.

1)Rule 1 – Detect VPN login events:

• EventID isinList 1660049, 1660009

2)Rule 2 – Detect RDP login from the same host using a different user:

• EventID = 4624
• S9 = 10
• UserName ≠ Rule No. 1 UserName
• S15 = Rule No. 1 S19

To export this alert setup in CQO format, use the following link: Alert Object.

Notification templates customization

From the Settings menu, navigate to Alerts > Notification templates. This opens the Alert Templates section of the Alerts customization interface.

The Actions menu allows editing or deleting existing alert templates. The Alert Templates page lists all defined templates and includes an option to create a new one.

To create a new alert template, select the NEW ALERT TEMPLATE option from any of the pages mentioned above. This opens the NEW ALERT TEMPLATE page. The available settings are similar to those in the Edit Alert Template page, accessible from the Alert Templates list.

• In the Name field, enter a unique name for the alert template.

• From the Please select a rule drop-down list, choose the rule (e.g., Rule1, Rule2, Rule3, or Rule4) that the template will reference.

• In the Please select either alert section or event data field, specify whether to use an alert section or event data as the source.

• In the Text field, enter a descriptive message or insert dynamic objects as needed.

Click the button to save the changes and return to the Alert Templates page.

Viewing Alerts

Working with Alerts Module

The Alerts module in CYBERQUEST provides real-time visibility into security incidents and policy violations. It allows users to monitor, filter, and investigate alert events generated based on predefined rules and thresholds. This section outlines how to navigate the Alerts interface, apply filters, and interpret results to support security operations and incident response.

Access the Alerts module by clicking the button located on the left-hand panel of the Web Interface.

The module is divided into two main sections:

• Search and Filter - Enables precise control over the alert data displayed.
• Results - Displays alert records based on the selected filters and search criteria.

Alerts Search and Filter section

This section provides control over which alerts are shown in the results list. To access it, expand the filters by clicking the button. Once expanded, the filtering options become available.

The Search field allows filtering of displayed alerts using free-text input. If left empty, all available events are shown.

A detailed guide on using free-text search is included in this manual.

To control how many alerts are shown per page, press the button. The default is 10 items, but options for 50 or 100 are also available.

Other options in the Search and Filter section:

• Filter data - Applies the selected filters and updates the alert results list accordingly.
• Send to Dashboards - Opens the filtered results in the Dashboards module in a new browser tab.
• Send to Browser - Opens the filtered results in the Browser module in a new browser tab.

The Search and Filter section offers options to specify the date and time range for the displayed information. This is especially useful for quickly reviewing compliance within a chosen period.

Users can set a custom start and end date or select from predefined intervals like last hour, day, three days, ten days, 30 days, or 90 days. By default, the Alerts interface shows all alerts. Convenient buttons below the Start Date and End Date fields allow adjusting the time range and choosing the time reference, including GMT, Local Time, Received Time, Now, or enabling AutoRefresh.

GMT - Converts the selected time range to Greenwich Mean Time.

LocalTime - Refers to the local system time when the event actually occurred.

ReceivedTime - Indicates the moment the event was received by the CYBERQUEST system.

Now - Automatically updates the end time to the current moment.

AutoRefresh - Automatically refreshes the alert view every 10 seconds.

Alerts Results section

This section is the main area where triggered alerts are displayed. Alerts appear in chronological order, and the number of entries per page depends on the settings defined in the Search and Filter section. Multiple viewing formats are available for reviewing alert data:

• Open Folder View - Opens the folder-based navigation view, allowing users to browse alerts by folders or categories.
• Listing category - Displays the current classification of alerts based on the stage of the attack lifecycle or operational focus (e.g., tactics like as initial access, lateral movement, or data exfiltration).
• Unresolved Alerts - Displays all active alerts that have not yet been addressed or closed, requiring a status change to mark them as resolved.
• Latest Alerts - Displays the most recently generated alerts.
• My Latest Alerts - Shows the latest alerts that are specifically assigned to or created by the currently logged-in user.
• My Unresolved Alerts - Displays all unresolved alerts that are assigned to the current user, helping prioritize personal alert triage.
• Low Risk Alerts - Alerts that indicate low severity or impact, typically informational or minor issues that require minimal action.
• Medium Risk Alerts - Alerts representing moderate risk or impact that may require attention but are not immediately critical.
• High Risk Alerts - High-severity alerts indicating serious risks, threats, or failures that require urgent investigation and action.

Detailed functionalities of the Alerts page are covered under the Real-Time Alerts Customization section.

Clicking an alert name in the Alert Name column opens the Alert Viewer pop-up, where detailed information about the triggered alert. The following elements are particularly relevant for investigation:

• AlertSecurityLevel refers to the current security level of the triggered alert, calculated based on the baseline defined in the alert definition.

• AlertSecurityScore indicates the current security score of the triggered alert, also derived from the baseline specified in the alert definition.

• The Assets tab displays all assets associated with the triggered alert.

• The Computers tab displays all computers currently impacted by the alert.

• The DataSources tab lists the data sources that contributed to generating the alert.

• The EventSubCategories tab shows the event subcategories linked to this alert.

• In Users tab are listed all users currently affected by this alert.

• Selecting Alert Extra Info displays the unique alert ID along with the correlation index used to trigger the alert and compute its security level and score.

• Selecting Triggered Rules shows a brief report outlining which rules from the alert definition were activated.

• Clicking the button next to an entry opens a full report showing the events linked to that specific triggered rule.

View triggered alerts

This area displays all triggered alerts in chronological order. The number of alerts shown per page depends on the settings configured in the Search and Filter section.

Clicking the icon in the Alert Name column opens the Alert Viewer pop-up window, where detailed information about the triggered alert can be reviewed. The following elements are particularly relevant for investigation:

• RUN PLAYBOOK - Executes a predefined automated response procedure.
• MARK AS ACKNOWLEDGED - Flags the alert as reviewed or noted.
• MARK AS FALSE POSITIVE - Tags the alert as a non-threat or incorrect detection.
• MARK AS NEW - Resets the alert status to "new" for further review.
• CREATE INVESTIGATION CASE - Opens a new investigation case based on the alert.
• ADD TO EXISTING INVESTIGATION - Links the alert to a previously created investigation case.
• ADD DEDUPLICATE ITEM - Marks this alert as a duplicate of another.
• SET DEDUPLICATE OF - Assigns another alert as the original this one duplicates.
• CHANGE USER CLASSIFICATION - Updates the threat classification of the involved user.
• DOWNLOAD - Saves the alert details locally as a JSON file format.
• DELETE - Removes the alert.

Manage Alerts

• To remove a triggered alert, open the Alerts module by clicking the button located on the left-hand side of the web interface. This action opens the alert management window.

Clicking the icon in the Alert Name column opens the Alert Viewer pop-up, where detailed information about the triggered alert can be reviewed and analyzed.

• The Alert History tab provides a chronological log of actions taken on the alert. It displays key information including the user who performed the action, the date it occurred, the current status of the alert, and notes or comments added during the action

Use the Alert History tab to review all management activities taken on the alert :

• Alerts can be assigned to specific users for resolution:

• The alerts report is available for download in HTML format.

• RUN PLAYBOOK - Allows manual selection of an action from the playbook list to execute on the alert/event.

Alerts Manual Deduplication

Manual deduplication enables the consolidation of functionally identical or closely related alerts by linking them to a primary alert. This reduces redundancy in the alert list and supports streamlined processing and correlation during analysis.

To perform manual deduplication:

1.In the Alerts module, identify the alert entry to be deduplicated.

2.Press the ADD DEDUPLICATE ITEM or "SET DEDUPLICATE OF" button, available in the alert's row or Alert Viewer interface.

Deduplication Options:

• Add Deduplicate Item: Assigns the current alert as a duplicate of another, treating it as part of an existing incident.
• Set Deduplicate Of: Allows the user to define which alert is the primary (root) alert that other duplicates will be linked to.

Once an alert is manually marked as a duplicate, it becomes visually grouped with its root alert. This grouping simplifies alert management and helps prevent redundant analysis.

Create Investigation Case

For detailed instructions on creating an investigation case, refer to the Case Management section.