Alerts Module

Creating alerts

Introduction to Alerts Module

CYBERQUEST's alerting feature is a a customizable module for each connected user. The event triggering an alert can be user-defined to respond to specific event needs, ensuring great accuracy and reducing false alerting to a minimum. This can be done from Alerts options in Settings menu.

Customization capabilities for each option is described below.

How to create new alerts

CYBERQUEST's alerting feature is a completely customizable module for each connected user. The event triggering an alert can be user-defined to respond to specific event needs, ensuring great accuracy and reducing false alerting to a minimum.

Follow the steps to create a new alert:

Step 1. Authentication

To access Web Interface, open a web browser and type the application's address or DNS name. The default address initially assigned to Web Interface is https://CyberquestIPAddress (example).

The browser automatically redirects you to CYBERQUEST's authentication page:

Step 2. Navigate to Alerts

From Settings menu, select Alerts > Realtime. Alerts customization page opens in 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: The name of the new alert.

Alert Active: Select ALERT ACTIVE checkbox if the alert is active or uncheck to deactivate it.

Time Frame TTL(sec.) : This setting instructs the alert for how long to be active once triggered.

Alert Security Score: When an alert is triggered, its security score will dynamically change value starting from this defined baseline, depending on defined rules and number of events. A real time security score cannot be lower than defined baseline and higher than 100.

Alert Security Level: Security levels behave in a similar manner to security scores and support the same color coding.

Sent as Alert: Send as Alert checkbox has a similar effect to ALERT ACTIVE checkbox. When unchecked, the alert is active but will not produce any visible effect. This setting ensures backend correlation of anomaly analysis over multiple events, triggers and alerts.

Has Action: If a script execution can be associated with the alert, check also Has Action checkbox. Script rule is the last rule in rule conditions list and prevails all other rules. Press . button to open Script Editor window where you can create a custom script to apply as rule.

Send via Email: Send via Email checkbox allows the alert being sent to defined recipients.

Notification Template: Choose a notification template to apply to your alert. You can choose from built-in or custom notification templates. Default is Default notification.

Under Rules section, you can granularly define rules controlling the alert behaviour. You can define from single event rules to any correlation between events, order in which events occur, correlation to missing an event from a logical succession of events and so on.

Previous: Navigate through the condition of an alert.

Next: Navigate through the condition of an alert.

Add Rule: Add a new rule by pressing "Add Rule" button. The new rule is defined in Rule Settings pane to the right.

Rule Settings pane assists you defining the rule logic. Rule logic consists of field, report and correlation conditions separated by logical operators AND, OR and NOT.

Each rule has:

Description: A Description where you enter a text describing the rule.

Add field condition: In Select Field drop-down, select a representative event field. From the next drop-down select the appropriate value operator. In the third field enter desired value.

Add report condition: The rule condition presents you with a drop-down list from which you can select a report from all existing reports.

Delete: You can delete a rule condition.

When adding a rule condition, a logical operator is automatically added for correlation to the previous condition. The default operator is AND. Click on AND switch to change the logical value to OR. Click again to change back to AND.

If logical chain requires, a "NOT" operator is also added in the form of a checkbox. By default, the operator is not selected. Click NOT to select the operator.

Real time alerts

Real time alerts customization

From Settings menu, select Alerts > Realtime. Alerts customization page opens in Alerts module interface. All alert definitions are listed here and can be edited, deleted or quickly exported to a CQO file.

Press button to create a new alert definition. Alert Settings window opens, allowing you to create a new custom alert specific to your needs. The window functionalities are identical to the ones for editing an alert and are described later in this chapter.

Press to import an alert definition from an existing CQO file.

At the bottom of page, a navigation selector allows you to navigate through pages containing 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.

• Choose a notification template to apply to your alert. You can choose from built-in or custom notification templates. Default is Default notification.

• Select ALERT ACTIVE checkbox if the alert is active or uncheck to inactivate it.

• Change the predefined value for Time frame (TTL) or leave as default. This setting instructs the alert for how long to be active once triggered, reducing the number of repeating alerts

• Set an Alert Security Score baseline from 1 to 100. When an alert is triggered, its security score will dynamically change value starting from this defined baseline, depending on defined rules and number of events. A real time security score cannot be lower than defined baseline and higher than 100. Security scores are marked in colour code:

• Green color indicates a low alert. Maximum is 30

• Yellow color indicates a medium alert. It ranges from 31 to 60

