Darktrace System Administration Guide

Darktrace System Administration Guide
Threat Visualizer v5.1

DARKTRACE SYSTEM ADMINISTRATION GUIDE 2
Contents
Device Tracking
Type of Device Tracking�� 5
Tracking by Hostname��7
Tracking by Credentials��10
Device Tracking and DHCP�� 11
Telemetry
Ingesting Syslog for Enrichment��12
Configuring a Syslog Input��14
Log Ingestion Patterns��16
Advanced Log Ingestion Syntax��18
AI Analyst Triggered Investigations�� 20
Replacing the Certificate for Encrypted Syslog Ingestion��21
Data Enrichment
Labelling Key Devices and Subnets�� 22
Configuring HTTPS Certification��24
Configuring an LDAP Server�� 25
Using LDAP data for Enrichment��27
Access and User Permissions

Accessing the Threat Visualizer using LDAP�� 29
Accessing the Threat Visualizer using SAML 2.0��31
Example User Permissions��34
Guide to User Privileges��35
Anonymization Mode��37
Example Alert Outputs

Configuring An Email Server for Alerts��38
Sending Email Alerts for Model Breach Alerts��39
Sending Email Alerts for AI Analyst Events�� 40
Sending Email Alerts for System Status Alerts��42
Email Alert Filters and Optional Settings��43
Example Email Alerts��45
Configuring the Mobile App��47
Model Administration
Upgrading Darktrace Models��48
Console Administration
Appliance Console Guide�� 50
Advanced Search Export Formats�� 55
Configuring Advanced Search Export for Elasticsearch��57
Configuring Advanced Search Export for TCP�� 59
Host Variables in the Appliance Console��61
Software Backups
Creating an Immediate Backup��63
Configuring a Scheduled Backup via SCP��64
Configuring a Scheduled Backup via SMB�� 66
Configuring a Scheduled Backup via S3�� 69
Setting Up Email Alerts for Scheduled Backup Status��74
Restore from a Backup��76
Upgrades and Data Removal

Types of Darktrace Upgrade Bundles�� 77
Downloading Update Bundles��78
Performing a Guided Upgrade��79
Performing a Manual Upgrade�� 80
Securely Erasing Captured Data�� 82
Restoring the Darktrace Appliance to Factory Settings��84
Type of Device Tracking

Understanding Device Tracking
Darktrace can model the ‘pattern of life’ for entities in a subnet in one of four distinct ways - by MAC address, by IP address,
by hostname or by credential. When selecting an appropriate mode of tracking, the most consistent aspect about the device
or user should be considered - what identifier should a long term behavioral profile be developed for?
In a simple subnet with static IP addresses, where a device has a single network connection and one user, tracking by IP
address makes sense. The IP address will remain consistent and the behavior of the device should remain consistent due
to a single operator.
The most common scenario is a subnet configured with dynamic IP assignment (DHCP), where devices join the network
and are assigned an IP from a pool of available internal IPs. Modeling by IP does not make sense in this context as that IP
could be assigned to many different devices over the course of a day, a week or a month. Instead, the devices should be
modeled by the MAC address assigned to their network card (DHCP), or by their hostname (Track by Hostname). DHCP
logs can be ingested in syslog format if assignment is not seen directly at a traffic level. Similarly, IP-hostname pairs can be
provided for mapping. The most appropriate choice depends on the information already present in the traffic - for example,
is Darktrace seeing the MAC in DHCP assignment - and the ease of getting additional information into the Threat Visualizer
if another method is desired.
Tracking by hostname can be desirable where a device has more than one network connection: for example, a laptop
connected by a wired and a wifi connection to the internal network. When tracking by MAC or by IP, two separate ‘patterns
of life’ would be modeled for the same device. In this scenario, setting the subnet(s) to track by hostname would model a
single entity combining the traffic seen from both interfaces.
Where multiple users utilize an IP or device outside of a DHCP scenario, there are a few approaches available. A ‘hot desking’
office may contain a subnet of docking stations, where a device utilizes the dock IP whilst connected and an office wifi when
undocked. Tracking by IP or MAC would create a single model for the dock regardless of the device connected. Instead,
setting both the dock subnet and the office wifi to track by hostname would ensure activity is assigned to the laptop - not
the dock - and model a single ‘pattern of life’ for that laptop as it moves between a docked and undocked state.
Finally, consider a subnet containing a pool of internal IP addresses assigned to VPN users - an IP address may be assigned
to multiple users across the span of one day. Similarly, a device used by multiple shift workers with individual credentials
will maintain the same IP address assignment and MAC address. In these cases, it makes sense to model the ‘pattern of
life’ of a credential - a user - to understand their workflow and detect when they begin to behave anomalously. Tracking
by credential is the best option for these example subnets, where the credential information is provided in the traffic or by
sending VPN/Credential logs for enrichment.
Possible Device Tracking States
Using the configuration options available in Subnet Admin, the following tracking states can be achieved:
DEVICE MODELED SUBNET ADMIN

RESULT
BY SETTINGS
DHCP: True, Devices tracked by MAC Address seen in DHCP traffic. If DHCP is not
MAC Hostname: False, available for the entire subnet, tracking will fall back to track based on
Credential: False hostname using Kerberos/DNS data.
DHCP: True,
Devices tracked by hostnames seen in DHCP data. If DHCP is not available
Hostname Hostname: True,
for the entire subnet, tracking will fall back to Kerberos/DNS data.
Credential: False
DHCP: False,
Hostname Hostname: True, Devices tracked by hostnames seen in Kerberos/DNS data.
Credential: False
DHCP: False,
Credential Devices tracked by credentials/usernames using data from authentication
Hostname: False,
(username) protocols observed or ingested VPN logs.
Credential: True
DHCP: False,
IP Address Hostname: False, Devices are modeled as static IPs using data seen to/from their IP.
Credential: False
When an IP or a hostname is assigned to a device, a “Hostname Change” or “IP Change” message will be placed in its event
log. Hovering over this message will provide the source of the change, such as Kerberos or DHCP traffic. If an unexpected
change is made, reviewing the source can help narrow down unreliable sources of tracking information so that the problem
can be addressed.
Tracking by Hostname
Darktrace will passively observe hostnames for devices as they make network requests such as DNS requests for IP addresses,
Kerberos logins, and DHCP assignments. This observation is used to provide enrichment data, allowing for easy identification
of devices beyond an IP or MAC address.
If tracking by hostname has been selected as the most suitable way to model devices in the subnet, additional configuration
should be undertaken to ensure that Darktrace can accurately and consistently retrieve hostname data. This is particularly
important for subnets where no DHCP data is available.
The following methods will be covered:
Ǔ Hostname assignment from passive observation of Kerberos data (enabled by default).

Ǔ Active ‘DIG’ commands polling a DNS server for hostnames.
Ǔ Ingestion and parsing of hostname logs in syslog format.
Ǔ Hostname assignment from passive observation of DNS (not recommended).
Observing Hostnames in Kerberos Traffic
If Darktrace observes suitable Kerberos traffic, it can locate IP/hostname pairings and reassign IP addresses to hostnames
accordingly. This is enabled by default but should be checked before moving to hostname tracking.
Please note, if DHCP data is available it will be considered authoritative unless explicitly disabled.
1. Within the Threat Visualizer, navigate to the System Config

page in the main menu under Admin. Select Settings from
the left-hand menu.
2. Locate Tracking from the available sections. Within the Network

Device Tracking subsection, confirm Reassign Device IPs
from Kerberos is enabled.
If not, enable the setting and save the changes.
Polling DNS Servers to Append Hostnames
Darktrace can actively retrieve hostname and IP assignment data from a local DNS server. This method uses DIG commands
to poll servers for an IP address’s hostname when the IP address becomes active on the network. The hostname resolution
will be cached for a time set during configuration.

page in the main menu under Admin.
2. Locate Data Population, then Active DNS Hostname Resolution.

The field “Active DNS Hostname Resolution Cache Time”
controls how long IP/hostnames pairs found via DNS resolution
are cached for. Entering a value greater than 0 into the field
will provide access to the required fields to configure active
hostname resolution.
To continue, add a value into this field. A typical value is 7200

, equivalent to 2 hours. The minimum value is 600, equivalent
to 10 minutes.
New options will now appear.

3. When performing active DNS resolution, the Active DNS

Resolution Throttle value limits the maximum frequency of
requests made per second. The default value is 10. Alter this
value if desired, or proceed onward.
4. The Active DNS Resolution Servers field controls the servers

polled for DNS resolution. A maximum of 5 servers can be
entered comma-separated, where the entry order defines the
order they will be queried in.
If this field is left empty, polling will be completed using the

DNS servers configured via the console.
Save the changes.
Hostname Tracking with Syslog Ingestion
Syslog-format logs can be sent to Darktrace for parsing and can be used to provide IP assignment data for a hostname -
logs can be ingested by both Masters and Probes. Matching patterns are configured on the System Configuration page.
For hostname tracking, the template must be of the type “Device Tracking Logs” and contain a hostname and a source IP.
For more information on configuring log ingestion, please see Ingesting Syslog for Enrichment.
Observing Hostnames in DNS Traffic
IPs can be reassigned (client-only) based upon on hostnames passively observed in DNS traffic. By default, this setting is
disabled and should only be enabled where other methods are not available.
Please note, if DHCP data is available it will be considered authoritative unless explicitly disabled.

page in the main menu under Admin. Select Settings from
the left-hand menu.
2. Locate Tracking from the available sections. Within the Network

Device Tracking subsection, enable the setting Reassign
Device IPs from DNS and save the changes.
Configuring a Subnet to Track by Hostname
1. In the main Threat Visualizer, navigate to the Subnet

Admin page in the main menu under Admin and locate the
corresponding entry.
2. Review the DCHP setting in the Tracking column.
The DHCP subnet setting controls if Darktrace should track

devices by DHCP. When tracking by hostname, enabling DHCP
will look at hostnames in DHCP traffic as the most authoritative
source, falling back on Kerberos or DNS if unavailable. If
disabled, Darktrace will use Kerberos and DNS as the primary
source for hostname information.
3. Review the Hostnames setting. Enabling this setting will begin

tracking the subnet by hostname.
Tracking by Credentials
In some subnet configurations, it may be desirable to model a ‘pattern of life’ for a credential rather than a device. This is
particularly advantageous for subnets where an IP is utilized by many, such as a pool of VPN IPs.
Credentials are automatically detected in authentication traffic such as Kerberos and Radius, or can be supplied by the
ingestion of credential logs in syslog format. As a credential is assigned an IP address through authentication, Darktrace
maps the IP address to the credential and models the activity accordingly.
Credential Tracking with Syslog Ingestion
Syslog-format logs can be sent to Darktrace for parsing and can be used to provide IP assignment data for credentials -
logs can be ingested by both Masters and Probes. Matching patterns are configured on the System Configuration page. For
credential tracking, the template must be of the type “Credential Tracking Logs” and contain a username and a source IP.
For more information on configuring log ingestion, please see Ingesting Syslog for Enrichment.
Configuring a Subnet to Track by Credential
1. In the main Threat Visualizer, navigate to the Subnet

Admin page in the main menu under Admin and locate the
corresponding entry.
2. Review the DCHP setting in the Tracking column.
If Tracking Credentials is to be enabled, DHCP must be disabled.
3. Review the Credentials setting. Enabling this setting will begin

tracking the subnet by credential.
Device Tracking and DHCP

Device Tracking and DHCP
DHCP data is used by Darktrace to map IP address assignment to hostnames and MAC addresses for both tracking and
enrichment purposes. When tracking a subnet by DHCP, MAC address assignment to IPs is used for tracking and hostnames
are included for enrichment purposes only. By default, DHCP is expected on all subnets. If a subnet does not have any DHCP
traffic, such as a network of static IP servers, the Threat Visualizer Status page will show “No DHCP” in red for the offending
subnet.
Ǔ If DHCP is expected but not observed, this is indicative of missing data. To rectify, the traffic SPAN configuration may need
to be altered or, instead, DHCP logs can be ingested directly in syslog format to provide the missing assignment data.
Ǔ If DHCP is not expected, it can be disabled to remove warnings. When a subnet is to be tracked by credential, DHCP must
be disabled.
Disabling Subnet DHCP
1. Within the Threat Visualizer, navigate to the Subnet Admin

2. Locate any Subnets with No DHCP in red.
If this is expected, the warning can be removed. Otherwise,

alter the traffic mirroring configuration or setup DHCP log
ingestion to provide the missing assignment data.
3. Locate the corresponding entry.
Click the highlighted DCHP in the Tracking column to disable

DHCP for the Subnet. Save the changes.
4. Confirm that the No DHCP warning is no longer in red.

Ingesting Syslog for Enrichment

Darktrace supports syslog-format log input, allowing custom event data to be read into Darktrace and mapped to existing
devices or channeled into custom models.
Ǔ Multiple log feeds can be configured concurrently. For multiline Syslog, all logs must be received within 1 minute.
Ǔ A single log line can match against multiple templates, as long as every template is a different type. “Custom Data” templates
are treated as unique types, meaning more than one “Custom Data” template can be matched against a single event.
Ǔ Successfully parsed syslog will be added to Advanced Search.
Ǔ “Tracking” type templates are always processed first (v5.0+).
Ǔ Telemetry templates are also used to parse data retrieved by the Splunk Polling integration.
VPNs
Where a client VPN is in operation on the network - each user authenticates with a credential and is assigned an IP from a pool
- the ingestion of VPN logs is highly recommended so that Darktrace can accurately model the ‘pattern of life’ for a VPN user
regardless of IP assignment. To use VPN logs for tracking by credential, the template type must be set to “Credential Tracking”.
Darktrace provides example Telemetry templates for a number of popular VPN vendors, pre-populated with the patterns
needed to parse relevant tracking info. These templates may need to be slightly adjusted if the logs produced by your VPN
vendor are non-standard; your Darktrace representative can assist with this process.
Integration with other Security Tools
Custom event types derived from ingested event data can be used to integrate Darktrace into your existing security stack.
When a “Custom Data” template is defined, it creates a new metric which can be seen in device event logs and used in
models. Example templates for parsing third-party alerts are provided, allowing users to leverage and model contextual data
from threat intelligence tools such as CrowdStrike alongside Darktrace ‘pattern of life’ detection.
From v5, AI Analyst can be triggered to investigate based upon third-party alerts ingested via syslog. Please see AI Analyst
Triggered Investigations for more details.
DHCP
Where it is not possible to observe DHCP association directly, DHCP logs can be sent to Darktrace and used to map activity
seen in ingested traffic.
In subnets tracked by DHCP, it may also be desirable to ingest VPN logins for enrichment purposes. To do so, create a template
of the type “Custom Data” with a name that includes the string “Login”. The message component must then correspond to
the VPN username. Future log lines will then be added to the event log of the corresponding IP.
Connection Logs
Where Darktrace does not have visibility over network traffic, such as that passing through cloud based zero-trust providers,
syslog can be ingested to simulate connectivity. Pre-configured integrations are available for popular providers such as
Zscaler, or logs can be parsed and configured manually.
Manually configured connection templates must be set to the type “Connection Logs”, then the name assigned to the template
must be added to the “Log Input Connection Types” field. This advanced setting is revealed by scrolling to the end of the
System Config “Settings” tab and clicking the “Advanced Configuration” button.
Tracking with Syslog Input
Templates list both the optional and required fields for each data type; the most common types are DHCP, VPN (credential)
and Device Tracking. Tracking templates are always processed before other “types”.
If logs are ingested for the purpose of tracking, the following configuration must be set on the relevant subnet to ensure logs
are used as the primary source for tracking information.
DATA TYPE REQUIRED SUBNET CONFIGURATION TEMPLATE TYPE REQUIRED FIELDS
DHCP - Enabled, Hostname -

