Darktrace Plugin for Log Shipper - Netskope Technical Documentation

This document explains how to configure the Darktrace v1.0.0 plugin with the Log Shipper module of the Netskope Cloud Exchange platform. This plugin supports ingestion of Alerts (Anomaly, DLP, Malware, Policy, Compromised Credential, Legal Hold, Malsite, Quarantine, Remediation, Security Assessment, Watchlist, UBA, CTEP, Device, Content), Events (Page, Application, Audit, Infrastructure, Network, Incident, Endpoint, Client Status), BWAN Events (Authentication, Audit, Client, Gateway, System), WebTx [via Netskope LogStreaming] and Logs (Debug, Information, Error, Warning). The data will be ingested in the SIEM platform. This plugin supports ingestion in CEF and JSON format.

Prerequisites

To complete this configuration, you need:

A Netskope tenant (or multiple, for example, production and development/test instances).
A Netskope Cloud Exchange tenant with the Tenant plugin and Log Shipper plugin already configured.
A Netskope Cloud Exchange tenant with the BWAN plugin already configured.
A Netskope Cloud Exchange tenant with the AWS Netskope Log Streaming or Azure Netskope Log Streaming plugin already configured (for ingesting WebTx from the Netskope Log Streaming plugins).
A Darktrace Server.

Note

Endpoint event type requires minimum Cloud Exchange version to be 5.1.0. BWAN events, Events of type Client Status and Alerts of type Device and Content requires minimum Cloud Exchange version to be 5.1.1.

Darktrace Plugin Support

The Darktrace plugin is used to ingest all the Alert, Events, WebTx[via Netskope LogStreming], and CE Logs in CEF and JSON format to the specified Darktrace server.

Data Type	Support
Events	Yes (Page, Application, Audit, Infrastructure, Network, Incident, Endpoint, Client Status)
Alerts	Yes ( DLP, Malware, Policy, Compromised Credential, Malsite, Quarantine, Remediation, Security Assessment, Watchlist, UBA, CTEP, Device, Content)
Syslog CE Logs	Yes (Info, Error, Warning, Debug)
BWAN Events	Yes (Authentication, Audit, Client, Gateway, System)
WebTx	Yes (via Netskope LogStreaming)

Note

CLS WebTX based on Google Pub Sub Lite is deprecated. Please refer to Netskope Product EOL/EOS Announcements – Netskope Knowledge Portal
For ingesting WebTX logs to your Log delivery destinations like SIEM, SOAR, XDR, Data Lake, use the AWS Netskope Log Streaming or Azure Netskope Log Streaming plugin.

API Details

The plugin uses a ‘logging’ third-party library to push the data to the Syslog collector.

Library: logging

This module defines functions and classes which implement a flexible event-logging system for applications and libraries.

The key benefit of having the logging API provided by a standard library module is that all Python modules can participate in logging, so your application log can include your own messages integrated with messages from third-party modules.

Refer to the official documentation for more information on the logging library.

https://docs.python.org/3/library/logging.html

List of Methods Used

Method: logging.getLogger(name=None)

Return a logger with the specified name or, if the name is None, return a logger which is the root logger of the hierarchy.

All calls to this function with a given name return the same logger instance. This means that logger instances never need to be passed between different parts of an application.

Method: setLevel(level)

Sets the threshold for this logger to level. Logging messages that are less severe than the level will be ignored; logging messages that have a severity level or higher will be emitted by whichever handler or handlers service this logger, unless a handler’s level has been set to a higher severity level than the level.

Method: handlers

The list of handlers is directly attached to this logger instance.

Note:

This attribute should be treated as operation.

read-only; it is normally changed via the addHandler() and removeHandler() methods, which use locks to ensure thread-safe

Method: addHandler(hdlr): Adds the specified handler hdlr to this logger.

Method: removeHandler(hdlr): Removes the specified handler hdlr from this logger.

Workflow