• Red color indicates a high alert. It ranges from 61 to maximum 100.

• Set an Alert Security Level baseline from 1 to 10. Security levels behave in a similar manner to security scores and support the same color coding.

• Send as Alert checkbox has a similar effect to ALERT ACTIVE checkbox. When unchecked, the alert is active but will not produce any visible effect. This setting ensures backend correlation of anomaly analysis over multiple events, triggers and alerts.

• Send via Email checkbox allows the alert being sent to defined recipients.

• If a script execution can be associated with the alert, check also Has Action checkbox. Script rule is the last rule in rule conditions list and prevails all other rules. Press button to open Script Editor window where you can create a custom script to apply as rule or predefined Actions from the list (LinuxActions, Notifications.Teams,Jira etc.)

For more information about Action Parameters please follow the link: How to activate automatic Actions in Realtime Alerts

Under Rules section, you can granularly define rules controlling the alert behavior. You can define from single event rules to any correlation between events, the order in which events occur, correlation to an event missing from a logical succession of events and so on.

In the left pane are the lists with defined rules. The following actions are available:

• Add a new rule by pressing button. The new rule is defined in Rule Settings pane to the right.

• Navigate through defined rules using Previous and Next buttons. Selected rule is marked in yellow and its settings are shown in Rule Settings pane.

• You can delete a rule by pressing button.

The Rule Settings pane assists you in defining the rule logic. Rule logic consists of fields, reports and correlations conditions separated by logical operators AND, OR and NOT.

Each rule has:

• A Description where you enter a text describing the rule

• A Rule's Trigger Type presented as a drop-down list where you can choose from:

• A single event trigger

• 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)

• MaxTreshold, MinTreshold and TTL (sec.) values for rule's trigger type

  

MaxTreshold - the maximum number of events that must occur to generate the alert

MinTreshold - the minimum number of events that must occur to generate the alert

PivotField - sum of specific field (for e.g. for business applications: sum of money, sum of transactions)

You can add, edit or delete rule conditions:

• To add a field condition press button. In Select Field drop-down, select a representative event field. From the next drop-down select the appropriate value operator. In the third field enter desired value

• To add a report condition press button. The rule condition presents you with a drop-down list from which you can select a report from all existing reports.

• To add a correlation condition press button. The correlation condition presents you with two Select Filed drop-downs from where to choose the event fields to correlate, a comparison operator drop-down (equal, not equal, lower, lower or equal, bigger, bigger or equal) and the option to choose the rule condition to which correlation applies.

Remember that by adding a script rule, the script rule acts as the last rule condition in chain and its effect supersedes all other rule conditions defined above.

You can delete a rule condition by pressing button at the far right of your rule condition.

When adding a rule condition, a logical operator is automatically added for correlation to the previous condition. The default operator is AND. Click on switch to change the logical value to OR. Click again to change back to AND.

If logical chain requires, a NOT operator is also added in the form of a checkbox. By default, the operator is not selected. Click to select the operator. In that case, the logical expression interpreted within your rule will be AND NOT, OR NOT respectively.

Note that all rule conditions are added in order, one subsequent to the other.

When finished, press button at the top to save your rule and return to the alert definitions list, or press button to cancel all changes.

Script rule example:

var obj = {
    Exec:function(Alert) {

    var currentAlertState =  JSON.parse(Alert);

    // in order to filter the current alert just based on custom scenarios
    // return null;

   }
};

Create a Logon alert scenario example

This scenario presumes setting up an alert for a specific user who has two failed logons during a 60 seconds time interval.

Step 1:

Go to Settings > Alerts > Realtime

To add the new alert, press Create new alert definition button in the Alerts page.

Step 2:

Create "Default - Audit policy change" alert definition with the following settings:

• Name: Default - Audit policy change

• Alert is active

• Security score of 40

• Security level of 5

Step 3:

Define a new rule with the following settings:

• Description: Audit policy change events

• EventID: 4719

EventID can be searched in Event Dictionary: Event Dictionary

Step 4:

Save the alert definition

The new definition shows in Alerts page

Step 5:

All alerts are generated in real time when conditions defined are met, and are displayed as events in Alerts mode interface. In this example, the alert was generated based on collecting an event with ID 4719 (Audit policy change) from Windows Security Log.

How to activate automatic Actions in Realtime Alerts

To use predefined Automatic Actions you should firstly create a new alert or edit /open pre-built scenarios/alerts.