DHCP Logs “DHCP Tracking Logs” mac, src or ip_address
Disabled, Credentials - Disabled.
IP Assignment Logs DHCP - Disabled, Hostname -
“Device Tracking Logs” hostname, src or ip_address
(Hostname to IP) Enabled, Credentials - Disabled.
DHCP - Disabled, Hostname - “Credential Tracking
VPN Logs username, src or ip_address
Disabled, Credentials - Enabled. Logs”
Configuring a Syslog Input

Syslog Ingestion
Logs should be sent in syslog format - encrypted and unencrypted log ingestion is available along with multiple forwarding
methods. For example, vSensors can forward logs to their associated master and Unified View components can optionally
propagate logs to all subordinate masters. The table below outlines all available methods.
PORT PROTOCOL RECEIVER ENCRYPTION PROPAGATION
Master or
1514 UDP or TCP Subordinate Unencrypted Will not propagate to other masters.
Master
vSensor Forwarded to associated master
1514 UDP or TCP Unencrypted
(4.0.7+) appliance.
Hardware Forwarded to associated master
1514 UDP or TCP Unencrypted
Probe appliance.
Propagated to all subordinate
2514 UDP or TCP Unified View Unencrypted
masters.
Master or
6514 TCP Subordinate TLS / SSL Will not propagate to other masters.
Master
vSensor Forwarded to associated master
6514 TCP TLS / SSL
(4.0.7+) appliance.
Hardware Forwarded to associated master
6514 TCP TLS / SSL
Probe appliance.
Propagated to all subordinate
7514 TCP Unified View TLS / SSL
masters.
Encrypted log ingestion uses a default self-signed certificate which can be found under “Syslog Server TLS Certificate” on
the System Config page. A custom certificate can be added if desired. If required by your syslog forwarder, the SHA1 and
SHA256 fingerprints of the current certificate are available in the certificate tooltip on the System Config page or can also
be found on Status page.
In addition to processing and transmitting network traffic, hardware probes and vSensors can ingest and forward syslog-
format logs to the Darktrace master. Pattern-matching is configured on the Darktrace master and then propagated to the
vSensor to apply to all future log entries. Matching (and discarding) is performed at the vSensor level; valid matches are then
forwarded on to the master. More information can be found in the vSensor guide.
Multiple log feeds can be configured concurrently.

Allowing Syslog Input
Integrations in the Telemetry category that require syslog to be sent to the Darktrace instance will need the IP of the log
sender allowed via this process. This includes some integrations which do not require a template to be defined, such as ZPA
and ZIA. The exception is the Splunk Polling integration, where Darktrace actively retrieves the data from the Splunk instance.
1. Configure the external device to send syslog to a Darktrace

master appliance or probe (vSensor or hardware) in the desired
port/protocol combination. A full list of ports and protocols is
found above.
2. Access the Darktrace master appliance intended to receive

the logs (directly, or via a connected probe). Within the Threat
Visualizer, navigate to the System Config page in the main
menu under Admin. Select Modules from the left-hand menu.
3. In the Telemetry section, click the cog Config button. A new

dialog will open.
4. Select the appliance or probe that logs are being sent to. In
the field Log Input Allowed IPs, enter the IP address of the
device sending syslog.
Save the changes.
A template must now be defined for the logs to be parsed.

Log Ingestion Patterns

Once the application is sending syslog data to Darktrace, one or more templates must be defined for the data to be used.
As syslog enters Darktrace, it is compared against the set of matching Telemetry patterns. If one or more patterns match, the
log is parsed and used for tracking or enrichment as defined by the template “type”. Successfully parsed events are also
added to Advanced Search.
If a log does not match any templates, it is stored - unsuccessfully parsed logs can then be retrieved on the System Config
page for testing. It is useful to have example entries of the format to be parsed to use when testing and refining the pattern.
Log samples can also be pasted manually into the user interface for testing.
Parts of a Template
Each template has a name, a type, an optional filter and an extraction pattern.
Name
The template name is used as a metric where the log data appears in the user interface (for example, where credential logs
triggered a username/IP assignment), where custom data is available in the model editor or when the log entry is added to
Advanced Search.
Please note, Templates configured before Threat Visualizer v4.1, or configured on the legacy config page must include
the relevant ‘type’ pattern in the naming syntax. This is no longer required when configuring ingestion on the new System
Config page.
Type
The type of template defines how Darktrace uses the data: tracking logs are used to map IP and hostname/credential
assignments for devices seen in traffic, custom logs create events from third-party systems and are available for modeling.
Each template ‘type’ has minimum fields which must be mapped.
Filter
Templates can contain a filter - a keyword which appears only in the entries intended for parsing by the template. Darktrace
will only attempt to match the template to log entries that contain the filter. This is optional, but recommended as Darktrace
will only match a log line against one of each template “type” before discarding (excludes “Custom Data”) - adding a filter
prevents the log from being matched against the wrong template.
The filter does not affect the data that can be included in the pattern and can refer to data at any point in the log body.
Pattern
The extraction pattern - Pattern Match - defines how the log entry should be parsed. Patterns are constructed with Grok syntax
in the format %{PATTERN:field}, where PATTERN is one of the built-in shortcut strings or a regular expression surrounded
by parentheses. The list of built-in patterns can be reviewed by clicking the info icon info-circle.
Darktrace provides a number of example patterns for tools like VPN providers and endpoint security software which can be
used to parse login events or alerts.
Creating a Template
This example process assumes that the syslog being ingested does
not have any example patterns already provided. If your logs match
any of the available examples, this can be used to pre-populate the
filter and pattern.
To do so, locate the example you wish to use under the Telemetry
Templates subheading, provide a descriptive name for the pattern
and then save. It should now be possible to test the pattern provided
against log lines by following the test procedure in step 3 and step
6 below.
We will now use example log lines from a VPN server that are intended for credential tracking. These log lines take the format:
2020-01-01T01:00:10.000003+00:00 vpnhost example - - - User <testuser_1> IP Address <10.0.0.2>,

Message
Process
1. Templates are defined in the “Modules” tab of the System Config page. The first step is to locate the “Telemetry” subsection
and click the plus (+) icon to create a new template.
2. Provide a descriptive name for the pattern which can be identified later, then select the “type” of template you wish to
configure.
The type defines what Darktrace does with the data - in this example, the type is set to “Credential Tracking Logs”.
3. Set the filter for the pattern using a keyword that appears in all log lines. Here, logs from this source originate from the
host vpnhost so this can be used as a filter.
4. Now, create the pattern to parse the data in the example log using the built-in shortcut strings or a regular expression.
The pattern must include all the required fields for the template “type”, for example “Credential Tracking Logs” requires
a username and an IP address.
The following pattern extracts these values from the log entry:
User <%{DATA:username}>.*IP Address <%{IP:ip_address}>
5. Save the template. At the bottom of the window, a test section should appear where unparsed syslog entries can be
retrieved. Click the Load button until an entry appears, or paste an example log line into the Log Input Test field.
The Load button will only return syslog entries that were not successfully parsed when they entered the Darktrace
appliance.
6. Now, click the Test button to compare against the log line in the Log Input Test field. If the filter and pattern match
successfully, a “Success” message will be shown and the data extracted from the log entry will be displayed.
If the message “Matching Failed!” is returned, check that the filter value appears in the log. If so, the pattern will need to
be refined.
Alter the pattern or until all information is successfully parsed from the log line.
Telemetry cards can be deleted if no longer needed, or temporarily disabled by change the filter to a keyword that would
never appear in any log.
Preserving/Removing Whitespace in Field Values
Please note, whitespace within telemetry field values is automatically removed on parsing. To preserve whitespace, locate
the advanced setting Log Input Trim Whitespace and ensure it is disabled. This setting is found by scrolling to the end of
the System Config “Settings” tab and clicking the “Advanced Configuration” button.
Advanced Log Ingestion Syntax

Telemetry templates are powerful, flexible tools - in addition to basic pattern matching, a number of advanced techniques
can be used to define complex patterns for a number of log scenarios.
Applying Tags
Both source and destination devices seen in log ingestion can be tagged with existing tags from telemetry input. The special
fields sourcetag and destinationtag can be utilized.
User Device <%{DATA:hostname}>.*IP Address <%{IP:src}>.*<%{DATA:sourcetag}>
When matched to the following log line:
2020-01-01T01:00:10.000003+00:00 vpnhost example - - - User Device <user123.example.com> was

assigned IP Address <10.0.0.2> with message <Guest>
Would produce a hostname of user123.example.com, a src of 10.0.0.2 and add the tag Guest to the device, provided
that the Guest tag already exists in the environment.
Prefixes and Suffixes
Characters can be appended to the beginning or end of a field value using this syntax. The field name must be enclosed
in square brackets ([]).
For example, the following pattern appends and prepends the value of the username field to create an email address:
User <%{DATA:user_[username]@example.com}>.*IP Address <%{IP:ip_address}>
When matched to the following log line:
2020-01-01T01:00:10.000003+00:00 vpnhost example - - - User <123> IP Address <10.0.0.2>, Mes-

sage
The pattern produces a value for username of user_123@example.com.
Aggregating Values in a Log Line
In some scenarios, data intended to populate a field may be interrupted in a log line by unwanted characters or information.
Fields may also be aggregated to create new values. This is performed by prefixing the field name with - or +, where -
places the value before existing data and + after existing data. The default field name must still occur in the pattern match.
For example, in this log line, the user and domain should be aggregated into an email address (testuser_1@example.com)
to create the username field value.
2020-01-01T01:00:10.000003+00:00 vpnhost example - - - User <testuser_1> Domain <example.com>

IP Address <10.0.0.2>, Message
This can be done with the following pattern, using the addition of prefix and suffix values discussed above:
User <%{DATA:username}>.*Domain <%{DATA:+@[username]}>.*IP Address <%{IP:ip_address}>
The final value for username is then testuser_1@example.com.
If the field order in the log was reversed, such as:
2020-01-01T01:00:10.000003+00:00 vpnhost example - - - Domain <example.com> User <testuser_1>

IP Address <10.0.0.2>, Message
Then the aggregation could still be achieved with the following pattern:
Domain <%{DATA:username}>.*User <%{DATA:-[username]@}>.*IP Address <%{IP:ip_address}>
Returning a final username value of testuser_1@example.com.

Combining Multiline Logs
When syslog cannot be emitted in one line for ingestion by the Darktrace instance, lines can be combined using consistent
identifiers present in each line. To be aggregated, lines must share consistent strings which are indicated with the merge
field, where the numerical value defines how many lines should be aggregated.
Up to 6 individual lines can be merged. To merge two lines using a consistent value, the key merge or merge2 should be
included in the defined pattern. To merge three lines, merge3 must be used, up to merge6 for six lines. All lines must be
received within one minute of the first.
Each log line requires a separate template, but all templates must have the same name.
For example, the following log lines represent a VPN user receiving an IP Address assignment:
2020-01-01T01:00:10.000003+00:00 vpnhost example - - - received request from User <testuser_1>

for Domain <example.com> SessionID <rOI0X5PiHg>
2020-01-01T01:00:10.000006+00:00 vpnhost example - - - granting IP Address <10.0.0.2> SessionID
<rOI0X5PiHg>
The log lines have the consistent identifier SessionID <rOI0X5PiHg>.
To aggregate these lines to create a single credential tracking event, two templates are created:
FIELD TEMPLATE 1 TEMPLATE 1
Name VPN Tracking VPN Tracking
Type Credential Tracking Credential Tracking
Log Filter received request granting
User <%{DATA:username}>.*SessionID IP Address <%{IP:ip_address}.*SessionID

Pattern Match <%{DATA:merge2}> <%{DATA:merge2}>
The first pattern:
User <%{DATA:username}>.*Domain <%{DATA:+@[username]}>.*SessionID <%{DATA:merge2}>
Retrieves the values testuser_1 and rOI0X5PiHg.
The second pattern:
IP Address <%{IP:ip_address}.*SessionID <%{DATA:merge2}>
Retrieves the values 10.0.0.2 and rOI0X5PiHg.
The shared key - rOI0X5PiHg- is then used to aggregate the two lines into a single event with the username testuser_1
granted the IP 10.0.0.2.
Successful merging can be tested by entering a first example line into the Telemetry test function and performing a test, then
entering a second example line with the same consistent value and performing another test. The first line must meet the first
configured pattern, the second line must meet the second pattern. The result of the second test should also include details
from the first line parsed by the first pattern.
The second line must be entered within one minute of the initial test.
Where more than two lines are to be aggregated, test further lines within the one minute window until all patterns have been
matched. The output of the final test will contain details from the previous lines.
AI Analyst Triggered Investigations