Configure the Darktrace Plugin
Configure a Log Shipper Business Rule for the Darktrace Plugin.
Configure Log Shipper Log Delivery for the Darktrace Plugin.
Validate the Darktrace Plugin.

Configure the Darktrace Plugin

In Cloud Exchange, go to Settings > Plugin Store. Search for and select the Darktrace v1.0.0 (CLS) plugin.
Add a plugin configuration name and make sure you have the Darktrace Default Mapping file selected (if you want to use the CEF mapping).

Note

Disable the toggle button to transform the logs if you want to ingest the data in JSON; keep it enabled if you want to ingest the data in CEF format.
Click Next and enter the Configuration Parameters:
- Darktrace server: IP address/FQDN of Darktrace server in which data will be ingested.
- Darktrace Protocol: Protocol to be used while ingesting data.
- Darktrace Port: Darktrace port.
- Darktrace Certificate: Certificate is required only for TLS protocol.
- Log Source Identifier: This will be added as a prefix to all the logs.

Click Save. Your plugin configuration will be available at Log Shipper > Plugins.

Configure a Log Shipper Business Rule for the Darktrace Plugin

Go to Business Rules.
By default, there is a business rule that filters all alerts and events. If you want to filter out any specific type of alert or event, click Create New Rule and configure a new business rule by adding the rule name and filter.

Configure Log Shipper Log Delivery for the Darktrace Plugin

In Log Shipper, go to Log Delivery and click Add Log Delivery Configuration.
Select the Source plugin (CLS Netskope), Destination plugin (CLS Darktrace), and a business rule.
For WebTx, select Source plugin (AWS Netskope Log Streaming or Azure Netskope Log Streaming) and Destination plugin (CLS Darktrace).
For Logs sharing, select the Source plugin (CLS Cloud Exchange Logs), and Destination plugin (CLS Darktrace).
Click Save.
After the Log Delivery configuration is added, the data will start to be pulled from the Netskope tenant, transformed, and ingested into the Darktrace platform.

Validate the Darktrace Plugin

Validate the Pull

To validate the pulling of Events, Alerts, logs, and WebTx (via Netskope LogStreaming) from the Netskope tenant, go to the Logging in Cloud Exchange and search for the pulled logs.

Validate the Push

To validatethe plugin workflow in Cloud Exchange, go to Logging and search for ingested Events, Alerts, WebTx and CE Logs with the filter message contains ingested. The ingested logs will be filtered.

Troubleshooting the Darktrace Plugin

An error occurred while configuring the Darktrace Plugin

If despite entering all parameters and clicking Save an error occurs, it may be due to one of these reasons:

The server/port configuration may differ from the specified settings (Netskope CE/Darktrace).
The port is not exposed on the Darktrace server.

What to do:

Expose the Port on the Darktrace server.

Error occurred while ingesting data from CE to Darktrace

If you are unable to push alerts/events/logs/webtx data on the Darktrace platform, then it could be due to one of these reasons:

The port is deleted/disabled on the Darktrace platform.
Darktrace server storage is full.

What to do:

Make sure the port is present and enabled, if not then create a new port.
Make sure to clean the event data if not necessary, or increase the storage of the Darktrace server.

If ingested data is not reflected on the Darktrace Platform

If you are unable to view alerts/events/logs/webtx data on the Darktrace platform, then it could be due to one of these reasons:

The filter is not correct on the Darktrace platform.
There might be an error but UDP was selected in the Port while configuring the Darktrace plugin.

What to do:

Make sure Data is searched using the correct filter.
Make sure to select the TCP port to check if there is any issue.

Network Event skipped due to unexpected type for Network Session ID field

If you are not able to get value for the Network session ID field, then it could be due to using an old Darktrace plugin where the network session id field is of number type.

What to do:

Update network session id field to string type to handle non-numeric data.

To update mappings, go to Settings > Log Shipper > Clone Darktrace Default Mappings and add name for cloned mapping. Click Events > Network > Extension and select the String Type for networkSessionId. Click Save.
Use the updated mapping file in plugin configuration.