To create new alert, please follow the link:

To access Action Parameters you have to open ALERT SETTINGS menu, for this select Settings > Alerts > Realtime. Alerts customization page opens in Alerts module interface.

When you create a new alert or edit an alert you will find Has Action checkbox:

Press button to open Script Editor window where you can create a custom script to apply as rule or predefined Actions from the list:

When choosing a specific action (e.g. LinuxActions Disable_User) you can activate automatic response scenario. It could be disable, enable Linux users, Email or messenger Notifications etc.

An action is raising, followed by alerts, which is generated based on specific events.

There are following predefined automatic actions at this moment:

LinuxActions.DISABLE_USER

This action deactivate or remove specific Linux users from using target host based on parameters:

• Target User (which user to disable)

• Host (on which host to deactivate the user)

• CredentialsGUID (using which credentials to disable the user)

This action required root password access.

In case of this action the user will be removed and couldn’t login into his machine/host.

Target User:

• Static Value - it can be static and in Static Value you will write the name of the user to be disabled:

• Properties - can be dynamic, where you can select the rule and event number from the list using the UserName field (e.g.), to know which user you are disabling:

Host:

• It can be done on the host that appeared, or on domain control dc01 (e.g.):

CredentialsGUID:

What credentials is used from the CYBERQUEST server, and we select from the list (AgentWindows):

LinuxActions.ENABLE_USER

This action activate or restore specific Linux users (will be able to log in) based on parameters:

• Target User (which user to enable)

• Host (on which host to activate the user)

• CredentialsGUID (using which credentials to enable the user)

This action required root password access.

Target User:

• Static Value - it can be static and in Static Value you will write the name of the user to be enabled

• Properties - can be dynamic, where you can select the rule and event number from the list using the UserName field (e.g.), to know which user you are enabling

Host:

• It can be done on the host that appeared, or on domain control dc01 (e.g.).

CredentialsGUID:

• What credentials I use from the CYBERQUEST server, and we select what we have in the list (AgentWindows).

LinuxActions.EXPIRE_USER_PASSWORD

When this action is turned on for the users with expired password, these target users will not be able to log in with his password based on parameters:

• Target User (whose user password has expired)

• Host (on which host is expire the password)

• CredentialsGUID (using what credentials to expire the password)

Could be done by group administrator or user/not obligatory root user.

Target User:

• Static Value - it can be static and in Static Value you will write the name of the user whose password should be changed.

• Properties - can be dynamic, where you can select the rule and event number from the list using the UserName field (e.g.), to know to which user is expire the password.

Host:

• It can be done on the host that appeared, or on domain control dc01(e.g.).

CredentialsGUID:

• What credentials I use from the CYBERQUEST server, and we select what we have in the list (AgentWindows).

LinuxActions.DISABLE_PASSWORD_EXPIRE

When this action is enabled, Linux users will be restored and able to log in again into host based on parameters:

• Target User

• Host

• CredentialsGUID

Could be done by group administrator.

Target User:

• Static Value - it can be static and in Static Value you will write the name of the user which needs to be enabled

• Properties - can be dynamic, where you can select the rule and event number from the list using the UserName field (e.g.), to know to which user is disabled to password expire

Host:

It can be done on the host that appeared, or on domain control dc01 (e.g.).

CredentialsGUID:

What credentials I use from the CYBERQUEST server, and we select what we have in the list (AgentWindows).

Notifications Email/ Teams/Slack/Jira

Notifications Email/ Teams/Slack/Jira - this actions activate notifications on email or messenger Teams, Jira, Slack.

Notifications Content - specific message, which is indicted by user and will be received in case of risky events which activated this alert.

Summary alerts

Summary alerts customization

Summary alerts group data based on specific conditions in reports.

For examples if we use CYBERQUEST for business applications we can group discounts by value for specific country.

Summary Alerts is looking on historical events (summary based on statistic). These are the events that are generated every 10 minutes and user can group these events on certain keys.

Realtime alerts are generated by the Data Correlation service, correlate events that come in real time, and those that are in Summary have already gone through this step.

From Settings menu, select Alerts > Summary. Registered Summary Alerts page opens allowing you to manage registered summary alerts.

The Actions menu includes options for edit and delete a Summary Alert, and you can mark summary alerts as active or inactive. Registered Summary Alerts page opens, listing defined Summary Alert and here you have a option for adding a Registered Summary Alert.