Telemetry data from third-party investigation tools can also be used to trigger AI Analyst investigations. This is done by adding
the metric to a model - “AI Analyst > AI Analyst Third-Party Investigations”. When syslog is sent to Darktrace from the third-
party tool, an entry is created for the custom metric which triggers the model and inserts the information into the AI Analyst
investigation queue.
Like standard Darktrace model breaches, AI Analyst will begin investigation of syslog-triggered investigations one hour after
the model breach. It is highly recommended to keep the number of third-party alerts that trigger investigations low to prevent
overloading the AI Analyst and preventing legitimate investigations from occurring.
Configuring Triggered Third-Party Investigations
1. First, the tool must be sending syslog into the Darktrace

instance which is successfully parsed with a telemetry template.
Please see Configuring a Syslog Input and Log Ingestion
Patterns if this requirement is not already in place.
The name of the template used to parse the data identifies it

within the Threat Visualizer.
2. In the main menu, select Models then Model Editor as a user

with permission to Edit Models. Locate the “AI Analyst” folder
on the left-hand side and open the “AI Analyst Third Party
Investigation” model.
Click the “Edit Model” button in the top right to be begin making
changes.
3. Click on the component “Any Connection” to expand it. In the

metric field (contains “Connections” by default), search for
the custom metric - this takes the name of the template that
is parsing the data.
Select this metric, so that the model logic now reads “[Custom
Metric] > 0 in 60 Minutes”. No other changes need to be made.
4. Set the model to Active using the toggle below the description.
The model is disabled by default.
5. Now, save the changes to the model.
When alerts from the third-party tool come in, this model will
breach and create an alert in the threat tray indicating that an
investigation will take place.
Replacing the Certificate for Encrypted Syslog Ingestion

TCP TLS/SSL encrypted log input is accepted on port 6514 for standalone Darktrace master instances and subordinate
masters, and additionally on port 7514 in Unified View environments (propagated to all subordinate masters).
For encrypted log ingestion, the Appliance uses a self-signed TLS/SSL certificate by default. If required by your syslog
forwarder, the SHA1 and SHA256 fingerprints of the current certificate are available in the certificate tooltip on the legacy
System Config page or can also be found on Status page.
Replacing the Certificate
The self-signed certificate can be replaced with a trusted certificate in a process very similar to the replacement of the HTTPS
certificate.
1. Navigate to the System Config page of the master appliance receiving the logs (directly, or via a connected probe).
2. On the Settings page, click the options icon ellipsis-h beside the search bar and select “Use Legacy Page >”.
3. If the certificate to be changed is that of the master appliance currently accessed, scroll to the Syslog Server TLS
Certificate section. Otherwise, locate the subsection for the vSensor or probe that you wish to change the certificate for.
4. Beside “Syslog Server TLS Certificate”, click the Create New button. Complete the required fields.
5. At a minimum, complete the Country Code and FQDN / Common Name fields. The FQDN field should contain the
hostname of the master or probe as you wish to contact it.
6. Save the fields to generate a CSR. This can be exported and signed.
7. Paste the signed certificate into the Certificate field below the CSR and save your changes.
Labelling Key Devices and Subnets

Labelling key devices and subnets is an important step to customizing your Darktrace deployment to streamline investigation
and quickly identify key assets.
Labelling Devices
For ease of identification and prioritization, it is recommended that the most important 20-30 devices are labelled. For example,
labelling the Domain Controllers as DC1 and DC2 can assist in identifying these key assets.
Labelling a device is particularly helpful for devices that do not have a hostname, where the hostname is ambiguous, or
where a device deviates from the naming convention. Device labels appear in search results and any model breaches
associated with the device.
1. Within the Threat Visualizer, navigate to the ‘Device Admin’

page in the main menu under ‘Admin’.
2. Choose a device and click the label to begin editing it.
Enter a label such as “Mail Server” or “Finance Desktop”, and

click away from the label to save your changes.
The main Threat Visualizer user interface must be refreshed

to display any changes.
Manually Labelling Subnets
Darktrace provides the ability to label Subnet IP address ranges for ease of use. Labelling larger subnets removes the need to
memorize the purpose of each IP address range and allows for simpler Subnet searching and selection in the Threat Visualizer
Individual subnets can be manually labelled within the Threat Visualizer user interface.

2. Click the IP address value under the LABEL column to edit it.
Enter a short description such as “Public Wifi”, and click the

Save button on the right.
3. Confirm the label has changed.

Uploading Labels
To make changes to a large number of Subnets on the Subnet Admin page, it is possible to upload a CSV file containing
Subnet details. It is possible to upload network ranges for subnets currently unseen in Darktrace in order to pre-define labels.
A correctly formatted CSV file containing all current Subnet information (including labels) may be downloaded from the Subnet
Admin page using the Download CSV button.

2. Click Edit Subnet Details, a Choose Files option will appear.
Select your CSV file and click Process File
3. A prompt will appear detailing the changes to be made.
Confirm the changes.

Configuring HTTPS Certification

Uploading a valid HTTPS certificate will prevent the web browser warning that the connection to the Threat Visualizer uses
an invalid certificate. For example, in the Chrome browser, this is indicated by a red line through the ‘https’ part of the URL
and may also present the user with a warning that must first be dismissed before accessing the Threat Visualizer interface.
Darktrace Appliances are shipped with a self-signed certificate for the hostname "dt-XXXX-YY" - the internal appliance
hostname as designated by Darktrace. Self-signed certificates are often not trusted by web browsers and therefore a warning
may be displayed when accessing the appliance. Additionally, it is common practice for companies to have their own appliance
naming conventions, and it is likely the Darktrace designated name will not fit into such a scheme.

page in the main menu under Admin. Scroll down and locate
the HTTPS Certificate section. Click New.
2. A series of fields will appear requesting additional information.

Complete as much information as possible. At a minimum,
populate the Country and Fully Qualified Domain Name.
3. Once the minimum number of fields are complete, the Generate

CSR button will become available. By clicking Generate CSR,
the supplied information is used to generate a Certificate
Signing Request in PEM format
The CSR should be copied to a file and provided to a Certificate

Authority such as Digicert or GoDaddy who will provide a
certificate in return for a nominal fee.
Alternatively, a local certificate authority may be used, provided

the facility is available and users of the appliance are likely to
have the root certificates present on their connecting clients.
4. Upon receiving the certificate back from the Certificate Authority,

return to the HTTPS Certificate section and paste the PEM
encoded contents of the certificate into the Certificate field.
Click Save to apply the change.
Reload the Threat Visualizer and confirm that the invalid

certificate warning has gone.
Configuring an LDAP Server

The Darktrace Threat Visualizer supports integration with LDAP servers such as Active Directory for both authentication and
enrichment. Providing details of an LDAP server for the Darktrace appliance to utilize will allow configuration of the following:
Ǔ Authentication to the Threat Visualizer interface using credentials from an LDAP server.
Ǔ Enrichment of user details in the Threat Visualizer by providing additional LDAP attributes for users and the optional creation
of LDAP group tags for use in modeling.
This guide will explain how to configure an LDAP server for the above purposes, or to provide enrichment information for
Antigena Email.
To configure enrichment, please see Using LDAP data for Enrichment and to configure authentication, please see Accessing
the Threat Visualizer using LDAP.
Adding the LDAP Server
1. Within the Threat Visualizer, navigate to System Config in the

main menu under ‘Admin’.
If not already selected, choose Settings from the left-hand

menu.
2. Scroll down and locate the LDAP/Active Directory section.
Under the LDAP Global Settings heading, enter an LDAP server

IP address or hostname in the LDAP Server/Domain Controller
field. For additional configuration - such as a port number or
SSL - alter the value as indicated in the question-circle tooltip.
3. For the LDAP Username, specify a username with credentials

to access the LDAP server that Darktrace can utilize.
For example:
darktrace@examplecompany.com
cn=darktrace,dc=examplecompany,dc=com
Enter a corresponding password for this user into the LDAP

Password field.
4. In the LDAP Account Attribute field, provide an LDAP attribute

to match user credentials with. This should be the name of
the field in LDAP containing a user’s username.
A user search filter is also supported. Please review the

additional information about supported strings in the question-
circle tooltip.
5. Set the LDAP User Base path to identify the users in the LDAP
tree. For example: ou=users,dc=company,dc=com.
6. Darktrace supports two methods of secure LDAP integration:

LDAPS (LDAP over SSL) and LDAP with STARTTLS. For
enrichment, these settings are optional but strongly
recommended and for LDAP authentication a secure method
is a minimum requirement. Only one of the two modes can
be enabled at one time.
If LDAPS is configured in the LDAP Server/Domain Controller

field, LDAP Enforce StartTLS must be disabled.
If LDAPS is not configured, LDAP Enforce StartTLS can be

enabled.
7. An LDAP Certificate is optional for both forms of encryption.

Omitting a value disables certificate validation.
8. Optionally enable the LDAP Digest Authentication to enable

SASL authentication if desired.
9. If LDAP Server Referrals are in use, enable this field.
Save all the changes made. Optionally test your configuration

using the “Test LDAP” button.
Multiple LDAP Servers
To add additional LDAP servers, complete the configuration for the first server and then click the “Add Server” button at the
bottom of the config section. By default, settings for this new server will be collapsed so that it can be placed above or below
the existing server in priority - click the name of the server or the - icon to expand and configure the fields for the new LDAP
server. Servers are identified by the contents of the “LDAP Server/Domain Controller” field.
A maximum of eight LDAP servers can be configured.

Using LDAP data for Enrichment

This guide will explain how to configure LDAP authentication to the Threat Visualizer - a configured LDAP server is presumed.
If a server has not yet been configured, please follow Configuring an LDAP Server before attempting to configure enrichment.
To configure optional LDAP authentication to the Threat Visualizer, please see Accessing the Threat Visualizer using LDAP.
Configuring LDAP Enrichment
LDAP data can also be retrieved to enrich the Threat Visualizer interface.
1. Remaining within the LDAP/Active Directory section, locate

the LDAP Enrichment subsection.
For now, leave LDAP User Attributes with the default value.
2. Set the LDAP Test User to a valid user identifiable by the

Threat Visualizer and click the Test LDAP button at the top
of the section.
This will perform a test against the LDAP settings configured

so far and retrieve a list of mapped and unmapped attributes
available for enrichment.
3. An LDAP success message is displayed if a connection is

established. A warning will appear if the communication is
not encrypted.
Click the info icon info-circle to review the list of attributes. If

the user is invalid or not identifiable by the Threat Visualizer
on the LDAP server provided, this icon will not appear.
Mapped attributes are attributes already shown in the user

interface.
Unmapped attributes list all the LDAP attributes which are

available, but not currently shown in the interface.
4. To append values as mapped attributes, review the LDAP

User Attributes field.
Attributes are set as key-value pairs, for example Email=mail.

The first part (Email) represents how the information will be
displayed in the Threat Visualizer. The second part refers to
the name of an attribute returned by LDAP, for example mail
or displayName.
Unmapped attributes returned by the test attempt can be

mapped by adding a series of comma separated key-value
pairs in this field.
Once additional attributes have been added, save the changes

and run the test again to verify they now appear in the Mapped
Attributes section.
5. These new user attributes from LDAP can be viewed in

the Device View. Select a device and hover over it to view
additional details set in the LDAP User Attributes field. This
could include the user name, email, group, and telephone
number.
Creating Tags from LDAP Groups
As an optional feature, Darktrace tags can be created from LDAP groups and automatically assigned to users that the Threat
Visualizer observes. Tags can then be used in Darktrace models to target devices associated with an LDAP user.
1. Remaining in the LDAP/Active Directory section locate LDAP

Create Group Tags in the LDAP Enrichment subsection. The
value of this field is used to match LDAP groups - groups that
match the value will generate tags and users in the matching
group will be tagged automatically. This field supports wildcards,
multiple comma-separated values and is not case-sensitive.
2. When tags are created, a prefix is inserted before the group

name to indicate that the tag refers to an LDAP group. By default,
this prefix is “Group:”. Optionally modify the contents of the LDAP
Group Tag Prefix if you wish to change this prefix.
Save your changes.

Accessing the Threat Visualizer using LDAP

This guide will explain how to configure LDAP authentication to the Threat Visualizer - a configured LDAP server is presumed. If
a server has not yet been configured, please follow Configuring an LDAP Server before attempting to configure authentication.
To configure optional LDAP enrichment, please see Using LDAP data for Enrichment.
Configuring LDAP Authentication
The following steps configure the Threat Visualizer to allow user authentication via LDAP.
1. Remaining within the LDAP/Active Directory section, locate

the LDAP User Authentication subsection.
Enabling Darktrace LDAP Authentication will allow users to

login to Darktrace using LDAP credentials.
Note, this option cannot be used with unencrypted LDAP

connections.
2. The optional field LDAP Authentication Group Value can

restrict usage of LDAP authentication to specific groups - only
users belonging to the group specified as the field value can
gain access to Darktrace. This field supports wildcards and
is not case-sensitive.
3. When an LDAP user meets the group membership criteria to

access Darktrace, the Threat Visualizer can optionally retrieve
other groups they are a member of and make them available
to assign permissions and network visibility to. This can be
particularly useful where security teams are divided into groups
for specific network regions or platforms (for example, email
or SaaS only).
Group names entered into the LDAP Populate Groups field

will be retrieved and surfaced in Group Admin. This field can
take multiple values and wildcards.
4. Advanced LDAP User Authentication Configuration provides

access to the following settings:
Ǔ LDAP Group Attribute Name

Ǔ LDAP Group Search Base
Ǔ LDAP Group Search Filter
Ǔ LDAP Group Search Groups Attribute
Ǔ LDAP Group Search User Attribute
Ǔ LDAP Group Search User Attribute Value
If you wish to modify any of these settings, expand the section

and alter the settings as indicated in the question-circle tooltip.
If not, save your changes. Optionally test your configuration

using the “Test LDAP” button.
When an LDAP user accesses Darktrace for the first time after LDAP authentication is configured, any groups they are in
which match the LDAP Authentication Group Value or LDAP Populate Groups will be added to the Group Admin page. For
example, an LDAP Authentication Group Value of *darktrace* will create a group for the LDAP group DarktraceAnalyst.
Group Admin is available from the main menu under Admin. On this page, permissions and network visibility ranges can be
applied to each group. A user can be part of multiple groups which add additional permissions. Permissions added via Group
Admin will always take priority over those granted in User Admin.
When a new Group is created, ensure that user permissions for the group are updated in Group Admin to match the desired
authorization. The default admin user can review the permissions assigned to each user on the Permissions page. Individual
LDAP users do not appear on the User Admin page or the Group Admin page - only LDAP groups will appear on Group Admin.
Please note, LDAP users must have Mobile App permissions explicitly revoked on the Permissions page. Removing the
permission from an LDAP group on Group Admin is not sufficient.
Accessing the Threat Visualizer using SAML 2.0

