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's host.ip field

    • threatInfo.classification is mapped to Stellar Cyber threat 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 as crowdstrike

    • (No incoming source field) msg_origin.category is created and populated with the applicable category for the data type, such as endpoint

    • Incoming data source field crowdstrike.metadata.eventType field exists and its value (such as crowdstrike_detection_summary) is mapped to Stellar Cyber field msg_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 field xdr.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
Method

Mapping of Native Alerts to Stellar Cyber Alerts

Notable Interflow Fields

Acronis Cyber Protect Cloud

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

AWS GuardDuty Alerts

Refer to Amazon GuardDuty.

AWS GuardDuty Connector

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 aws_guardduty_id.

Azure AD

riskDetections>riskEvents

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.

Bitdefender

URL--based

Antiphishing

Data Protection

User Control / Content Control

IP-based

Firewall

Ransomware activity detection

Threat-based

Advanced Threat Control (ATC)

Antiexploit Event

Antimalware

Hyper Detect event

Sandbox Analyzer Detection

Storage Antimalware

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

  • URL-based alerts: event.type (module acronym), host.name (computer_fqdn), host.ip (computer_ip), url

  • IP-based alerts: event.type (module acronym), host.name (computer_fqdn), host.ip (computer_ip), srcip (attack source or source-ip)

  • Threat-based alerts: event.type (module acronym), host.name (computer_fqdn), host.ip (computer_ip), threatName, where threatName varies depending on the record type (malware_name, threatType, detection_threatName, attack_types, aph_type, exploit_type, or target_type)

See the Bitdefender connector information card for more details on normalization of these and other Bitdefender records.

Blackberry CylancePROTECT and CylanceOPTICS

CylancePROTECT:

Exploit Attempts

Script Control

Threats

CylanceOPTICS:

Detections

Forward log files to port 5177 (specific for handling Cylance logs)

The Blackberry Cylance Connector is applicable only for response actions.

  • For CylancePROTECT, three types of Cylance events are mapped to the XDR Kill Chain and Stellar Cyber's Alert index: Exploit Attempts, Script Control, and Threats. The other data (Audit Log, Device, Device Control, and Threat Classification) are ingested and mapped to the Syslog index (not Alerts index), and are not run through the ML/SA pipeline.

  • For CylanceOPTICS, Detection events are evaluated with Stellar Cyber time series analysis models to determine abnormality of the event before mapping.

CylancePROTECT

CylanceOPTICS

CrowdStrike Falcon

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.

Cybereason

Malops

Cybereason Connector

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 malopDetectionType is reformatted and used for the alert name. Stellar Cyber has evaluated each possible alert and assigned a corresponding MITRE | ATT&CK Stage, Tactic and Technique.

Cynet

ADT Alerts

NextGen Antivirus Alerts

Threat Intelligence Alerts

Memory Protection Alerts

Network Activity Alerts

AMSI Alerts

Feature Alerts

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 event.threat.name, which is shown in the key fields.

Deep Instinct

Events

Deep Instinct Connector

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:
tactic_name = XDR Malware
technique_name = XDR Miscellaneous Malware

Google Workspace Alert

Alerts

 

Google Workspace Connector

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.

Microsoft Defender for Endpoint

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.

The lastUpdateTime timestamp is used with the API to pull alerts/events. The alertCreationTime timestamp is not used. This may result in the old event being pulled again when an update happens on the event.

Microsoft Office 365

Windows Events

Office 365 Connectors

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 event_summary field.