Press to edit the alert. Below is a short description of each setting in Edit Summary Alert page:

• Name field, contains the registered summary alert name

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

• Security Score and Security Level fields display the baseline value for summary alert's security threat. As explained for alert definitions, this score is used for internal anomaly analytics scoring

• SummaryOn Level n, Time, TimeInterval Unit, Summary Type, Split Into Groups of and Threshold are values used to define the summaries for this registered summary alert

• Notifications field contains the email addresses where the summary alert will be sent. Type in one email address per line, without separators

• Template Used for Notification opens a drop-down listing all alert templates that can be used for notification

• On/Off selector allows you to specify if the summary alert is active or not

Press button to save changes and return to Registered Summary Alerts page.

To delete alerts, press button next to it. As a measure of precaution, you will be asked to confirm deletion.

Add Registered Summary Alert option allows you to create a new summary alert.

Creating a new registered summary alert

To create a new summary alert, select Add Registered Summary Alert option in any of the pages detailed above. New Summary Alert page opens, possible settings are similar to Edit Summary Alert page options described above:

• In Name field, enter a unique name for the new summary alert

• In Report drop-down list, select the report for which summary alert will be generated

• In Security Score and Security Level fields enter the baseline value for summary alert's security threat. If you don't know which value to type, entering 50 (5, respectively) is recommended in most cases

• In SummaryOn Level n drop-downs, select the event fields you need to summarize. You need to have a value at least for Level 1 in order for summary alert to function

• Enter a Time value for the TimeInterval Unit (minutes, hours, days, weeks or months) you need to create a summary - time from the current moment till specific value and time interval back ( for example 3 days ago from this moment).

• Summary Type can be a count, sum or average; select accordingly

• Select a value for Split Into Groups of setting. Default is to split by days

• Enter a Threshold - the maximum number of the group events which triggered the alert (for e.g. we apply 1000 as maximum for region).

• In Notifications field, enter the email addresses where the summary alert will be sent, in the form of one address per line, without separators

• You can select a Template Used for Notification, this is optional

• On/Off selector allows you to specify if the summary alert is active or not

Press button to save changes and return to Registered Summary Alerts page.

Configuring a Logon summary alert scenario example

The alerting scenario will be to notify the security officer if a user failed to authenticate for more than 50 times a day.

Step 1:

Create a report containing the alert definition (a report that shows all filtered events, in this case: "An account failed to log on"). Once executed, the report will find all events matching the report definition. It will also send a notification with relevant information like network address, username, date, time etc.). To achieve this result:

• Open Browser module

• Search for "EventID:4625" which is the Windows event ID for event: "An account failed to log on". Press Filter data to show matching events

• Click Save and select option Save as New Report

• Type in "An account failed to log on" for Name and Description fields

• By default, the new created report will be saved in Custom reports folder in Reports module

Step 2:

Create a new summary alert using the new created report. Open: Settings > Alerts > Summary and click on New Registered Summary Alert option.

Use the following settings:

• The custom report name

• A security score of 50 and a security level of 5

• SummaryOn Level 1: UserName

• SummaryOn Level 2: Computer

Step 3:

Check results.

DTS Alerts

DTS Objects

Data Transformation Service allows for arising alerts by checking the internal lists of objects. The objects are used for log enhancement, enrichment, decision making, alerting and other functionalities.

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 extra string fields and are generally used to store extracted useful information from the event. The purpose of this is to correlate that usefull information in dashboards and set alert triggers.

Example: We can use a DTS object to check a dynamic or static list for blacklisted or unknown users. We use the getter function to check if the current user is part of a blacklist or a whitelist.

Case 1: The user is part of a blacklist: we can raise an alert that a blacklisted user has logged on to a computer with the RaiseAsAlert function.

Case 2: The user is part of a whitelist: we do nothing (from an alerting point of view) just parse useful data if needed.

Case 3: The user is not in either of the lists and we want to add unknown users to a blacklist by default. That can be achieved by using the setter function.

In order for a DTS object to receive an event as a parameter (for an event to be parsed) the following 3 preconditions need to be followed:

1) Create a DTS object

A new DTS object can be created from the setting menu by navigating to Settings > Rules > DTS Objects page. Press the following button and create a new DTS object.

2) Create a Filter rule

The filter rule is a set of conditions that received events have to meet in order to be passed through one or more DTS Objects (parsed).

A new Filter rule can be created from the setting menu by navigating to: Settings > Rules > Filter Rules. Press the following button and create a filter rule.