Darktrace master instances running v5 and above support authentication and access via SAML 2.0 Single Sign On. The
following guide provides a generic configuration process for allowing SAML 2.0 access to your Darktrace instance via your
organizational ID Provider.
Please note, the Darktrace mobile app does not support users created and authenticated exclusively by SAML SSO. A Threat
Visualizer user created via the User Admin page or a compatible LDAP user are required to authenticate with the mobile
app at this time.
Requirements
Ǔ A Fully Qualified Domain Name (FQDN) configured for the Darktrace instance. This can be found on the “Settings” tab of
the Darktrace System Config page, under “System” and is required before generating the XML for configuration.
Ǔ Users intended to access the Darktrace instance via SAML 2.0 must be grouped in top-level (not-nested) groups in the
ID Provider.
Ǔ The Darktrace instance must be accessible by the ID Provider to send the assertion.
Before Configuration
In your ID provider, configure a new service provider using the configuration values listed below. These values are also
provided on the Darktrace System Config page.
SAML RESPONSE CONFIGURATION
https://[FQDN]/sso/login (e.g., https://example.darktrace.com/sso/

Assertion Consumer Service (ACS) URL (1)
login)
EntityID [FQDN] (e.g., example.darktrace.com)
https://[FQDN]/sso/login (e.g., https://example.darktrace.com/sso/

Login URL
login)
https://[FQDN]/sso/logout (e.g., https://example.darktrace.com/

Logout URL
sso/logout)
Sign Assertion True
Sign Response True
Signature Algorithm SHA-256
Expected NameID format Unspecified (urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified)
A minimum of an attribute for username (such as nameID) and group

Required Attributes in Assertion (2)
membership attributes (such as memberOf)
(1)The ACS URL may be referred to by a different name in your ID provider, such as “Reply URL” (AzureAD) or “Single sign
on URL” (Okta).
(2)Darktrace requires users intended to use the Threat Visualizer to be members of a group, and for group attributes to be
sent as part of the SAML assertion. This is not sent by default in a number of environments, so ensure this information is
included when configuring your ID provider.
When the Service Provider entry is configured, retrieve the SAML metadata XML and store it securely for use during configuration.
Darktrace Configuration Process
1. Within the Threat Visualizer, navigate to System Config in the

main menu under ‘Admin’.
If not already selected, choose Settings from the left-hand

menu.
2. Scroll to locate the SSO Configuration section, then the SAML

2.0 subsection.
3. In the SAML Configuration XML field, paste the contents of

the XML file generated by your ID provider.
4. Provide the name of the attribute sent in the SAML assertion

that identifies the username - for example, nameID - into the
SAML Username Attribute Name field.
5. In the SAML Authentication Group field, enter the name of the

(top-level) group of users permitted to access Darktrace from
your ID Provider. Wildcards are supported to define multiple
groups, for example Darktrace* would match and allow the
groups “DarktraceUsers” and “DarktraceAdmin”.
Only users belonging to the groups matching the field value

can gain access to the Threat Visualizer.
6. In the SAML Group Attribute Name, enter the name of the

attribute that corresponds to group membership in the SAML
assertion sent by your ID provider. For example, memberOf.
7. Save your changes.
8. Attempt to access the Darktrace instance from another browser,

such as a private session, and review the login screen - Login
Via SSO should be visible.
It is not recommended to log out entirely in case any alterations

need to be made within the Darktrace System Config page.
Attempt to log into the Darktrace instance as a user permitted to

access the instance by your ID Provider. If access is successful,
configuration is complete.
Optional Settings
FIELD DESCRIPTION
In a UV environment, where FQDN has been made available to all

SAML Fully Qualified Domain Name subordinate masters, this field can be used to specify the exact FQDN of the
(FQDN) UV instance to be accessed. Where an FQDN value is set at the top level, this
field can be left blank.
When integrating with Azure ADFS, enable this setting to resolve error
SAML Disable RequestedAuthnContext
AADSTS75011.
Troubleshooting
The Test SAML Set Up button will check the current configuration and report the last error seen. If a user tries to access the
Threat Visualizer but is unsuccessful, error information will be shown here.
If the Threat Visualizer login page successfully redirects to your ID Provider but an error is shown by the provider, this indicates
a potential issue with the configuration in that environment. Ensure that your user is permitted to access the Darktrace
application in the ID provider environment.
If the Threat Visualizer login page successfully redirects to your ID Provider, the login to the provider is then successful, but
the user is redirected back to the Threat Visualizer login page - this suggests an error with the SSO configuration of the
Darktrace instance or that the assertion does not include all necessary fields. Confirm that the group and attribute information
match that sent by the ID Provider and that all required attributes are being sent.
Permissions and Access
When a SAML SSO user accesses Darktrace for the first time after SSO authentication is configured, any groups they are in
which match the SAML Authentication Group will be added to the Group Admin page. By default, these groups will have
no access permissions assigned and users will be presented with a warning that they do not have authorization to access
the service.
There are two workflows to configure permissions - preemptively create one or more groups on the Group Admin page which
exactly match the name of the SAML SSO groups(s), or wait for groups to be populated automatically on first login and then
assign permissions. Auto-populated groups will have no permissions assigned.
When a new Group is created, ensure that user permissions for the group are updated in Group Admin to match the desired
authorization. Hierarchically, SAML SSO users belong to the admin user who can review the permissions assigned to each
user on the Permissions page. SAML SSO users do not appear on the User Admin page.
Example User Permissions

Three user access configurations are covered below. These profiles encompass common roles utilized by organizational
security teams when using Darktrace. These roles can be used as a starting point when assigning permissions to new users.
(a). Basic threat analysis in obfuscated privileges:
Ǔ Visualizer Ǔ One Click Analysis

Ǔ Acknowledge Breaches Ǔ Ask Expert
Ǔ Discuss Breaches Ǔ Dynamic Threat Dashboard
Ǔ View Models Ǔ Register Mobile App
Users with this access are unable to identify users of a particular device, but can make comments and acknowledge breaches.
They do not have access to Advanced Search or privileges to change and administration settings.
(b). Full threat analysis privileges:
Ǔ Visualizer Ǔ Download PCAPs

Ǔ Device Admin Ǔ Antigena
Ǔ Advanced Search Ǔ Antigena Email (+ Antigena Email-specific permissions)
Ǔ Status Ǔ Unrestricted Devices
Ǔ Acknowledge Breaches Ǔ Create AI Analyst Investigations
Ǔ Discuss Breaches Ǔ Ask Expert
Ǔ Edit Domains Ǔ Dynamic Threat Dashboard
Ǔ API Help Ǔ Register Mobile App
Ǔ View Models Ǔ Explore
Ǔ One Click Analysis
Ǔ Create PCAPs
The following options provide full threat analysis with Advanced Search and capability to identify users. Packet Capture and
Antigena are also available. The user can also trigger AI Analyst investigations.
(c). Full administration privileges:
Ǔ Visualizer Ǔ One Click Analysis

Ǔ Edit Models Ǔ Create PCAPs
Ǔ Device Admin Ǔ Download PCAPs
Ǔ Subnet Admin Ǔ Antigena
Ǔ Audit Log Ǔ Antigena Email (+ Antigena Email-specific permissions)
Ǔ User Admin Ǔ Unrestricted Devices
Ǔ Group Admin Ǔ Create AI Analyst Investigations
Ǔ Advanced Search Ǔ View Messages
Ǔ Status Ǔ Download TIRs
Ǔ Acknowledge Breaches Ǔ Ask Expert
Ǔ Discuss Breaches Ǔ Dynamic Threat Dashboard
Ǔ Edit Domains Ǔ Register Mobile App
Ǔ Configuration Ǔ Explore
Ǔ API Help Ǔ System Admin
Ǔ View Models
Full Administration access to change system configuration and perform details threat analysis. Typically, this level is granted
to System Administrators only.
Guide to User Privileges

User Admin provides options to control access and restrict privileges for user accounts within the Threat Visualizer application.
User privileges can be configured by enabling values in blue, and then clicking the Save button. By default, the ‘admin’ user
will possess all available privileges. User access can also be controlled by creating user groups in the Group Admin page
and assigning specific permissions to each group.
Organizations with Antigena Email can also control permissions for the Email Console from this page. Adding the ‘Antigena
Email’ permission to a user will expose the additional permissions, indicated by the ‘envelope’ icon. Antigena Email permissions
can be reviewed in User Permissions in the Antigena Email Visual Guide.
PERMISSION AVAILABLE IN DESCRIPTION
Enables users to acknowledge model breaches. Any user investigating

Acknowledge Threat Visualizer,
breaches should likely have access to this role. Recommended for all but
Breaches SaaS Console
the most restricted user.
Advanced Search provides a deep insight into network traffic making
Threat Visualizer, every connection searchable. An excellent tool for investigating suspicious
Advanced Search
SaaS Console activity, but may be restricted to more privileged positions due to the
insight granted.
Threat Visualizer, Enables changes to be made to Antigena functionality. A valid Antigena
Antigena
SaaS Console license is required.
Allows users to access the Antigena Email console - adding the permission
Threat Visualizer, to a user will reveal all Antigena Email permissions available. Users given
Antigena Email
SaaS Console only the Antigena Email permission and lacking the Visualizer permission
will redirect to the Antigena Email console upon login.
Provides information on the Threat Visualizer API. Recommended for all
API Help Threat Visualizer
administrators and developers.
Threat Visualizer, Ask Darktrace Analysts questions about particular Model breaches.
Ask the Expert
SaaS Console Requires an additional Ask the Expert license.
Lists captured user behavior such as logging into Darktrace. Typically for
Audit Log Threat Visualizer
administrators only.
Configuration/ Threat Visualizer, Make changes to the System Configuration page. Typically for
System Config SaaS Console administrators only.
Create AI Analyst Threat Visualizer, Allows the user trigger AI Analyst investigations into devices and SaaS
Incidents SaaS Console users.
Enables users to create Packet Captures in the Threat Visualizer
Create PCAPs Threat Visualizer
application. Recommended for users familiar with Wireshark or other tools.
Lists all devices observed by Darktrace and allows for changes to be made
Device Admin Threat Visualizer to their classification. This is particularly useful for searching, bulk tagging,
or changing device types. Typically for administrators only.
Makes comments on model breaches. Very useful for controlling and
Threat Visualizer,
Discuss Breaches highlighting which users are working on a model. Recommended for all but
SaaS Console
the most restricted user.
Allows user to download created Packet Captures. Recommended for
Download PCAPs Threat Visualizer
users familiar with Wireshark or other tools.
Threat Visualizer, Enables users to download Threat Intelligence Reports. This permission is
Download TIRs
SaaS Console required to generate Executive Threat Reports.
Dynamic Threat
Threat Visualizer Provides access to the Dynamic Threat Dashboard.
Dashboard
Edit Domains Threat Visualizer Make changes to domain information. Typically for administrators only.
PERMISSION AVAILABLE IN DESCRIPTION
Threat Visualizer, Make changes to Models, including the addition of defeats. Required for
Edit Models
SaaS Console ‘One click defeats’ in the Model Breach log.
Provides access to the Explore functionality that allows playback of
Explore Threat Visualizer communication between Subnets or Tags at a given point. Fixed positions
can be provided and set. Recommended for most analysts.
Threat Visualizer,
Group Admin Controls access to group privileges. Typically for administrators only.
SaaS Console
Provides a quick view of the model breach to assist in identifying and
One Click Analysis Threat Visualizer investigating model breaches. Recommend for all users performing threat
analysis.
Register the Darktrace Threat Visualizer mobile app. The mobile app (IMAP
Register Mobile Threat Visualizer,
or Cloud Service) must be configured. Enabling this functionality provides
App SaaS Console
users with this access to a link on the Account Settings window.
Threat Visualizer, Controls access to the SaaS Console, a specialized user interface for
SaaS Console
SaaS Console investigating SaaS and Cloud activity.
Threat Visualizer, For administrators and developers to check the system health of the
Status
SaaS Console Darktrace appliance, probes, and network traffic.
Lists all subnets and allows for changes to be made to their configuration.
Subnet Admin Threat Visualizer
Typically for administrators only
Permits the user access to administrative features. Currently allows access
to trigger an appliance reboot from the System Config page. Please note,
System Admin Threat Visualizer
this is available on physical instances only and applies to Masters and their
probes (not Unified Views).
When enabled, users can view all user credentials that have accessed
Unrestricted Threat Visualizer, a device. Disabling this option restricts users to an obfuscated view
Devices SaaS Console and will prevent access to Device Admin and Executive Threat Reports.
Recommended for restricted users.
Threat Visualizer,
User Admin Controls access to user privileges. Typically for administrators only.
SaaS Console
Allows the user to view system messages on login (such as reboot
View Messages Threat Visualizer notifications) and those sent by Darktrace to the Darktrace Appliance.
Recommended for admin users.
To help understand how a model breach occurred, it is recommended that
Threat Visualizer,
View Models all users have access to View Models. Note there is a separate privilege for
SaaS Console
editing roles, which is much more restricted.
Access to the main Threat Visualizer interface and limited read-only access
Visualizer Threat Visualizer
to some admin pages.
Anonymization Mode
Darktrace’s technology has been designed with protection and controls in place that allow customers to comply with a range
of privacy and confidentiality policies. Anonymization Mode can be configured for enhanced anonymization on a per-user
basis. The mode anonymizes the hostnames and IP addresses of client devices and the usernames of SaaS users. The mode
does not impact any devices classified as servers.
If set, this mode anonymizes various aspects of the data seen by Darktrace, in order to protect the privacy of employees
and to comply with European privacy laws.
Anonymization Mode includes the following features:
Ǔ The last octet of IPv4 addresses is anonymized. For example, 192.168.0.22 is anonymized to 192.168.0.#36178
Ǔ Hostnames are anonymized. For example, this.companydomain.internal is anonymized to #63680206
Ǔ SaaS users and resources are anonymized
Ǔ Credentials are not displayed
Ǔ No PCAPs can be generated
Ǔ Executive Threat Reports cannot be generated
Ǔ Access to Advanced Search is restricted
Enabling Anonymization Mode
1. Within the Threat Visualizer, navigate to ‘User Admin’ in the main menu under ‘Admin’.
2. Deselect the Unrestricted Devices, Create PCAPs and Advanced Search options and save the changes.
3. Repeat for all users intended for anonymization.
The operation of the Darktrace API in anonymization mode is also supported from v5.1 - granting API access to a user without
the Unrestricted Devices permission will anonymize returned data and restrict endpoint access.
Configuring An Email Server for Alerts

