Integration of Third Party Native Alerts
Stellar Cyber's built-in alerts are created from data pathways that leverage raw data collected from all forms of data sources, including third party services and Stellar Cyber’s sensors. You can choose to allow Stellar Cyber's Machine Learning (ML) and Statistical Analysis (SA) to generate alerts based on raw data ingested from third party services. For certain services, you can additionally choose to ingest and integrate alerts that are natively created in those services.
This topic summarizes which third party services and products Stellar Cyber supports for native alert integration and how those alerts are mapped in Stellar Cyber.
Third Party Native Alert Mapping
Stellar Cyber handles each service and product in a custom manner, according to the nature of the incoming data, including third party native alerts and other security events. To view alerts and events from multiple sources in our unified, common platform, Stellar Cyber normalizes and enriches the third party native alerts and security events during the data ingestion process. With ingested, normalized, and enriched third party native alerts and security events, Stellar Cyber further applies ML/SA engines, a direct mapping, or a combination of the two, to create Stellar Cyber alerts mapped to the XDR Kill Chain with additional de-duplication to reduce noise and alert fatigue.
Review the following to better understand the native third party alert mapping Stellar Cyber is doing to help you get to the decision points more efficiently:
-
De-duplication: In mapping third-party native alerts and security events to the XDR Kill Chain, Stellar Cyber uses a variety of methods to identify and eliminate potential duplicates for each applicable alert or event type. In particular, Stellar Cyber identifies a combination of fields and values to be key characteristics and uses those to identify duplicates. An example method is to compare the values in that combination for each new third party native alert; if the same value set occurs within a time threshold, that record is considered a duplicate and only the original record is mapped. This process is a critical mechanism to eliminate noise and reduce alert fatigue.
-
Normalization: A key benefit of Stellar Cyber is standardization of all incoming data sources to a common data model (Interflow record), that includes some fields based on the Elastic Common Schema (ECS). Values from the incoming raw data are mapped into standardized fields in Stellar Cyber. In some cases, the original data field is still saved with the Interflow record. This normalization allows Stellar Cyber Analytics and Machine Learning to perform complex analysis and identify related events from disparate ingestion sources. Here are examples of normalization:
-
crowdstrike.event.LocalIP
is mapped to Stellar Cyber'shost.ip
field -
threatInfo.classification
is mapped to Stellar Cyberthreat
field
-
-
Enrichment: Stellar Cyber's data framework requires certain fields to help identify the data source, the category of data, the type of event, to support scoring calculations and certain other activities. In some cases, the ingested data can be directly mapped into these fields. In other cases, Stellar Cyber generates that data. Examples of data enrichment are:
-
(No incoming source field)
msg_origin.source
is created and populated with the vendor name, such ascrowdstrike
-
(No incoming source field)
msg_origin.category
is created and populated with the applicable category for the data type, such asendpoint
-
Incoming data source field
crowdstrike.metadata.eventType
field exists and its value (such ascrowdstrike_detection_summary
) is mapped to Stellar Cyber fieldmsg_class
-
Incoming data source field
event.technique.name
field exists and its value is either mapped directly or algorithmically standardized to populate to Stellar Cyber fieldxdr.event_name
. -
Populating the
xdr_event
structure is a key part of enrichment, with Stellar Cyber ensuring that a Tactic, Technique, and Procedure name, and important scores, are present in every Alert record.
-
Supported Native Third Party Alerts
The table below lists all the services and products for which Stellar Cyber has developed direct integration of third party native alerts, which includes mapping to the Stellar Cyber XDR Kill Chain and adding those alerts to the Alert index. Data not directly mapped is still run through the Stellar Cyber ML/SA pipeline, where applicable. The third party native alerts that are not mapped are ingested and available for creating ATH rules for automatic actions and entry of the result into the Alert index.
Use the table below to identify the data applicable for direct alert mapping, the method of ingestion, and the nature of the mapping.
-
In cases where a value is indicated as Derived, Stellar Cyber assigns a value based on other attributes in the ingested data.
-
Where possible, links to the third party data type format are provided for reference.
For the Key Fields for Third Party Alerts, see Key Fields for Third Party Native Alert Types.
Third Party Service |
Third Party Data Type |
Ingestion |
Mapping of Native Alerts to Stellar Cyber Alerts |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Acronis Cyber Protect Cloud Alerts |
Acronis Cyber Protect Cloud Connector This connector ingests logs from Acronis Cyber Protect Cloud to get the raw alerts that are stored in the Syslog index. |
Stellar Cyber maps Acronis Cyber Protect Cloud alerts. The alerts are read from the Syslog index, enriched with Stellar Cyber fields, and mapped (with de-duplication) to the Alerts index. The following four alert types are supported: Email security, EDR, Antimalware protection, and URL filtering. Tactic and Technique are based on alert type. Alerts from Acronis Email security are not correlated into cases in Case Management. |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AWS GuardDuty Alerts Refer to Amazon GuardDuty. |
This connector ingests logs from AWS GuardDuty to get the raw alerts that are stored in the Syslog index. |
Stellar Cyber maps AWS GuardDuty alerts. The alerts are read from the Syslog index, enriched with Stellar Cyber fields, and mapped (with de-duplication) to the Alerts index. Deduplication is by |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
URL--based User Control / Content Control IP-based Threat-based |
Configure ingestion of Bitdefender's Push event for JSON RPC messages to send data to a Stellar Cyber sensor configured to ingest httpjson (port 5200) over TLS. |
Of the different record types you can configure to push to Stellar Cyber's httpjson parser, the 11 at left are normalized and enriched as they are added to the Syslog index. The records are evaluated against existing records in the Alert index-- those that do not already exist are directly mapped to the Alert index and XDR Kill chain. The other records are run through the ML/SA pipeline, which may generate alerts based on those algorithms. The labels assigned to the alert groups at left refer simply to the nature of the key data points for those alerts. Specifically, these data are supplied with the relevant alert description (Bitdefender field in parenthesis):
See the Bitdefender connector information card for more details on normalization of these and other Bitdefender records. |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CylancePROTECT: CylanceOPTICS: |
Forward log files to port 5177 (specific for handling Cylance logs) The Blackberry Cylance Connector is applicable only for response actions. |
|
CylancePROTECT
CylanceOPTICS
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Detections |
4.3.0-4.3.4:
4.3.5+:
Of the above, only Detections are relevant to alert mapping. |
For Detections, CrowdStrike's DetectionSummaryEvent and PatternDisposition records are used to derive certain fields for populating the alert into the Stellar Cyber alert index. The Tactic and Technique fields in the record are more directly mapped to Stellar Cyber's XDR Kill Chain. |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Malops |
Stellar Cyber can generate alerts based on the Cybereason sensor and MalOp data, however the MalOp records are most applicable for direct mapping. The value in |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Configure ingestion of CEF format logs to a Stellar Cyber sensor. |
The collection of Cynet alerts listed here are read from the Syslog index, enriched and mapped (with de-duplication) to the Alert index and Stellar Cyber Kill Chain. The Cynet alert type is mapped to Stellar Cyber's |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The connector can be used for three data types but only Events are applicable for alert mapping. |
The Events record includes a MITRE | ATT&CK structure with values that support direct mapping to Stellar Cyber's XDR Kill Chain. If the incoming tactic or technique are blank, the following values are assigned in Stellar Cyber: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This connector can ingest Alerts from Google's Alert center and Application (audit) reports. The Gmail Phishing, Google Identity, and User Changes events from the Alert reports (and are specifically relevant to this mapping). |
The Gmail Phishing, Google Identity, and User Changes alerts are mapped. All other data from Alerts and Applications (audit reports) are processed through Stellar Cyber's ML/SA workflow. |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LimaCharlie Alerts The following types of events for alerts collected by LimaCharlie's EDR sensors are supported:
Refer to Events. |
This connector ingests logs from LimaCharlie to get the raw alerts that are stored in the Syslog index. |
Stellar Cyber maps LimaCharlie alerts. The alerts are read from the Syslog index, enriched with Stellar Cyber fields, and mapped (with de-duplication) to the Alerts index. Deduplication is by Tactic and Technique are provided by the LimaCharlie raw alerts field |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Syslog |
Microsoft Defender for Endpoint Connectors This connector ingests logs from Microsoft Defender for Endpoint (connector). Select the Alerts content type. There may be two data sources for third party native alerts if you have integrated both Microsoft Defender for Endpoint (connector) and Windows Defender Antivirus (free version). The integration of Microsoft Defender for Endpoint (connector) may stop the alert mapping for Windows Defender Antivirus (free version). |
Stellar Cyber maps Microsoft Defender ATP alerts. |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Microsoft Entra ID (formerly Azure AD) Connector This connector can ingest several log types. Only Risk Detection logs are relevant to alert mapping. |
The value in the fields for the data type noted at left are mapped to Stellar Cyber's XDR Alert index. These alerts are suitable for MITRE | ATT&CK classification, but do not contain tactic and technique values. Stellar Cyber has evaluated each possible alert and assigned a corresponding MITRE | ATT&CK Stage, Tactic and Technique. |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Windows Events |
This connector ingests logs from Microsoft Office 365. Select the Audit General content type. Only the AlertTriggered operation is relevant to alert mapping. |
Stellar Cyber maps Microsoft Office 365 alerts from the AlertTriggered operation. For the Audit General content type, Office 365 alerts contain events from the AlertTriggered operation, which are sent to the Alerts index. The source records may also include related events in the AlertEntityGenerated operation. Some information (AlertEntityId and EntityType) from the AlertEntityGenerated operation is merged with the AlertTriggered operation for the same Alert ID. The information (AlertEntityId and EntityType) is stored in the Deduplication is by |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Mimecast alerts There are the following types of alerts:
Refer to "Log Field Descriptions" in Understanding SIEM Logs: Targeted Threat Protection - Attachment Protect logs, AV logs, Targeted Threat Protection - Impersonation Protect logs, Target Threat Protection - Internal Email Protect logs, Receipt logs, Targeted Threat Protection - URL Protect logs |
This connector ingests logs from Mimecast to get the raw alerts that are stored in the Syslog index. |
Stellar Cyber maps Mimecast alerts. The alerts are read from the Syslog index, enriched with Stellar Cyber fields, and mapped (with de-duplication) to the Alerts index. Deduplication is by the listed fields for the following event logs:
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
OCI CloudGuard Alerts Refer to OCI CloudGuard. |
Oracle Cloud Infrastructure (OCI) Connector This connector ingests logs from OCI to get the raw alerts that are stored in the Syslog index. |
Stellar Cyber maps OCI CloudGuard alerts. The alerts are read from the Syslog index, enriched with Stellar Cyber fields, and mapped (with de-duplication) to the Alerts index. Deduplication is by Alerts from OCI CloudGuard are not correlated into cases in Case Management. |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Proofpoint TAP Alerts There are the following categories of alerts:
|
This connector ingests logs from Proofpoint TAP to get the raw alerts that are stored in the Syslog index. |
Stellar Cyber maps Proofpoint TAP alerts. The alerts are read from the Syslog index, enriched with Stellar Cyber fields, and mapped (with de-duplication) to the Alerts index. Deduplication is by There are the following event types:
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Threats |
This connector can ingest Hosts, Threats, and Vulnerabilities. Of these, only Threats are relevant for alert mapping. |
The threat dataset includes a variety of fields that enable Stellar Cyber to map the native SentinelOne alerts to the Stellar Cyber alert index. For example, For SentinelOne, the |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Alerts |
Trellix (FireEye) Endpoint Security HX The connector can be used for three data types but only Alerts are applicable for alert mapping. |
Stellar Cyber identifies the FireEye data logged into the Syslog index. Records of the type Alerts are then normalized, enriched, and mapped to the Alerts index. The following fields are included as part of the Stellar Cyber
alert description: The following four alert types are supported: IOC, MAL, AMSI, and PROCGUARD. Tactic and Technique are based on alert type. |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Trend Micro Vision One Alerts |
Trend Micro Vision One Connector This connector ingests logs from Trend Micro Vision One to get the raw alerts that are stored in the Syslog index. |
Stellar Cyber maps Trend Micro Vision One alerts. The alerts are read from the Syslog index, enriched with Stellar Cyber fields, and mapped (with de-duplication) to the Alerts index. Deduplication is by Tactic and Technique are provided by the Trend Micro Vision One raw alerts field |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Varonis Alerts
|
Configure ingestion of CEF format logs to a Stellar Cyber sensor. |
Varonis sends Syslog CEF events to Stellar Cyber, which maps Varonis DatAdvantage alerts to the Alerts index. |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
VMware Carbon Black Cloud |
Alerts of type CB Analytics, Device Control, and Watchlist |
VMware Carbon Black alerts are assigned a MITRE technique / tactic / procedure (TTP) which is reformatted but otherwise preserved during mapping, except as noted below. CB Analytics and Device Control:
Watchlist: This type of alert is considered noisy (generates a large volume of hits), so it is routed through the ML/SA pipeline using our Time Series Analytic and Rare models, along with de-duplication, before being mapped to the Alerts index. This type of alert is classified as Tactic: XDR EBA with Technique: XDR Anomaly. |
ORIGINAL FIELDS: In addition to the mapping of fields to Stellar Cyber Interflow fields, all of the original fields for this alert type are included in the Interflow record. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(free version only) |
Windows Agent Detection Logs ingested from a Windows Agent |
These events are ingested to the Stellar Cyber Windows Event index. As of the v4.3.2 release, they are also now processed into the Alerts index. In these logs, multiple events correlate to a single incident, such as event_id 1116 (malware detected), one with event_id 1117 (means malware is quarantined). Stellar Cyber manages this, tracking the events to the related incident during the mapping process. |
|