3) Create a DA rule (data acquisition rule)

The DA rule is a decision making mechanism that sends Events (data) that meet criteria set by Filter rules through DTS objects and to Data Storage service and/or Data Correlation service.

A new DA rule can be created from the setting menu by navigating to: Settings > Rules > DA Rules. Press the following button and create a DA Rule.

For additional information about DTS objects, please follow the link: DTS.

DTS Objects Built-in methods

DTS objects have custom built-in functions created with the purpose of interacting with Redis lists or with the alerting module. The functions are:

1) "setter" function

With this function we can insert values in Redis lists.

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

Example:

setter(‘UserLists’,this.inputEvent.UserName,this.inputEvent.SrcIP,360);

In this example the DTS object looks in "UserLists" for the event’s "UserName" field.

Case1: If it already exists it changes its value ( SrcIP field) and resets the list entry duration to 360 seconds.

Case2: If it does not exist, it creates a new entry with "UserName" key and "SrcIP" value that has a 360 second expiration time.

2) "getter" function

With this function we can get values from Redis lists.

Parameters: [list_name],[list_key]

Example:

getter('IPLists', this.inputEvent.SrcIP);

In this example the DTS object looks in "IPLists" list for the current event’s "SrcIP" field and gets associated value.

3) "RaiseAsAlert" function

With this function we can generate an alert event with the desired settings.

Parameters: [event_list](json format),[alert_name],[email_address(es)],[security_score],[security_level], [alert template]

Example:

RaiseAsAlert(JSON.stringify(EventList),"MultipleLogins(10)","someone@company.com","7","7","Multiple Logins(10)");

In this example the DTS object alerts 'someone@company.com' when the "Multiple Logins (10)" alert is triggered and gives it a security score of 7 and a security level of 7.

4) "backEvents" function

Example:

backEvents(‘SearchString’), NumberOfDays);

Default "NumberOfDays" (if not specified) is 100. Searches for "SearchString" and returns all the events that match the search in JSON format (array).

5) "backCount" function

Example:

backCount(‘SearchString’), NumberOfDays);

Searches for "SearchString" and returns the count of all the events that match the search.

6) "ConsoleLog" function

Example:

ConsoleLog(String);

Logs desired String in: /var/log/data-acquisition.log

Alert scenarios

Alerts examples

Example 1. Create a Logon alert scenario example

This scenario presumes setting up an alert for a specific user who has two failed logons during a 60 seconds time interval.

Step 1:

Go to Settings > Alerts > Realtime

To add the new alert, press Create new alert definition button in the Alerts page.

Step 2:

Create "Default - Audit policy change" alert definition with the following settings:

• Name: Default - Audit policy change

• Alert is active

• Security score of 40

• Security level of 5

Step 3:

Define a new rule with the following settings:

• Description: Audit policy change events

• EventID: 4719

EventID can be searched in Event Dictionary: Event Dictionary

Step 4:

Save the alert definition

The new definition shows in Alerts page

Step 5:

All alerts are generated in real time when conditions defined are met, and are displayed as events in Alerts mode interface. In this example, the alert was generated based on collecting an event with ID 4719 (Audit policy change) from Windows Security Log.

Example 2. Configuring a Logon summary alert scenario example

The alerting scenario will be to notify the security officer if a user failed to authenticate for more than 50 times a day.

Step 1:

Create a report containing the alert definition (a report that shows all filtered events, in this case: "An account failed to log on"). Once executed, the report will find all events matching the report definition. It will also send a notification with relevant information like network address, username, date, time etc.). To achieve this result:

• Open Browser module

• Search for "EventID:4625" which is the Windows event ID for event: "An account failed to log on". Press Filter data to show matching events

• Click Save and select option Save as New Report

• Type in "An account failed to log on" for Name and Description fields

• By default, the new created report will be saved in Custom reports folder in Reports module

Step 2:

Create a new summary alert using the new created report. Open: Settings > Alerts > Summary and click on New Registered Summary Alert option.

Use the following settings:

• The custom report name

• A security score of 50 and a security level of 5

• SummaryOn Level 1: UserName

• SummaryOn Level 2: Computer

Step 3:

Check results.

Example 3. Distributed Denial of Service (DDoS)

Alert description

100 Events to the same IP or Port in 1 Minute from Different Sources. This alert should be trigged at the occurrence of 100 communication events to an IP address and the same port from different IP addresses.