Email Alerts
Email alerts for model breaches, AI Analyst events and System Status alerts can be generated in three different formats:
HTML, Plain Text and JSON. HTML alerts are formatted to be consistent with the Darktrace Threat Visualizer and are the
most popular export format that Darktrace offers. Model Breach and AI Analyst Alerts include important information about
the source device, the breach conditions and a direct link to the breach for ease of investigation. Plain text and JSON format
are suitable for parsing by other tools such as SIEMs or middleware.
Email alerting is especially important for teams that do not have enough time to regularly check the Threat Visualizer and
would rather log in for specific alerts only. Some organizations may prefer to send all model breaches and incidents to a
central SOC team, while others prefer to configure the email alerts, so they are only alerted to the most serious model
breaches or highly scoring AI Analyst events. A series of rules and filters can be defined for each recipient, ensuring alerts
are distributed to the relevant security team member.
Requirements
Ǔ A Fully Qualified Domain Name (FQDN) must be configured for the Darktrace instance for links to be included in external
alerts. This can be found on the “Settings” tab of the Darktrace System Config page, under “System”.
Ǔ Emails are only sent when a model is set to alert (model breaches only). To view this setting, edit a model and confirm that
the Action section has ‘Alert’ selected.
Email Server Configuration
Details for an email server which can be utilized by Darktrace must first be provided before individual recipients can be
configured.
1. Within the Threat Visualizer, navigate to the ‘System Config’

page in the main menu under ‘Admin’.
From the left-hand menu, select Modules and choose Email

from the available Workflow Integrations.
2. Complete the Server location and optionally modify the

communication port. Ensure that the port selected is allowed
by any intermediary firewalls.
3. Provide a Sender Name and Sender Email Address - these

values will appear to the recipient as the sender of the email
they receive.
4. A Username and Password must also be provided so that

Darktrace can send email alerts via the server. The sender
email address must match the username value.
These fields are required in the vast majority of cases. However,

if the Darktrace appliance is intended to connect to an SMTP
server which does not require authentication, these fields can
be omitted.
5. Email alerts can use STARTTLS or SSL - these settings are

optional but strongly recommended. Only one of the two
modes can be enabled at one time.
Sending Email Alerts for Model Breach Alerts

Multiple email alert recipients can be configured in parallel with different email formats, filter options and restrictions. This is
particularly valuable where network areas are handled by different security teams, or where email alerts are both utilized by
human analysts and ingested into other security tools.
Darktrace Model Breach Alerts
A model is used to define a set of conditions which, when met, will alert the system to the occurrence of a particular event
or chain of anomalous behavior. Default Darktrace models are focused on ‘pattern of life’ anomaly detection, potentially
malicious behavior and optional compliance issues - organizations can create their own models to mirror internal policy or
an existing SOC playbook.
Model breach alerts are surfaced within the Darktrace Threat Visualizer platform; to keep security teams informed on-the-go
and to integrate with a full range of security tools, alerts can also be issued to external systems in a wide range of formats.
Adding an Email Alert Recipient
1. If you are not already modifying Email Alert configuration,

navigate to it via Admin > ‘System Config’ > Modules and
choose Email from the available Workflow Integrations.
In the ‘Settings’ tab, there are two configuration sections: Email

Server and Email Recipients. When email alerts are configured
for the first time, a blank recipient section should already be
visible. To add an additional section, click the “New” button.
2. First, enter one or more recipient email addresses that should

receive emails configured with these settings.
3. Select a format for the email alerts. When HTML Format is

enabled, email alerts will be sent formatted. When JSON
Format is enabled, email alerts will be sent in plain text with
the alert structured in JSON. When both HTML Format and
JSON Format are disabled, email alerts will be sent in plain text.
4. Enable any additional settings or filters as desired.
A full, detailed list of filters and settings is available in Email

Alert Filters and Optional Settings.
If any fields are read-only, it means that these thresholds are

configured globally. Please see Global Alert Thresholds in
Email Alert Filters and Optional Settings.
5. Finally, enable Send Alerts and save your changes.

Sending Email Alerts for AI Analyst Events

The Darktrace Cyber AI Analyst investigates, analyzes and reports upon threats seen within your Darktrace environment;
as a starting point, it reviews and investigates all Model Breaches that occur on the system. If behavior which would be of
interest to a cyber analyst is detected, an event is created.
AI Analyst incidents in the Threat Visualizer UI are comprised of one or more events, where an event is a tab within each
incident.
Ǔ Where an incident is multiple events on the same device, the Threat Visualizer groups events by the device triggering
the activity to create a device incident.
Ǔ Where an incident in the UI is cross-network - involves multiple devices - it groups events by activity type.
Minimum AI Analyst Score is the only threshold that impacts AI analyst alerts. Any alert thresholds such as Minimum Breach
Priority, Model Expression or those set globally do not filter AI Analyst incident events. As of v5.1, AI Analyst alerts obey the
global Restricted View Alerts setting. A full, detailed list of filters and settings is available in Email Alert Filters and Optional
Settings.
Alert Mode
AI Analyst events can be sent in two modes, curated and immediate. In immediate mode, events are sent as soon as they
are created but are not filtered, producing a greater volume of alerts. Immediate alerts can be filtered with a score threshold
- by default, 80. In curated mode, a selection of high scoring events occurring in the last seven days that are deemed ‘most
interesting’ to a cyber analyst are sent once an hour.
The alert mode can be altered by changing the state of “Send Immediate AI Analyst Alerts”.
Sending AI Analyst Events via Email



receive AI Analyst events via email.

4. Enable Send AI Analyst Alerts.
AI Analyst emails can be added to existing configured recipients

by enabling this toggle in addition to Send Alerts for model
breach alerts.
An additional option will appear - Send Immediate AI Analyst

Alerts. This toggle alters the alert mode between immediate
and curated.

Save the changes.
Please note, AI Analyst incidents are aggregations of events within a timeframe. Incidents as presented in the User Interface
may not directly correlate with those sent individually via email due to differing time or scoring parameters.
Sending Email Alerts for System Status Alerts

System Status alerts keep Darktrace operators informed of system health, changes in monitored traffic, and any errors
experienced by Darktrace Security Modules or virtual sensors. Alerts include details of the originating host, the severity of
the event and useful links to investigate or resolve the issue. Notifications are sent for active system events and on event
resolution.
Any model breach alert filters such as Minimum Breach Priority, Model Expression or those set globally do not filter System
Status alerts. A full, detailed list of filters and settings is available in Email Alert Filters and Optional Settings.
Sending System Status Alerts via Email



receive System Status events via email.


5. Enable Send System Status Alerts.
Save the changes.

Email Alert Filters and Optional Settings

Email alerts can be modified and filtered using a series of optional fields. All settings are on a per-recipient - or set of
recipients - basis.
Some fields are applicable only to specific alert types, others such as timezone are set universally for email alerts across all
alert types. A field may not appear unless the relevant alert type has been enabled.
Optional Settings
FIELD NAME APPLIES TO DESCRIPTION
Timezone All alerts This setting alters the timezone of timestamps displayed in the email alert.
Allows a custom prefix to be inserted before the text of the subject line for
Subject Prefix All alerts
email alerts.
Allows the subject line to be customized entirely using a set of template
Subject Template All alerts
values (time, device, label, hostname, name, score, ip).
When AI Analyst alerts are enabled, this setting allows to toggle between
immediate mode (enabled) and curated mode (disabled). In immediate
Send Immediate AI mode, events are sent as soon as they are created and can be filtered
AI Analyst Alerts
Analyst Alerts with a minimum score. In curated mode, a selection of high scoring events
occurring in the last seven days that are deemed ‘most interesting’ to a
cyber analyst are sent once an hour.
Optional Filters
An alert must meet all relevant criteria to generate an external alert - not all criteria are applicable to all alert types. Where
more than one relevant filter is in place, the alert must meet all filters.
FIELD NAME APPLIES TO DESCRIPTION
Every model has a priority from 0-5 indicating the breach severity.
Minimum Breach Model Breach
Providing a minimum alert priority of 1 to 5 will restrict model breach alerts
Score(1) Alerts
to models that fire with a threshold of the priority number or greater.
The model breach score is displayed when hovering over the colored
line to the left of a model breach. Providing a minimum breach score will
Minimum Breach Model Breach
prevent model breaches under that threshold from generating email alerts.
Priority(1) Alerts
The score is a percentage representing the overall priority of a breach and
can be filtered with a slider in the main Threat Visualizer.
Model Breach A regular expression can be entered to restrict model breach alerts to
Model Expression(1)
Alerts model names that match the regular expression defined.
Model Tags Model Breach A regular expression can be entered to restrict model breach alerts to
Expression Alerts models with specific tags that match the regular expression defined
Model breach alerts can be restricted to a list of device IPs or network
Model Breach
Device IPs ranges for the recipients specified, allowing specific subnets to be sent to
Alerts
specific teams or analysts.
For immediate AI Analyst alerts (where Send Immediate AI Analyst Alerts
AI Analyst Alerts is enabled), a minimum threshold for the AI Analyst score can be provided.
Minimum AI Analyst
(Immediate mode Incident events below this score will not produce email alerts. Please note
Score
only) this is not available for curated AI Analyst alerts, as only those with high
scores are selected.
This setting allows System Status email alerts to be only sent when a
Minimum System System Status
minimum severity level is met. Those below the level will still appear on the
Alert Severity Alerts
System Status page but will not generate external email alerts.
(1) Indicates a setting may be controlled by the global alert thresholds

Global Alert Thresholds
If the fields are read-only within the recipient configuration section, it means that these thresholds are configured globally.
Global Settings can be accessed from the cog Config button to the right of Workflow Integrations, and enabled on a per-format
basis using “Enable Modular Alert Thresholds”.
Example Email Alerts

In the Darktrace Threat Visualizer, the option to send automated email alerts in various formats is available. The following
examples demonstrate the email alerts that Darktrace can produce. Some objects, such as devices, contain optional fields
which will not return if no data exists.
Please note, in order for alerts to contain links back to the Threat Visualizer, the FQDN must be set on the System Config
page. This field should contain the resolvable hostname or IP address of the Darktrace appliance.
Model Breach Alerts
The following are examples of model breach alerts in HTML and in plain text format. This is the way the alerts will appear in
your email, if you have opted to receive email model breach alerts. The examples below contain illustrative values but are
true representations of such alerts.
HTML Format
This is a model breach alert in HTML format as received via email.
The above example also demonstrates the Restricted View alert

setting.
Plain Text
This is a model breach alert in plain text format as received via email.

setting.
System Alerts
The following are examples of system alerts in HTML and in plain text format. This is the way the alerts will appear in your email,
if you have opted to receive email system alerts. The examples below contain illustration values but are true representations
of such alerts.
HTML Format
This is a system alert in HTML format as received via email.
Plain Text
This is a system alert in plain text format as received via email.

AI Analyst Alerts
The following are examples of AI Analyst alerts in HTML and in plain text format. This is the way the alerts will appear in
your email, if you have opted to receive email AI Analyst alerts. The examples below contain illustration values but are true
representations of such alerts.
HTML Format

setting
Plain Text
Configuring the Mobile App

The Darktrace mobile app allows users to easily access Enterprise Immune System Alerts when they are on the move. In
order to associate the Darktrace Mobile app with your Darktrace deployment, the Darktrace mobile app Service must be
launched. Filtering can then be performed on a per-user basis within the app itself.
Mobile App Alerting Configuration
1. Navigate to the System Config page from the Darktrace Threat

Visualizer Main Menu.
2. From the left-hand menu, select Modules and choose Darktrace

Mobile App Service from the available Workflow Integrations.
3. A configuration window will open. Select a region to host the

mobile app push notification service from the dropdown.
Save the change.
4. The Service Status should state “Successfully registered to

push notification service in region: [region]”
The mobile app service is now launched. Navigate to

Registering the Mobile App to register the mobile app and
start receiving alerts.
Mobile App Permissions
Mobile app permissions per User can be set by the Administrator via the Account Permissions page, and can be revoked at
any time. If the administrator revokes mobile app permissions, the model breach, Antigena and summary cached data within
the app is deleted for the given user.
If a Darktrace user using the mobile app has their mobile app permission removed (via ‘Admin’, ‘User Admin’), their app will
deactivate itself and receive no further data.
Please note, LDAP users must have their app permissions explicitly revoked on the “Permissions” page. Removing the
permission from an LDAP group on Group Admin is not sufficient.
Upgrading Darktrace Models

When do Models Auto-Update?
When a software upgrade bundle is applied, any changes to Darktrace models (such as new or updated models) will also be
performed. Where software upgrades are set to pre-cache, model updates will be pushed to the User Interface for automatic
update or approval even if the full software bundle is not yet applied.
Separate to this software upgrade process, updates to Darktrace models are delivered on a regular basis to the Threat
Visualizer when Call-Home is enabled.
Darktrace Threat Visualizer v5 introduced Model Defeats. These are lines of logic that can be added to change whether
the model breaches, but that do not affect whether it is updated or not. Changes to other parts of the model logic will still
affect the model’s auto-update status.
Whether a model is updated automatically or not is decided by the following:
Auto-Updating Models

page under Admin on the main menu. If not already selected,
choose Settings from the left-hand menu.
2. Locate the “Models” section and confirm that Auto Update

Models is enabled.
3. Additionally, confirm the setting for Maintain Tags With Update.
When enabled, any tags added to the model will be preserved

when auto-updating, a useful setting if models have been
mapped to specific use-cases or an existing playbook.
When disabled, any tags on a model will be overwritten during

an auto-update.
4. Edit any Model in the Threat Visualizer and confirm that the
Auto Update setting is enabled.
When enabled, this model will automatically upgrade to the

latest version when its released.
Applying Pending Model updates
1. If models are not updated automatically due to any of the

