KHIKA Alerts & Correlations
Contents
Introduction
Correlations and Alerting is one of the core functionalities of KHIKA. As KHIKA Core receives streams of data from KHIKA Data Aggregator/s, the incoming data has to be processed in “real time” and meaningful alerts have to be triggered when predefined conditions are met. The predefined conditions are called as “Alert/Correlation Rules” and the component of KHIKA responsible for processing these Correlation Rules is called “Alerting and Correlation Engine”
Consider “Alerting and Correlation Engine” as an inverted database that has queries (aka Alert/Correlation Rules) already defined and stored in it. As the data streams pass through the “Alerting and Correlation Engine”, the streams of data get validated against the predefined queries. As soon as the predefined conditions are met, the alerts are generated.
KHIKA’s state of art of alerting and correlation engine is built with complex event processing (CEP) at its core and hence it is capable of handling complex alerting requirements such as
- Several login failures followed by a successful logon for same user from same machine within 10 minutes (Successful brute force attack)
- Several packets dropped on firewall from same source IP address with more than 50 unique combinations of destination hosts and ports within 5 minutes
- User created and deleted within 24 hours
- User created but initial password not changed within 24 hours
- Communication with suspicious IP on firewall from a host followed by a virus alert from antivirus engine on the same host etc.
Note that these are complex alerting requirements as it involves correlating several events together to be able to generate a meaningful alert. For instance, to identify a successful brute force attack on windows, you must correlate several logon failure events (eventid = 4625) with a logon success event (eventid=4625) for the user in question within certain time period. Eventid 4625 may have different field to identify the same user from eventid 4624. Clearly, one must be able to do cross-event correlations on any field that may exist in the events.
Alert Dashboard
Click on “Alert Dashboard” on left menu pane. Certain alerts are pre-canned and shipped with KHIKA, keeping in mind the requirements of the users. Alerts that the system generates, can be seen in the “Alert Dashboard” as well as can be sent in email to relevant stakeholders. (Application / no Application ? ) Alert Dashboard displays all the alerts generated by all the devices which are connected to the system. Visual representation in the form of Pie Charts, Bar Graphs, and Line Graphs are used for identifying the priorities, trends, problem IPs etc. easily. You can prioritize alerts based on severity and impact and focus on the critical incidents. Additionally, there are five filters provided on top as drop down menus to navigate and / or focus on a certain alert type or only “Critical” severity alerts say.
alert1
You can view a graphical representation of the alerts in the top half of the screen while the table below shows details of the event that pinpoint the exact IP addresses, URLs, Username involved. This is aimed to help the admin investigate and sort out the event.
Viewing & Filtering Alerts
You can view details of a particular alert by using following filters:
- Severity
- Alert
- Username
- Device
- Date range
You can apply filters to any of these parameters and generate a graphical representation to see the trend. The filter also affects the tabular representation below the graphs. The table shows only those alerts for which you have applied the filter. To apply filters to each of the parameters and generate a chart follow these steps:
Select the appropriate details like Severity, Alert, Username, Device and Date Range.
alert2
Click on Submit Selection button on the top right.
alert3
The selected filters are applied, and the chart is displayed.
alert4
Various fields in Alert Dashboard table are listed below:
Field | Description |
---|---|
Time | Exact timestamp when alert is triggered in the system. |
Id | Unique identifier of the alert.(This is for internal reference) |
Alert Type | What the alert is about. |
User | Username associated, if any. (default is NA) |
IPAddress | IPAddress that raised the alert. |
Device | Machine name (device) that raised the alert. |
Workspace | Relevant Workspace name which has the devices, events associated. |
Source | Data source of the alert (like APV, VPN, Firewall etc.) |
Severity | Severity of the alert. |
Details | Description of the alert, not mentioned in other fields. |
You can search a particular alert by entering any of the field details in the search option. The search option returns all the details of the particular alert.
alert5
You can manage an incident by assigning it to another group to verify and handle the condition. Also you can change the status of the incident according to your workflow.
Click on Manage Incident button.
alert6
Select the status and user group for incident. You can assign an incident to a user group.
alert7
Write a comment if any. Click on Save button
alert8
You can check the current status of the incident in the Alert Dashboard.
alert9
The best way to understand how Alerting works is learning by examples. In the section below, we will begin with some very simple examples and slowly show how to create complex alerts/correlations in KHIKA.