Data sources needed

• In order for the alert to be set, Firewall netflow events must be collected in CYBERQUEST.

Alert setup

From Settings menu, select Alerts > Realtime.

1) In the Rule 1 settings fields, netflow events will be identified. Please fill in the fields with the information as shown below: EventID, isinList, 63805 63809

2) In the Rule 2 settings fields, set:

• Min Threshold to 100

• Max Threshold to 150

• TTL to 60

• SrcIP ≠ Rule No. 1 SrcIP

• AND

• DestIP = Rule No. 1 DestIP

  

To export the alert settings in CQO format file, please follow the link: Alert Object.

Example 4. Application credentials sharing

Alert description

Logon on Windows with a user followed by a Logon on an application with another user (on the same IP). This alert should be trigged at the occurrence of an windows login event followed by an application login event but with a different username from the windows login event.

Data sources needed

In order for the alert to be set, the following sources need to be collected in CYBERQUEST:

• Windows Security Log with Logon audits enabled in GPO;
• Application logon audits should be enabled and to contain information about the user and IP.

Alert setup

From Settings menu, select Alerts > Realtime.

1) In the Rule 1 settings fields, Windows Success Logon 4624 events will be identified. Please fill in the fields with the information as shown below: EventID = 4624

2) In the Rule 2 settings fields, application success login events will be identified.

To do that:

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

To export the alert settings in CQO format file, please follow the link: Alert Object.

Example 5. Malicious IP or domain

Alert description

This alert is triggered when detecting communications between internal IP addresses and blacklist ones. The blacklist contains malicious IPs and domains.

Data sources needed

In order for the alert to be set, the following sources need to be collected in CYBERQUEST:

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

Alert setup

From Settings menu, select Alerts > Realtime.

In the Rule 1 settings fields, fill in the fields with the information as shown below: SrcIP isinList @BlackListDomains AND DestIP isinList @BlackListDomains

To export the alert settings in CQO format file, please follow the link: Alert Object.

Example 6. Successful login after multiple attempts

Alert description

Successful Login after minimum 5 failed attempts on the same user in less than 10 minutes.

Data sources needed

In order for the alert to be set, the following source needs to be collected in CYBERQUEST:

• Windows Security Log with Logon audits enabled in GPO

Alert setup

1) Open CYBERUEST Web Interface.

2) Go to Settings > Alerts > Realtime.

3) Create a new alert, by pressing button.

4) Create the first Rule for identifying the Windows 4625 Failed Logon, by pressing button and select EventID = 4625

5) Add a second rule by pressing button and select “UserName = Rule No. 1 UserName”.

6) Add rule 3 and select “Add correlated condition” (UserName = Rule No. 1 Username) and “Add field condition” (EventID = 4624).

7) After that, to save the Alert you have to press button, from the top-left corner.

To export the alert settings in CQO format file, please follow the link: Alert Object.

Example 7. Traffic to infected domains

Alert Purpose

This alert should be trigged on detecting malicious Domains (BlackListDomains).

Data Sources Needed

• web access events

Description

1) Open CYBERUEST Web Interface.

2) Go to Settings > Alerts > Realtime.

3) Create a new alert, by pressing button.

4) Rule1 - EventID = “event id for web access events“ AND “Accessed domain field” isinList @BlackListDomains

To export the alert settings in CQO format file, please follow the link: Alert Object.

Example 8. VPN Login and RDP with different users

Alert Purpose

This alert should be trigged on detecting a VPN login and RDP connection with a different user then the VPN user.

Data Sources Needed

• VPN Login events
• Windows Security log

Description

1) Open CYBERUEST Web Interface.

2) Go to Settings > Alerts > Realtime.

3) Create a new alert, by pressing button.

4) Rule 1 - EventID isinList 1660049 / 1660009

5) Rule 2 - EventID = 4624 AND S9 = 10 AND UserName NOT = Rule No. 1 UserName AND S15 = Rule No.1 S19

To export the alert settings in CQO format file, please follow the link: Alert Object.

Notification templates customization

From Settings menu, select Alerts > Notification templates. Alerts customization page opens Alert Templates module interface.

The Actions menu includes options for edit and delete Alert Templates. Alert Templates page opens, listing defined Alert Template and here you have a option for creating a New Alert Template.

To create a new alert template, select New Alert Template option in any of the pages detailed above. New Alert Template page opens, possible settings are similar to Edit Alert Template page you can open from Alert Templates list:

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