conditions listed above, a message will appear on the home
page of the Threat Visualizer stating ‘x’ number of model
updates are available and require review.
Clicking this blue notification will redirect the user to the Model
Updates page. The Model Updates page can be accessed
at any time from the main menu under Models.
Any new models created or duplicated will not be impacted

by automatic updates
2. The Models Updates page lists all Models which have been
customized but have new updates available.
Click on a Model row to reveal more options.
3. For each model, each revision will appear as a separate line

with a short description of the changes and options to Accept,
Decline or View them.
The Active model is the current version active on your

deployment.
Clicking the View button will display the current Model settings
with the option to view the new upgrade.
Click View Upgrade to see the newest version of the model.

You may Ignore or Accept the changes.
Accepting the changes will permanently update the Model.

Be careful not to overwrite any changes.
If you wish to preserve your changes to a model but are concerned about delaying any important updates, one method is
to duplicate the model and then upgrade the original. The duplicated model will retain the original logic with your changes
and can be revised to match the upgraded version at your convenience.
Appliance Console Guide

When a successful console login has been performed, the user will be presented with the main menu. The console can
be navigated using the tab and arrow keys. Pressing enter while the ‘OK’ is highlighted will enter the selected submenu or
action. Pressing enter while the ‘Cancel’ is highlighted will exit to the previous menu or exit the console application. User
input may be freely typed.
The appliance console contains the following sections:
Networking and Traffic Analysis
1. Configure network interfaces
Allows the user to configure the basic IPv4 network addressing for the admin interfaces and edit settings for the
analysis interfaces. For entries requiring multiple values (such as DNS servers), each entry must be space separated.
It is strongly advised that a Darktrace appliance is set with a static IP. If your environment requires the appliance to
have DHCP addressing, please ensure a static reservation is set within your DHCP scope.
2. Count active devices
This allows a console user to ascertain how many active devices are currently being modeled by Darktrace, without
using the Threat Visualizer web interface or API. This count includes devices seen in network traffic and created by
any additional modules such as Security Modules or the TSA.
3. Interface stats
Interface stats will display the approximate bandwidth utilization of each connected interface.
4. NTP Settings
This option permits the user to view and amend the current NTP servers. It is important that the Darktrace appliance
maintains a synchronized time source, so this must be configured. NTP settings can also be accessed from the
Management Interface when in the Configure network interfaces menu.
Software updates
Please refer to Types of Darktrace Upgrade Bundles and Downloading Update Bundles for the Threat Visualizer for more
information about upgrading the Darktrace Appliance.
1. Guided Mode
Please refer to Downloading Update Bundles and Performing a Guided Upgrade for details about the options within
the submenu.
2. Manual Mode
Please refer to Downloading Update Bundles and Performing a Manual Upgrade for details about the options within
the submenu.
Appliance Admin
1. Topology settings
A Darktrace appliance may be configured as a master (the default) or a probe (optional).
Entering into Topology Settings on a probe will permit you to specify a Darktrace master into which the probe will
forward captured network metadata and test the connection to the specified Darktrace master.
1. Convert to Probe allows the appliance (if a master) to be converted into a Darktrace probe. Conversion
from a master into a probe is a one-way conversion and is irreversible. Please refer to Configuring an Appliance
as a Probe for more details.
2. Dedicated master allows the appliance to be set up as a dedicated master for unified view environments.
3. Setup Unified View allows the appliance to be converted to a role in a Unified View deployment. This
setting should not be used without guidance from your Darktrace representative or Darktrace support.
2. Call-Home menu
The Call-Home settings (disabled by default) permit the user to enable or disable the Call-Home feature. This may
be used for remote analytical and/or maintenance work. Please note that the device’s ability to do this depends on
a previously agreed arrangement with Darktrace. Please contact your Darktrace representative for more information.
1. About Call-Home describes the service.
2. Call-Home status checks the current status. If this reports ‘Disabled’, the Call-Home service will not start
automatically on appliance boot. If this reports ‘Enabled’, this service will be started automatically.
All lines should show ‘OK’ if the connection has initialized correctly.
3. Enable/Disable Call-Home will toggle the service on and off. Disabling Call-Home will also ensure the
service does not automatically start on boot.
4. Call-Home configuration shows the current Call-Home settings that are configured.
5. Clear Call-Home cache is a troubleshooting step that should only be used as instructed by Darktrace support.
6. Call-Home partner connection will set up Call-Home to a third-party partner, for example a managed
service provider. This feature is designed for use by Darktrace certified partners and should not be attempted
without their guidance.
7. Upgrade Call-Home connection should only be used when instructed by a member of Darktrace Support
as part of troubleshooting connection issues.
8. Select Call-Home destination is an advanced option which should only be used under guidance from
Darktrace Support.
3. Antigena Network
1. Enable/disable Antigena Networking changes whether Antigena Network is enabled within the console.
The setting is enabled by default. Please see Enabling Antigena Network and Manually Re-enabling Antigena
Network for more details on configuring Antigena Network
2. Set outward network interfaces allows you to change the firing interfaces used for Antigena Network. A
guide to using this setting can be found in Antigena Network and Dedicated Firing Interfaces.
4. Industrial Immune System
An Enterprise Immune System appliance can be converted to Industrial mode (additional protocol analysis, device
types, industrial-specific models) using this option and a code from Darktrace support.
5. Configure host variables
Please refer to Host Variables in the Appliance Console more information about changing host variables.
6. Configure SNMP
Please refer to the documentation on High Availability Mode for information on configuring SNMP monitoring.
7. Endace API
Allows PCAPs to be stored on an Endace Probe. For more information about Darktrace integration with Endace, please
ask your Darktrace representative.
8. Advanced Search Export
Please see Advanced Search Export Formats for details on how to configure Advanced Search exports.
9. Mobile App
If you are experiencing issues configuring the Darktrace Mobile App Service, Darktrace support may use this alternative
method to launch the service.
10. Change console/transfer password
The password for the console and transfer users is limited to the characters a-z, A-,Z and 0-9 and must be a minimum
of 9 characters. For security, the password text is not displayed in the password input field. The user must repeat the
password to ensure it is entered correctly, and the new password will be valid upon the next login session.
11. Clear UI SSL certificate
If the installed certificate is blocking access to the UI, the certificate can be removed by the user to restore access.
12. Antigena Email Configuration
This dialog is used to configure the local IP address of an on-premises Antigena Email Appliance in order to facilitate
communication and UI access.
13. Reset appliance menu
Please refer to Securely Erasing Captured Data and Restoring the Darktrace Appliance to Factory Settings for more
information on using this submenu.
Backup and Restore
1. Backup locally now
Please see Creating an Immediate Backup for more details.
2. Scheduled backup configuration
Please see Configuring a Scheduled Backup via SCP, Configuring a Scheduled Backup via SMB or Configuring a
Scheduled Backup via S3.
3. Test backup transfer
This option tests the current scheduled backup configuration by placing a file of negligible size on the backup server.
4. Generate/regenerate SCP transfer keys
The transfer key used for SCP backups can be regenerated using this option.
5. Restore from backups
Please see Restore from a Backup for more details.
6. Configure email alerts
Please see Setting up Email alerts for Scheduled Backup Status for more details.
Power and Service Management
1. Service status
This option will perform a basic check of all core services on the appliance. All services should report ‘OK’ or ‘UNTRAINED’,
otherwise errors may be encountered during Darktrace operations.
2. Restart all services
Selecting restart all services will cause all core services to restart. For appliances in a production environment, this
may take some time. If the appliance is actively analyzing data, some data capture may be lost while the services are
being restarted.
3. Restart Mobile App Backend
If you are experiencing issues with the Darktrace Mobile App Service, Darktrace support may use this option to restart
the service.
4. Create Darktrace debug file
Selecting this option will cause the appliance to generate a snapshot of debugging information that can be submitted
to Darktrace for analysis. When generated it will be available for download from the appliance through an SFTP session
initiated by the transfer user.
5. Reboot
Immediately issue a restart to the Darktrace appliance. This will safely stop all services and the device will restart.
6. Shutdown
Immediately issue a shutdown command to the Darktrace appliance. This will safely stop all services and the device
will power down. The appliance will need to be manually powered on for it to resume services.
Advanced Search Export Formats

Advanced Search logs can be automatically exported from the Darktrace appliance to external log storage. The export is
performed at the stage between Deep Packet Inspection and data insert into Advanced Search, so logs will only be exported
from the point of configuration onward and will not include system notices.
Export must be configured on every master and probe appliance desired for logging; each appliance can export logs to a
different external location. Data from vSensors is not currently supported.
The following exports can be configured in the appliance console:
Ǔ Elasticsearch v.6 and v.7

Ǔ TCP JSON format (suitable for SIEMs or Splunk environments)
HTTP and Kafka exports can be configured by a member of Darktrace support. Please contact your Darktrace representative
to request one of these additional export formats.
Requirements
Ǔ A Darktrace Appliance running software version 4.0 and above.

Ǔ A configured elasticsearch cluster or external log server (like Splunk) which supports JSON format exports.
Ǔ If necessary, a relevant firewall exception configured to allow the Darktrace appliance to connect to the external log location.
Advanced Search Export Filters
An optional filter can be applied to Advanced Search logs to reduce the volume of messages sent to the external log server.
This may be desirable if some types of traffic are already being ingested from other locations (such as VPN logs or DNS
queries) to prevent duplication, or if there are concerns about storage and ingestion costs.
Configuring a filter can be tricky, so the following examples should be followed closely.
Supported Syntax
Each field can be filtered on with Fields[<fieldname>]. Single quotes (’) should be used for variable names. For example,
Fields[@type] == 'conn'
Regular expressions must be enclosed by forward slashes:
Fields[dest_ip] !~ /^192\.168\.10\./ && Fields[dest_ip] !~ /^10\./
When specifying a value, the type of data matters. The filter Fields[dest_port] != '53' will not work because the data
type is numeric. The filter Fields[dest_port] != 53 , however, will work.
Relational Operators Logical Operators Special
Ǔ == equals Ǔ ( ) Pa r e n t h e s e s f o r g r o u p i n g Ǔ TRUE
Ǔ != does not equal expressions Ǔ FALSE
Ǔ > greater than Ǔ && AND (higher precedence) Ǔ NIL - used to test the existence (!=)
Ǔ >= greater than or equal to Ǔ || OR or nonexistence (==) of a field variable
Ǔ < less than
Ǔ <= less than or equals
Ǔ =~ regular expression match
Ǔ !~ regular expression negated match
Additional Examples
Fields[@type] == 'conn' || Fields[@type] == 'conn_long'
Fields[dest_port] != NIL
Fields[source_ip] =~ /^10\./ && Fields[dest_port] != 53 && Fields[@type] != 'ssl'

Configuring Advanced Search Export for Elasticsearch

Please ensure you have read through the requirements and filter syntax in Advanced Search Export Formats before
configuring the export.
1. In the appliance console, navigate to Appliance Admin then

select Advanced Search export.
2. Select Configure export to elasticsearch from the options.
3. On the first screen, you will be prompted to enter the destination

of the elasticsearch cluster where the logs will be exported to.
A hostname or IP address must be specified with a destination
port in the format http://destination:port or https://
destination:port. For example: http://10.0.0.1:9200 or
https://cluster4.elasticsearch.domain:9200
Please note, for HTTPS connections encryption is supported

but certificate validation will not be performed.
Mapping files for elasticsearch version 6 and 7 will be placed

in the transfer directory of the Darktrace appliance; please
retrieve the mapping file for the relevant version. The mapping
template assumes that the default index name will be used for
exported logs. If you plan to use a custom index name, please
adjust the mapping template appropriately.
4. The TCP connection to the elasticsearch cluster will now be

tested. Please ensure that any necessary firewall exceptions
have been made to allow communication from the Darktrace
appliance to the cluster location.
If the connection fails, you may proceed with configuration

but connectivity issues must be resolved before logs can be
exported successfully.
5. HTTP basic authentication is available and can be configured

in this step; Darktrace strongly recommends using basic
authentication for best security practices.
If ‘Yes’ is selected, a username and password prompt will appear.