Deduplication is by AlertId.

  • msg_origin.source Interflow field to which Stellar Cyber assigns a vendor identifying value, which can be used for filtering.:office365
  • msg_class Interflow field to which Stellar Cyber assigns a value, which can be used for filtering.office365_audit_general

  • Alert Subtype: event.threat.name or office365.Name

  • Event (Alert) Name Interflow field: xdr_event.display_name: Microsoft 365: with the assigned Technique Technique includes both those based on the MITRE | ATT&CK framework, as well as native XDR versions developed by Stellar Cyber, which will be used only when there is no available Mitre technique. and the assigned (Tactic), for example Microsoft 365: Valid Accounts (Privilege Escalation)

  • Fidelity Interflow field: fidelity: Is Severity by default

  • Severity Interflow field: severity or event.severity: Derived from Office 365 alert policy Severity event.severity_str:

    • High: 75

    • Medium: 55

    • Low: 35

    • Informational: 15

  • Kill Chain & MITRE | ATT&CK values are mapped to the Office 365 alert policies and the category to which each policy is assigned. You can also refer to the Microsoft documentation.

Oracle Cloud Infrastructure (OCI) CloudGuard

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 tenantid, oracle.data.additionalDetails.tenantId, event.threat.name, and cloud.resource.id.

Alerts from OCI CloudGuard are not correlated into cases in Case Management.

Proofpoint Targeted Attack Protection (TAP)

Proofpoint TAP Alerts

There are the following categories of alerts:

  • Phish: Phishing is when attackers send malicious emails designed to trick people into falling for a scam. Typically, the intent is to get users to reveal financial information, system credentials or other sensitive data.

  • Imposter: A scammer sets up an email address that looks like it is from your company. Then the scammer sends out messages using that email address. This practice is called spoofing, and the scammer is what we call a business email imposter.

  • Malware: Malware is a common cyber attack and an umbrella term for various malicious programs delivered and installed on end-user systems and servers. These attacks are designed to cause harm to a computer, server, or computer network, and are used by cyber criminals to obtain data for financial gain

  • Toad (Telephone-Oriented Attack Delivery): Toad is a type of social engineering attack that lures potential victims to contact fraudulent call centers managed by threat actors in attempts to steal credentials or install malware onto their systems.

  • Spam: Email spam, also known as junk email, refers to unsolicited email messages, usually sent in bulk to a large list of recipients.

Proofpoint TAP Connector

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 email.sender.address.

There are the following event types:

  • Proofpoint TAP messageBlocked

  • Proofpoint TAP messageDelivered

  • Proofpoint TAP clickBlocked

  • Proofpoint TAP clickDelivered

SentinelOne Cloud

Threats

SentinelONE Connector 

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, threatInfo.classification describes the event (such as Trojan). That and other fields in the threatInfo record support direct mapping of SentinelOne's MITRE | ATT&CK Tactic and Technique fields to Stellar Cyber's XDR Kill Chain.

For SentinelOne, the UpdatedAt timestamp is used with the API to pull alerts/events. The CreatedAt timestamp is not used. This may result in the old event being pulled again when an update happens on the event.

Trellix (FireEye) Endpoint Security

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: indicator.name and agent.url. Each relevant Syslog record is compared against existing records in the Alert index and not added to that index if the values in the following fields match those of an existing record logged in the previous 24 hours: org_id, tenantid, user.name, host.ip, event.name, file.path, process.path.

The following four alert types are supported: IOC, MAL, AMSI, and PROCGUARD. Tactic and Technique are based on alert type.

Varonis DatAdvantage

Varonis Alerts

  • File system operation

  • Directory services operation

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 Cloud Connector

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:

  • Alerts with a threat_cause_threat_category of NON_MALWARE, NEW_MALWARE, and KNOWN_MALWARE are directly mapped to the Alerts index. The kill_chain_status values (RECONNAISSANCE, WEAPONIZE, DELIVER_EXPLOIT, INSTALL_RUN, COMMAND_AND_CONTROL, EXECUTE_GOAL, BREACH) are preserved and mapped to the Stellar Cyber XDR Kill Chain.

  • Alerts with a threat category value of RISKY_PROGRAM are assigned a Tactic of XDR Malware and Techinque of XDR PUA.

  • Alerts with threat category value of UNKNOWN are run through Stellar Cyber's ML/SA pipeline, to better ascertain the nature of the alert before mapping it to the Alert index. This type is assigned an Tactic of XDR EBA and Technique of XDR Anomaly

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.

Windows Defender Antivirus

(free version only)

Events

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.