• In Text field, type a descriptive text or insert an object

Press button to save changes and return to Alert Templates page.

Viewing Alerts

Working with Alerts Module

You access Alerts mode by pressing button you will find in top-left section of Web Interface.

The module operation area is divided in two sections:

• Search and Filter section allows you to granularly control what information is displayed in alerts list

• Results section contains the actionable data listed function of searches and filters.

Alerts Search and Filter section

This section allows you to control what information is displayed in alerts list.

Search field provides the ability to filter displayed information by using free text capabilities. If nothing is entered in field box, all events are displayed.

A complete guide to using free text capabilities is included in this manual.

By pressing button you will be able to instruct the interface on how many items are displayed per page. Default option is 10 items, but you can increase to 50 or 100 items.

When finished, press button to apply your selections.

Other options available in Search and Filter section:

• Send to investigations option will direct your selection to Investigations module. The option opens a new web browser tab to Investigations interface. You are presented with Filter data window that is now populated with filtering information you already entered. Press button to command data extraction based on your filters and display in Investigations interface.

• Send to dashboards option will direct your selection to Dashboards module. The option opens a new web browser tab to Dashboards interface listing filtered results.

• Send to browser option will direct your selection to Browser module. The option opens a new web browser tab to Browser interface listing filtered results.

Search and Filter section includes options for setting the date and time interval for which you need information. This feature is very helpful when you need to have a quick look on compliance over a certain period of time.

The interface allows you to set a specific start date and end date, and also provides you with quick options for date (last hour, last day, last three days, last ten days, last 30 days, last 90 days). By default, Alerts interface lists all alerts. Buttons below Start Date and End Date fields allow you to quickly increase or decrease time interval, and specify time reference to be considered (GMT, LocalTime, ReceivedTime, Now, AutoRefresh).

GMT - is the time reference which converts your search time into GMT(Greenwich Mean Time Zone).

LocalTime - is the time reference when an event occurred.

ReceivedTime - is the time reference when the events arrived in CYBERQUEST machine.

Now - self-update end data with current time.

AutoRefresh - refreshes the page every 10 seconds.

Alerts Results section

This is the main display area for triggered alerts. All alerts are listed in chronological order, the number of items on a page being the one set in Search and Filter options.

Alerts page functionalities are described in detail in Real time alerts customization title.

Clicking the alert name in Alert Name column of the list opens Alert Viewer pop-up window where you can investigate the triggered alert in detail. The following are of interest for an investigation:

• AlertSecurityLevel is the current security level calculated for a triggered alert, starting from a baseline defined in alert definition

• AlertSecurityScore is the current security score calculated for a triggered alert, starting from a baseline defined in alert definition

• In Computers tab are listed all computers currently affected by this alert

• In SrcIPs tab are listed all network addresses currently affected by this alert

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

• When pressing Alert Extra Info, you are presented with the unique ID of the alert, and the correlation index responsible for triggering the alert and calculating security level and score

• When pressing Triggered Rules, you are presented with a short report listing triggered rules from alert definition.

• Pressing button for an entry in list takes you to a full report detailing the associated events for that triggered rule.

View triggered alerts

This is the main display area for triggered alerts. All alerts are listed in chronological order, the number of items on a page being the one set in Search and Filter options.

Clicking on in Alert Name column of the list opens Alert Viewer pop-up window where you can investigate the triggered alert in detail. The following are of interest for an investigation:

• If you press button, you are presented with the unique ID of the alert, and the correlation index responsible for triggering the alert and calculating security level and score.
• When pressing button, you are presented with a short report listing triggered rules from alert definition.
• If you press this buttons , you are presented with the status of the alert.
• You can choose to send alert to Create Investigation case or Add to Existing investigation option.

Manage Alerts

• To delete a triggered alert you have to access Alerts Module by pressing button, you will find in top-left section of Web Interface and window will open:

Clicking on in Alert Name column of the list opens Alert Viewer pop-up window where you can investigate the triggered alert in detail.

To delete a triggered alert you have to press delete buttonand the alert will be deleted.

• To delete a definition of alert you have to go to Settings menu, select Alerts > Realtime. Alerts customization page opens in Alerts module interface:

To delete alerts, press button from Action menu. As a measure of precaution, you will be asked to confirm deletion.

Create Investigation Case

To see how to create an investigation case, please follow the link: Case Management.