Please enter valid credentials for a user with permission to
index data in the elasticsearch cluster. The password must not
contain double quote characters (").
6. A custom index pattern can be used for log files; all patterns
will be suffixed with the date in the format YYYY.MM.DD. For
example, the pattern darktrace-123- will be indexed as
darktrace-123-2020.05.28.
Index patterns must be lowercase only, a maximum of 245

characters, must not begin with _, -, or + and must not contain
the following special characters: # / \ * ? " > < | ,.
A blank index pattern will default to “darktrace-[hostname]-”
7. A filter may also be applied to outgoing logs to limit the types

of data exported.
If you wish to configure a filter, please see Advanced Search

Export Formats for more details of the supported syntax.
Leave the field blank if you do not want to apply a filter.
8. A prompt will appear, confirm you have imported the mapping

file provided earlier into your elasticsearch cluster and made
any necessary changes to the default index specified in the file.
Select ‘OK’ to confirm the file has been imported and proceed
to apply the changes. Configuration will now be applied.
Advanced Search export can be removed by re-attempting the configuration process and providing a blank value in the
hostname field of the first prompt.
Configuring Advanced Search Export for TCP

Please ensure you have read through the requirements and filter syntax in Advanced Search Export Formats before
configuring the export.
1. In the appliance console, navigate to Appliance Admin then

select Advanced Search export.
2. Select Configure TCP JSON export from the options.
3. On the first screen, you will be prompted to enter the destination

of the server where the logs will be exported to. A hostname
or IP address must be specified with a destination port in the
format destination:port.
For example: 10.0.0.1:8000 or splunk.corp.domain.8080
4. The TCP connection to the external server will now be tested.

Please ensure that any necessary firewall exceptions have been
made to allow communication from the Darktrace appliance
to the location.
If the connection fails, you may proceed with configuration

but connectivity issues must be resolved before logs can be
exported successfully.
5. TLS is available and can be configured in this step; Darktrace

strongly recommends using TLS for the connection in line with
best security practices.
Please note, encryption is supported but certificate validation

will not be performed.
6. A filter may be applied to outgoing logs to limit the types of

data exported.
If you wish to configure a filter, please see Advanced Search

Export Formats for more details of the supported syntax.
Leave the field blank if you do not want to apply a filter.
7. After the optional filter has been configured, select ‘OK’ to

proceed to apply the changes.
Configuration will now be applied.
Advanced Search export can be removed by re-attempting the configuration process and providing a blank value in the
hostname field of the first prompt.
Host Variables in the Appliance Console

Host Variables
Darktrace provides several custom configuration options which may be appropriate for your environment. These configuration
options are accessed via the console and will help to access, use and administer the appliance and ensure any internal
policies are adhered to.
The available host variables may change from version to version, dependent on requirements. Each option is described in
detail when selected from the console menu.
HOST VARIABLE DESCRIPTION
Configures the SSH server to use a highly compatible set of ciphers. Disabling
1. Use highly compatible ssh ciphers
this option increases the security of the SSH server.
2. HTTPS: Disable SHA1 ciphers and TLS Enabling this option restricts the cipher suite in use by the HTTPS server and
protocols < 1.2 disables TLS protocols other than TLS v1.2.
Sets the number of minutes after which UI sessions are logged out due to
3. UI session expiry length
inactivity.
Enabling this option requires that all users of the Threat Visualizer provide a
second credential to access the user interface. Two-factor authentication be
4. Enforce two factor authentication individually enabled for specific users in the User Administration page on the
Threat Visualizer User Interface. Once enabled, this setting cannot be globally
disabled.
This option sets the maximum transaction unit (MTU) size that can be
5. Set MTU Configuration
communicated over the network.
Enabling this option applies the kernel patch to mitigate the Meltdown
6. CVE-2017-5754 Intel “Meltdown” patch vulnerability (Kernel page table isolation). A reboot is required for changes to
take effect.
Sets the Terminal Services Agent (TSA) to post data to the appliance on port
7. Set alternative TSA port
1443.
8. Block Darktrace user from generating
Restricts the ability to generate PCAPs for the Darktrace user.
PCAPs
Changes the encoding for DHCP hostnames. The Windows DHCP client
transfers computer hostnames using the system encoding. Organizations with
9. Set DHCP hostname encoding
Windows machines configured to use non-ascii charactersets by default may
wish to change this setting.
Automatically generate an Executive Threat Report every Sunday at midnight
10. Generate weekly Executive Threat
UTC, unless day and hour are set. Please note, this feature will not run on
Report
probes or individual masters underneath a Unified View instance.
11. Day for Weekly Executive Threat Allows an alternative day to be set for weekly Executive Threat Report
Report generation. By default, reports are generated on Sunday.
12. Hour for Weekly Executive Threat Allows an alternative hour (UTC only) to be set for weekly Executive Threat
Report Report generation. By default, reports are generated at midnight UTC.
Enabling this option will allow Darktrace support to acquire additional
13. Test Antigena Network reachability diagnostic information about Antigena Network reachability within your
network.
Enforces FIPS 140-2 encryption on inbound HTTPS connections. When
14. FIPS 140-2 cryptographic compliance enabled on both Master and Probe, probes will only accept FIPS valid ciphers
in inbound connections from the Master.
Checksum validation is performed within the DPI engine to filter out invalid
15. DPI engine protocol checksum packets that would not typically be accepted by network interfaces. This host
validation variable allows validation to be disabled if invalid checksums are expected
within traffic.
HOST VARIABLE DESCRIPTION
When enabled, packet ingestion interfaces will be polled at a higher

16. Low latency interfaces frequency to prevent packet misordering when network TAPs send RX and TX
packets to different interface ports.
Disables the ports used for syslog ingestion at the firewall level. Please see
17. Block log input ports
Configuring a Syslog Input for more details on syslog ingestion.
Darktrace ingests syslog on a number of pre-set ports; where a syslog-
emitting component only permits logs to be sent to port 514 on the receiver,
18. Log Input on port 514 this host variable allows Darktrace to ingest syslog on port 514 and forwarded
internally to the selected port. Please see Configuring a Syslog Input for more
details on syslog ingestion.
Modifying Host Variables
1. Login to the console menu and select Appliance Admin.
Select option Configure host variables.
2. The Host variables menu shows all the currently available

configuration options.
Select a desired variable.
3. After selecting an option, an explanation of the setting will

be displayed.
For the majority, pressing the space bar will toggle the setting
on or off. On is indicated by an asterisk [*].
Variables which require a value will allow for text entry.

Creating an Immediate Backup

Backups
The Darktrace Threat Visualizer console includes configuration options to take an encrypted backup of your Darktrace
appliances. A backup includes all Darktrace machine learning, models, breaches, as well as subnet and device information,
and configuration settings on the Threat Visualizer GUI. It does not include transactional data such as connections in the
Event Log, Advanced Search entries and PCAP files, nor configuration settings on the console menu.
A backup will take approximately 2GB of storage space, although actual size may vary, and can be created either manually
or automatically on a daily schedule. By default, only the latest three backups will be retained. If a new backup file is created
on top of the previously existing three backups, the most outdated one will be removed automatically.
In networks with Probe and Master appliances, only the Master appliance needs to be backed up. In Unified View deployments,
or if more than one Master is being used, make sure to back up all Masters.
Create an Immediate Backup
A backup file can be manually created through the appliance console and accessed via SFTP by the transfer user.
1. On a Master appliance, login to the console menu and select

Backup and Restore.
2. A range of backup options are available.
Select Backup locally now.
3. A message will appear stating that Darktrace appliances can

only be restored from a backup of the same software version.
Select Yes to proceed.
4. The Backup file is created in the /files directory.
This directory can be accessed by the transfer user via SFTP.
Clear Transfer File Directory
Through the appliance console it is possible to clear the transfer file directory. To do this, select Appliance Admin, then
Reset Appliance Menu and finally Purge Transfer File Directory.
Configuring a Scheduled Backup via SCP

Scheduled Backups
The Darktrace Threat Visualizer application includes configuration options to backup your Darktrace appliances. A backup
includes all Darktrace machine learning, models, breaches, as well as subnet and device information, and configuration
settings on the Threat Visualizer GUI. It does not include transactional data such as connections in the Event Log, Advanced
Search entries and PCAP files, nor configuration settings on the console menu.
or if more than Master is being used, make sure to back up all Masters.
Backups via SCP
Backups can be automatically created on a daily basis and passed to a specified remote server via SCP, SMB or S3. This
guide will cover backups over SCP.

Backup and Restore.
2. A range of backup options are available. Select Scheduled

backup configuration.
3. When accessing this feature for the first time, a prompt may
appear stating “Backup configuration not set”. Confirm OK
to proceed.
The next screen will ask if you wish to change the configuration
at this time. Select Yes to proceed.
4. Choose a protocol over which to transfer backups.
Select scp. Selecting none disables scheduled backups.
5. Enter the IP address or hostname of the remote server

intended to receive the backup files and proceed.
6. Enter a port on the backup server and confirm.
7. Enter a user to authenticate against for the server and confirm.
The username may contain alphanumeric or specific special

(_,.or-) characters. The first character must be alphabetical
or _. Dollar characters ($) are not permitted.
8. Enter a path on the server where the backup will be sent

and confirm.
9. Enter the hour, minute and second in UTC for the backup
and confirm.
10. Select whether the backup should be performed daily or every

week at the specified time.
11. Confirm your configuration options and select Yes to proceed.
Please note, the public key is generated in the /files directory,

which can be accessed by the transfer user via SFTP.
This key must be added to the .ssh/authorized_keys file

for the configured user on the remote backup server.
The key can also be regenerated from Generate/regenerate

scp transfer key under the Backup and Restore submenu.
12. Optionally test the configuration.
Configuration can be tested at any time from Test backup

transfer under the Backup and Restore submenu.
Configuring a Scheduled Backup via SMB

Scheduled Backups
Backups via SMB
guide will cover backups over SMB.

Backup and Restore.
2. A range of backup options are available. Select Scheduled

backup configuration.
appear stating “Backup configuration not set”". Confirm OK
to proceed.
Select SMB. Selecting none disables scheduled backups.
5. Enter the IP address or hostname of the remote server

intended to receive the backup files and proceed.
6. Enter the name of the share on the SMB server and confirm.
Dollar characters ($) are not permitted within this value.
7. Enter a user to authenticate against for the server and confirm.
The username may contain alphanumeric or specific special

(_,.or-) characters. The first character must be alphabetical
or _. Dollar characters ($) are not permitted.
8. Set the domain or workgroup that this user is a member of

and confirm.
9. Set a password for the user for authentication and confirm.
10. Set the path on the server where the backup will be sent
and confirm.
11. Select the maximum SMB version - SMB1, SMB2 and SMB3
are supported. The use of SMB3 is recommended.
and confirm.

15. Optionally test the configuration.
Configuration can be tested at any time using Test backup

Configuring a Scheduled Backup via S3

Scheduled Backups
Backups via S3
guide will cover backups to S3 compatible services.

Backup and Restore.
2. A range of backup options are available.
Select Scheduled backup configuration.
appear stating “Backup configuration not set”. Confirm OK
to proceed.
Select S3. Selecting none disables scheduled backups.
5. Enter the URL of the S3-compatible service intended to receive

the backup files and proceed.
Do not include the bucket name in the URL.

6. Enter a bucket name where the backups should be stored.
7. Authentication details for S3 must now be entered. These

can be entered manually or uploaded in a compatible file by
the transfer user.
To upload authentication details select “SFTP upload…” and

then proceed to step 8.
To manually enter the details, select “Enter details manually…”

and skip to step 9 below.
8. To load S3 authentication details from a file, create a plain text

file with the Access Key and Secret Key in the format:
ACCESS_KEY=key
SECRET_KEY=key
Upload this file using the transfer user into the files/
upload directory. Proceed when the file is uploaded and load
the authentication details.
Proceed to step 11 below.
9. To manually enter S3 authentication details, enter the S3

Access Key and proceed.
10. Enter the Secret Key into the prompt and proceed.
11. If a proxy is required to access the S3 service, enter the details

in the format described in the prompt.
Leave the field blank if no proxy is required.

12. Optionally add a prefix to specify the backup location within

the bucket.
If the backups are to be stored at the top level of the bucket,

leave this field blank.
and confirm.

Optionally test the configuration.
Configuration can be tested at any time from Test backup

Minimum IAM Policy for S3 Backups

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListObjectsInBucket",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::[BUCKETNAME]"
]
},
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::[BUCKET_NAME]/*"
]
}
]
}
Where [BUCKET_NAME] should be replaced with the name of the S3 bucket.

For the second part of the policy (GetObject/PutObject), /* can be replaced with your configured key prefix. For example:
...
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::[BUCKET_NAME]/darktrace/backups/*"
]
}
]
}
Encryption
Encryption on the target S3 bucket is supported with both SSE-S3 and SSE-KMS:
Ǔ No IAM policy changes are required for SSE-S3 as encryption is managed directly by AWS
Ǔ No IAM policy changes are required for SSE-KMS if encryption is configured with an AWS managed key (“AWS KMS key”
> “AWS managed key (aws/s3)”)
Ǔ IAM Policy changes are required for SSE-KMS if a customer managed key (CMK) is desired.
For CMK encryption with SSE-KMS, the key type should be symmetric and should be located in the same region as the
S3 bucket. The IAM user policy must allow the IAM user to utilize the key or tests (and backups) will fail due to “Insufficient
permissions”. More information can be found in the relevant AWS documentation.
Example policy for CMK Encryption

{
"Version": "2012-10-17",
"Id": "key-consolepolicy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[ACCOUNT-NUMBER]:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through S3 for all principals in the account that are author-
ized to use S3",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "s3.[BUCKET_REGION].amazonaws.com",
"kms:CallerAccount": "[ACCOUNT_NUMBER]"
}
}
},
{
"Sid": "Allow direct access to key metadata to the account",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[ACCOUNT_NUMBER]:root"
},
"Action": [
"kms:Describe*",
"kms:Get*",
"kms:List*"
],
"Resource": "*"
}
]
}
Where [BUCKET_REGION] and [ACCOUNT_NUMBER] are placeholder values to be replaced.

Setting Up Email Alerts for Scheduled Backup Status

The Darktrace Threat Visualizer application includes configuration options to backup your Darktrace appliances. Darktrace
provides the option to receive email notifications about the success or failure of daily scheduled backups. Scheduled backups
must already be configured for email notifications to be set.
Configuring Email Notifications

Backup and Restore.
Under the Backup and Restore submenu, select Configure

email alerts.
2. A prompt will describe scheduled backup notifications.
Select OK to proceed.
3. A further prompt will ask whether you wish to enable

notifications. Choose Yes to configure email alerts.
4. By default, email notifications are sent when a backup fails.
Optionally, notifications can be sent when a backup is successful.

Select your preferred configuration option and proceed.
5. Enter an email address to receive notifications.
6. Enter an email address to send notifications from (optional).
7. Enter the hostname or IP address of an SMTP server to send

emails via.
8. Select a port for SMTP.
9. Choose whether STARTTLS is to be used.
10. Enter a username to configure SMTP authentication.
11. Enter the password of this user.
12. Confirm the configuration and select Yes to proceed.
13. Optionally send a test email to confirm the configuration process

was successful.
Restore from a Backup

The option to restore from a backup is available in the console menu. Transactional data such as connections in the Event
Log, Advanced Search entries, and PCAP files are not restored. Before restoring from a backup, check the following:
Ǔ Upload the backup file to /files/upload in the transfer user directory via SFTP.
Ǔ Confirm the appliance is running the same software version as the backup file, otherwise the restore cannot be performed.
How to Restore
1. On the Master appliance intended for restore, login to the

console menu, and select Backup and Restore.
2. Select Restore from backup.
3. A prompt will appear to warn that a backup must be present

before a restoration can occur.
Select OK to continue.
4. Select a backup to restore from the list.
5. A prompt will request confirmation for the chosen backup.
If this is the correct backup, proceed with the restoration.
6. Please wait for the restoration to complete.
Larger backup files will take longer to restore from.
7. A restore completed successfully message will confirm

restoration was successful.
Types of Darktrace Upgrade Bundles

Darktrace Upgrade Bundles
This article describes the different types of Darktrace Threat Visualizer upgrade bundles available for download. There are
two types of software bundle available, full and differential. Full packages contain the entirety of the Darktrace software
needed to upgrade an appliance to the newest version and consequently are larger files. Differential packages are much
smaller upgrade bundles and only contain the necessary content to upgrade from the version specified in the file name.
Understanding the difference will ensure you download the correct package for your needs.
Full package
A full package can be applied to upgrade an appliance running any older version of the Darktrace software. These software
bundles follow the naming syntax:
darktrace-bundle-[upgrade version]_[release date]-[alphanumeric]-x.dat
Example: darktrace-bundle-31007_20181217T1457Z-983d8-x.dat
Differential package
Differential packages are much smaller files than full packages. Unlike full packages, differential packages can only upgrade
appliances running the specific software versions named in the package file name. Differential packages come in two types,
delta and xdelta.
Delta Packages
Delta packages can be applied to any software version newer than the version specified in the filename. These software
bundles follow the naming syntax:
darktrace-bundle-[upgrade version]-delta[oldest version]_[release date]-[alphanumeric]-x.dat
Example: darktrace-bundle-31007-delta30911_20181217T1457Z-983d8-x.dat
In this example, any appliance running the oldest version (30911) or newer can be upgraded with this bundle.
Xdelta Packages
Xdelta packages can only be applied to the specific software version included in the filename. These software bundles
follow the naming syntax:
darktrace-bundle-[upgrade version]-xdelta[specific old version]_[release date]-[alphanumeric]-x.dat
Example: darktrace-bundle-30811-xdelta30801_20180726T1426Z-5c186-x.dat
In this example, only an appliance running the specific version (30801) can be upgraded with this bundle.
Downloading Update Bundles

Upgrade Methods
This article describes the different methods for downloading Darktrace Threat Visualizer upgrade bundles. Please review
Types of Darktrace Upgrade Bundles to ensure you select the correct package for your environment.
Software upgrade bundle files can be obtained via automatic download, manual download or from the Darktrace Customer
portal.
Automatic download
A differential package file is automatically downloaded every weekend (if available) when automatic downloads are configured.
To check the current settings, access the console and navigate to Software Updates > Guided mode > Configure downloads.
To disable all automatic downloads, select None (disable guided updates) under the appropriate submenu.
Ǔ Automatic download via Call-Home: Update bundle files are downloaded via Call-Home. (Call-Home must be established
to select this). This is enabled by default.
Ǔ Automatic download over the internet: Alongside the Call-Home SSH connection, Darktrace provides another channel
for appliances to automatically download bundle files over the internet via HTTPS.
The appliance requires port 443 access to either packages.darktrace.com, or if preferred, the Cloudfront CDN at
packages-cdn.darktrace.com. A proxy can be configured if required. This method requires a bundle key which can be
requested from Darktrace Support.
Manual Download
All current software bundles can be found on the Darktrace Customer Portal. A manual update check can also be performed
from the appliance console.
Ǔ Manual download via Call-Home: The latest differential package can be downloaded via the console menu. Navigate to
Software Updates > Guided mode > Check for updates now
Ǔ Manual Download via Customer Portal: The latest bundle file is available in the Customer Portal. Download the file from
the website and copy it to the appliance intended for upgrade via SFTP using the transfer user.
Performing a Guided Upgrade

This section describes the process for initiating a manual upgrade for the software version running on a Darktrace appliance.
When Call-Home is enabled, all Master appliances will automatically be upgraded by Darktrace to the latest release, unless the
‘Upgrade requires approval’ has been selected. In such case, or when Call-Home is not enabled, a manual upgrade is required.
As a Darktrace installation may involve multiple appliances, it is important all appliances are upgraded to the same version.
Upgrading an appliance will not change any previous settings or overwrite any model breaches currently stored in the
application.
Upgrade procedure
1. On the appliance intended for upgrade, login to the console

menu and select Software Updates.
2. Two options are available, Guided mode and Manual mode.
Select Guided Mode.
3. Review the options available on the Guided mode menu:
[1] Check for updates now: Checks if there are any new
available updates. If an update is available it will download
and proceed to unpack and install it, prompting before each
step begins.
[2] Unpack and Install updates: runs through the update

process, asking for confirmation before each step.
[3] Configure download: provides configuration settings for

fetching the latest upgrade bundles. Please see ‘Downloading
Bundle Files’ above for further information.
Select Check for Updates Now. The appliance will locate any
available updates and proceed through the upgrade process.
Performing a Manual Upgrade

This section describes the process for manual upgrades for the software version running on a Darktrace appliance. When
“Call-Home” is enabled, all Master appliances will automatically be upgraded by Darktrace to the latest release, unless the
‘Upgrade requires approval’ has been selected. In such case, or when Call-Home is not enabled, a manual upgrade is required.
Upgrading to the latest version of the Threat Visualizer application is quick and easy. Review the summary of the following steps:
1. Download the latest bundle.
2. Copy the bundle to all Darktrace Appliances.
3. In the Darktrace console, unpack the bundle.
4. Install the latest Threat Visualizer version.
5. Log in to the Threat Visualizer application and confirm the latest version is installed.
As a Darktrace installation may involve multiple appliances, it is important all appliances are upgraded to the same version.
Upgrading an appliance will not change any previous settings or overwrite any model breaches currently stored in the
application.
Upgrade procedure
Please ensure that your upgrade bundle file is placed on the appliance before the upgrade process. If you downloaded a
bundle from the Customer Portal, login to your appliance as the transfer user via SFTP, and upload your upgrade bundle
file to the /files/upload directory.
1. On the appliance intended for upgrade, login to the console

menu and select Software Updates.
2. Two options are available, Guided mode and Manual mode.
Select Manual mode.
3. Manual mode requires further configuration steps to unpack

the downloaded bundle and before installation.
In the Manual Mode submenu, select Unpack uploaded update

bundle.
4. A list of available bundles stored on the appliance will appear.
Select the newest bundle to install. The latest bundle is always

at the bottom of the list.
Press OK to continue.
5. A prompt will ask if you wish to unpack the specified bundle.

Confirm and proceed.
It may take some time for the unpacking operation to complete.
6. Once unpacked, the console will return to the Manual mode

submenu.
Select Apply update/configuration changes.
7. A confirmation warning will appear. Proceed with the update.
If an error occurs, please try applying the latest changes a

second time. If the error persists, please contact Darktrace
Support.
8. A further warning will appear. Upgrading a Darktrace appliance

without confirmation from Darktrace support may affect your
Service Level Agreement.
Confirm your understanding and proceed.
9. A final warning will explain that all capture services will be

restarted on upgrade.
Confirm and proceed.
10. The update process will begin.
When finished, press OK to complete the upgrade.
11. Optionally check the status of the services. Select Yes if you
wish to do so. After the status check you will be logged out
of the console. No will log you out of the console immediately.
Login to the console menu again to confirm that the software
version has updated.
Securely Erasing Captured Data

Data Erasure
Data erasure is useful when relocating a Darktrace appliance and/or changing its monitoring scope, to start initial deployment
‘baselining’ afresh, or if data needs to be wiped before returning an appliance to Darktrace.
There are two options for data erasure, captured data deletion or a factory reset. Both data erasure processes above can
be performed onsite, provided access to a Darktrace appliance is available. Neither processes will affect the appliance
Operating System or any Darktrace proprietary software.
The ‘delete captured data’ option will include, but may not be limited to, the following data sets: topology settings (connected
probes and their IP addresses), hostnames and popularity (rare hostnames etc.), environmental details (proxies, domains etc.),
all modeled devices, breaches and partial breaches, device connectivity states, and backups.
Darktrace will also fully erase any information on all storage drives for new or returned appliances.
How to Delete Capture Data
Captured data is erased through the console application. This process will also require an unlock code to be provided by
a Darktrace representative, and exchanged via a secure channel such as text message or the Darktrace Customer Portal.
1. Access the appliance console. From the main menu, select

Appliance Admin, then Reset appliance.
2. Select Delete capture data and choose OK.
3. A prompt will appear with a warning message.
Confirm Yes if you wish to proceed.
No will cancel the process and no changes will be made.
4. Another warning prompt will require that you reconfirm your

decision to reset captured data.
Select Yes again to confirm your choice.

5. A further screen will ask if you wish to disable capture interfaces

before proceeding.
Yes will disable capture interfaces, meaning that no further

data can be ingested even after the appliance completes its
reset regardless of if cables have been removed. Capture
Interfaces should not be disabled if you wish to continue to
use the appliance after reset; only Darktrace Support can
re-enable them.
Selecting No means the appliance will begin ingesting data

again through any connected capture interfaces on completion
of the reset.
6. The appliance will now request a reset unlock code. Enter the
unlock code provided by Darktrace and confirm.
7. The Device successfully reset message confirms the erasure

process was successful
Press OK.
Restoring the Darktrace Appliance to Factory Settings

Data Erasure
There are two options for data erasure, captured data deletion or a factory reset. Both data erasure processes above can
be performed onsite, provided access to a Darktrace appliance is available. Neither processes will affect the appliance
Operating System or any Darktrace proprietary software.
A factory reset will write zeros to all disks and reinstall the operating system and Darktrace software components, rendering
the appliance in an as-new state.
Darktrace will also fully erase any information on all storage drives for new or returned appliances.
How to Restore to Factory Settings
A factory reset is performed through the Appliance console and is the most stringent data erasure method available. A
factory reset will write zeros to all disks, reinstall the operating system and all Darktrace software components to return the
Appliance to an as-new state. Consequently, this process will take considerably longer than the standard Delete function and
requires a reset code provided by a Darktrace representative and exchanged via a secure channel (such as text message
or the Darktrace Customer Portal).
Before proceeding with a factory reset, unplug all analysis port cables (management and RMM cables can remain plugged in).
1. Access the appliance console. From the main menu, select

Appliance Admin, then Reset appliance.
2. Select Factory reset and select OK.
3. A prompt will appear with a warning message.
Confirm Yes; if you wish to proceed.
No will cancel the process and no changes will be made.
4. Another warning prompt will require that you reconfirm your

decision to restore the appliance to factory settings.
Select Yes again to confirm your choice.

5. The appliance will now request a reset unlock code.
Enter the factory reset unlock code provided by Darktrace

and confirm OK.
6. During the first part of the process, the following message will
appear on the screen:
“Initiating factory reset. The appliance will reset upon success.

This can take a long time, please wait. After reboot, consult
the monitor screen to view the progress of the factory reset.”
Do not interrupt the process or the appliance may be left in

an irrecoverable state.
7. After rebooting the appliance, the terminal will display the

progress of the wipe.
This progress will periodically update.
8. Once the wipe is complete, the terminal will show the following
message on the screen:
“Completed Wipe. Starting Setup.”
After completing the setup the appliance will reboot one further
time, at which point the process will be complete.
LAST UPDATED: AUGUST 4 2021
US: +1 415 229 9100 UK: +44 (0) 1223 394 100 LATAM: +55 11 4949 7696 APAC: +65 6804 5010 info@darktrace.com darktrace.com

Язык

Darktrace System Administration Guide

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Darktrace System Administration Guide

Оригинальное название:

Загружено:

Авторское право:

Darktrace System Administration Guide

Threat Visualizer v5.1

Access and User Permissions

Example Alert Outputs

Upgrades and Data Removal

Type of Device Tracking

Possible Device Tracking States

DEVICE MODELED SUBNET ADMIN

The following methods will be covered:

Ǔ Hostname assignment from passive observation of Kerberos data (enabled by default).

Observing Hostnames in Kerberos Traffic

1. Within the Threat Visualizer, navigate to the System Config

2. Locate Tracking from the available sections. Within the Network

If not, enable the setting and save the changes.

Polling DNS Servers to Append Hostnames

1. Within the Threat Visualizer, navigate to the System Config

2. Locate Data Population, then Active DNS Hostname Resolution.

To continue, add a value into this field. A typical value is 7200

New options will now appear.

3. When performing active DNS resolution, the Active DNS

4. The Active DNS Resolution Servers field controls the servers

If this field is left empty, polling will be completed using the

Save the changes.

Hostname Tracking with Syslog Ingestion

Observing Hostnames in DNS Traffic

1. Within the Threat Visualizer, navigate to the System Config

2. Locate Tracking from the available sections. Within the Network

Configuring a Subnet to Track by Hostname

1. In the main Threat Visualizer, navigate to the Subnet

2. Review the DCHP setting in the Tracking column.

The DHCP subnet setting controls if Darktrace should track

3. Review the Hostnames setting. Enabling this setting will begin

Credential Tracking with Syslog Ingestion

Configuring a Subnet to Track by Credential

1. In the main Threat Visualizer, navigate to the Subnet

2. Review the DCHP setting in the Tracking column.

If Tracking Credentials is to be enabled, DHCP must be disabled.

3. Review the Credentials setting. Enabling this setting will begin

Device Tracking and DHCP

Disabling Subnet DHCP

1. Within the Threat Visualizer, navigate to the Subnet Admin

2. Locate any Subnets with No DHCP in red.

If this is expected, the warning can be removed. Otherwise,

3. Locate the corresponding entry.

Click the highlighted DCHP in the Tracking column to disable

4. Confirm that the No DHCP warning is no longer in red.

Ingesting Syslog for Enrichment

Integration with other Security Tools

Tracking with Syslog Input

DATA TYPE REQUIRED SUBNET CONFIGURATION TEMPLATE TYPE REQUIRED FIELDS

DHCP - Enabled, Hostname -

Configuring a Syslog Input

PORT PROTOCOL RECEIVER ENCRYPTION PROPAGATION

Multiple log feeds can be configured concurrently.

Allowing Syslog Input

1. Configure the external device to send syslog to a Darktrace

2. Access the Darktrace master appliance intended to receive

3. In the Telemetry section, click the cog Config button. A new

Save the changes.

A template must now be defined for the logs to be parsed.

Log Ingestion Patterns

2020-01-01T01:00:10.000003+00:00 vpnhost example - - - User <testuser_1> IP Address <10.0.0.2>,

User <%{DATA:username}>.*IP Address <%{IP:ip_address}>

Preserving/Removing Whitespace in Field Values

User Device <%{DATA:hostname}>.IP Address <%{IP:src}>.<%{DATA:sourcetag}>

User <%{DATA:username}>.Domain <%{DATA:+@[username]}>.IP Address <%{IP:ip_address}>

Domain <%{DATA:username}>.User <%{DATA:-[username]@}>.IP Address <%{IP:ip_address}>

User <%{DATA:username}>.SessionID IP Address <%{IP:ip_address}.SessionID

User <%{DATA:username}>.Domain <%{DATA:+@[username]}>.SessionID <%{DATA:merge2}>