Darktrace System Administration Guide

Darktrace System Administration Guide
v4.1
DARKTRACE SYSTEM ADMINISTRATION GUIDE 2
Darktrace System Administration Guide
Type of Device Tracking�� 4
Tracking by Hostname�� 6
Tracking by Credentials�� 9
Device Tracking and DHCP�� 10
Log Input for Enrichment�� 11
Log Ingestion Patterns�� 13
Labelling Key Devices and Subnets�� 15
Configuring HTTPS Certification�� 17
Working with LDAP Servers�� 18
Example User Permissions�� 22
Guide to User Privileges�� 23
Anonymization Mode�� 25
Configuring An Email Server for Alerts�� 26
Sending Email Alerts to Specific Recipients�� 27
Configuring the Mobile App�� 29
Configuring the Mobile App for IMAP�� 30
Upgrading Darktrace Models�� 32
Appliance Console Guide�� 34
Advanced Search Export Formats�� 38
Configuring Advanced Search Export for Elasticsearch�� 40
Configuring Advanced Search Export for TCP�� 42
Host Variables in the Appliance Console�� 44

Creating an Immediate Backup�� 46
Configuring a Scheduled Backup via SCP�� 47
Configuring a Scheduled Backup via SMB�� 49
Configuring a Scheduled Backup via S3�� 51
Setting up Email alerts for Scheduled Backup Status�� 54
Restore from a Backup�� 56
Types of Darktrace Upgrade Bundles�� 57
Downloading Update Bundles�� 58
Performing a Guided Upgrade�� 59
Performing a Manual Upgrade�� 60
Securely Erasing Captured Data�� 62
Restoring the Darktrace Appliance to Factory Settings�� 64

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
Devices tracked by MAC Address seen in DHCP traffic. If DHCP is not

MAC DHCP: True, Hostname:
available for the entire subnet, tracking will fallback to track based on
False, Credential: False
hostname using Kerberos/DNS data.
Devices tracked by hostnames seen in DHCP data. If DHCP is not
Hostname DHCP: True, Hostname:
available for the entire subnet, tracking will fallback to Kerberos/DNS
True, Credential: False
data.
Hostname DHCP: False, Hostname:

Devices tracked by hostnames seen in Kerberos/DNS data.
True, Credential: False
Credential DHCP: False, Hostname: Devices tracked by credentials/usernames using data rom
(username) False, Credential: True authentication protocols observed or ingested VPN logs.
IP Address DHCP: False, Hostname:

Devices are modeled as static IPs using data seen to/from their IP.
False, 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 to 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 Log Input 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 Log Input 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.

Log Input 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. 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. Log ingestion templates are also used
to parse data retrieved by the Splunk Polling integration.
Where it is not possible to observe DHCP association directly, DHCP logs can be sent to Darktrace for parsing and mapped
to activity seen in ingested traffic. Custom event types derived from ingested event data can be used to integrate Darktrace
into your existing security stack.
Note that this data will not be added to Advanced Search.
Configuring Log Input
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.

Configuration Process
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 Event Ingestion section, click the 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.
Encrypted Log Input TLS Certificates
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 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.
Log Ingestion Patterns
Creating an Log Ingestion Pattern for Matching
Matching patterns are used to extract relevant data from

syslog format log entries or outputs from log polling
integrations. Log entries are matched against each
applicable configured pattern until a match is found. Once
a match is found and data is extracted by the associated
pattern, no further pattern matching will be attempted.
Each template has a name, a type, a filter and an extraction
pattern.
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) or where custom data is available in the model editor. The type of template defines
how Darktrace uses parsed 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.
Each template requires a filter, this is usually 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. 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.
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 .
It is useful to have example entries of the format to be parsed to use when testing and refining the pattern.
Please note: log input configured before 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.
Worked Example
The following log line is an example of logs coming from a VPN server and intended for use in a credential-tracked subnet.
2020-01-01T01:00:10.000003+00:00 vpnhost example - - - User <testuser_1> IP Address

<10.0.0.2>, Message
To parse this log, we will create a new template with type: Credential Tracking Logs. Logs from this source originate from
the host vpnhost, so this can be used as the filter.
Credential tracking logs require a username, an IP address and an optional timestamp. The following pattern extracts
these values from the log entry:
User <%{DATA:username}>.*IP Address <%{IP:ip_address}>
Once this template is configured and saved, the Test functionality can be used to compared log lines with the configured
pattern. Input can be loaded from lines seen or pasted into the field. Clicking “Test” will attempt pattern matching and list
successfully parsed fields.
Tracking with Log Input
Templates list both the optional and required fields for each data type. The most common types are DHCP, VPN (credential)
and Device Tracking. 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 EVENT TYPE REQUIRED FIELDS

CONFIGURATION
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”
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.
Working with LDAP Servers
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.
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 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
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. These settings are optional but strongly
recommended. 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
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.
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 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 Permissions page can be used to review the permissions assigned to each user.
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 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.

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 • Ask Expert

• Acknowledge Breaches • Dynamic Threat Dashboard
• Discuss Breaches • Register Mobile App
• View Models
• One Click Analysis
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 • Create PCAPs

• Device Admin • Download PCAPs
• Advanced Search • Antigena
• Status • Antigena Email
• Acknowledge Breaches • Unrestricted Devices
• Discuss Breaches • Ask Expert
• Edit Domains • Dynamic Threat Dashboard
• API Help • Register Mobile App
• View Models • Explore
• One Click Analysis
The following options provide full threat analysis with Advanced Search and capability to identify users. Packet Capture
and Antigena are also available.
(c). Full administration privileges:
• Visualizer • View Models

• Edit Models • One Click Analysis
• Device Admin • Create PCAPs
• Subnet Admin • Download PCAPs
• Audit Log • Antigena
• User Admin • Antigena Email
• Group Admin • View Messages
• Advanced Search • Unrestricted Devices
• Status • Download TIRs
• Acknowledge Breaches • Ask Expert
• Discuss Breaches • Dynamic Threat Dashboard
• Edit Domains • Register Mobile App
• Configuration • Explore
• API Help
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 the Antigena Email Visual Guide or User Permissions
PERMISSION DESCRIPTION
Visualizer Access to the main Threat Visualizer interface and limited read-only
access to some admin pages.
Edit Models Make changes to Models. Using tags can be a good way of tuning models
without requiring access to edit a model.
Lists all devices observed by Darktrace and allows for changes to be made
Device Admin to their classification. This is particularly useful for searching, bulk tagging,
or changing device types. Typically for administrators only.
Subnet Admin Lists all subnets and allows for changes to be made to their configuration.
Typically for administrators only
Audit Log Lists captured user behavior such as logging into Darktrace. Typically for
administrators only.
User Admin Controls access to user privileges. Typically for administrators only.
Group Admin Controls access to group privileges. Typically for administrators only.
Advanced Search provides a deep insight into network traffic making

Advanced Search every connection searchable. An excellent tool for investigating suspicious
activity, but may be restricted to more privileged positions due to the
insight granted.
Status For administrators and developers to check the system health of the
Darktrace appliance, probes, and network traffic.
Enables users to acknowledge model breaches. Any user investigating
Acknowledge Breaches breaches should likely have access to this role. Recommended for all but
the most restricted user.
Makes comments on model breaches. Very useful for controlling and
Discuss Breaches highlighting which users are working on a model. Recommended for all
but the most restricted user.
Edit Domains Make changes to domain information. Typically for administrators only.
Configuration Make changes to the System Configuration page. Typically for

administrators only.
API Help Provides information on the Threat Visualizer API. Recommended for all
administrators and developers.
To help understand how a model breach occurred, it is recommended that
View Models all users have access to View Models. Note there is a separate privilege for
editing roles, which is much more restricted.
Provides a quick view of the model breach to assist in identifying and
One Click Analysis investigating model breaches. Recommend for all users performing threat
analysis.
PERMISSION DESCRIPTION
Create PCAPs Enables users to create Packet Captures in the Threat Visualizer
application. Recommended for users familiar with Wireshark or other tools.
Download PCAPs Allows user to download created Packet Captures. Recommended for
users familiar with Wireshark or other tools.
Antigena Enables changes to be made to Antigena functionality. A valid Antigena

license is required.
Allows the user to view system messages on login (such as reboot
View Messages notifications) and those sent by Darktrace to the Darktrace Appliance.
Recommended for admin users. user.
When enabled, users can view all user credentials that have accessed a
Unrestricted Devices device. Disabling this option restricts users to an obfuscated view and
will prevent access to Device Admin and AI Analyst. Recommended for
restricted users.
Download TIRs Enables users to download Threat Intelligence Reports.
Ask the Expert Ask Darktrace Analysts questions about particular Model breaches.
Requires an additional Ask the Expert license.
Dynamic Threat Dashboard Provides access to the Dynamic Threat Dashboard.
Register the Darktrace Threat Visualizer mobile app. The mobile app (IMAP
Register Mobile App or Cloud Service) must be configured. Enabling this functionality provides
users with this access to a link on the Account Settings window.
Provides access to the Explore functionality that allows playback of
Explore communication between Subnets or Tags at a given point. Fixed positions
can be provided and set. Recommended for most analysts.
Allows users to access the Antigena Email console - adding the
Antigena Email permission to a user will reveal all Antigena Email permissions available.
Users given only the Antigena Email permission and lacking the Visualizer
permission will redirect to the Antigena Email console upon login.
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. Importantly, this mode only impacts Client machines in Darktrace. It does not impact any Server device Types.
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
• Credentials are not displayed
• No PCAPs can be generated
• Access to Advanced Search is restricted
Please note, AI Analyst is not accessible in this mode.
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.

Configuring An Email Server for Alerts
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.
Email Alerts
Email alerts for model breaches 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. Alerts include important information about the source device, the breach conditions and a direct link to the breach
for ease of investigation (requires FQDN configuration). 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 to a central SOC
team, while others prefer to configure the Email Alert so they are only alerted to the most serious model breaches. A series
of rules and filters can be defined for each recipient, ensuring alerts are distributed to the relevant Security Team member.
Note, emails are only sent when a model is set to alert. To view this setting, edit a model and confirm that the Action
setting 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 Alert Outputs.
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.
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.
Now, save your changes and proceed to configure

recipients.
Sending Email Alerts to Specific Recipients
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.
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 Alert Outputs.
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. Before defining filter options, optionally select an email

Subject Prefix that should be used when sending alert
emails to these recipients.
5. Email alerts offer two additional filters which control

when an alert should be sent to a specific recipient for a
particular model breach. If more than one alert condition
is configured then a model breach must meet all criteria
to generate an alert.
Optionally configure a list of device IPs or network

ranges that model breaches should be restricted to for
these recipients.
6. The second additional filter is an optional Model Tags

Expression, where model breaches are restricted to
those with tags that match the regular expression
defined.
7. If Modular Alert Thresholds is enabled, three additional

filter fields can be edited: Minimum Breach Priority,
Minimum Breach Score and Model Expression. .
If these fields are read-only, it means that these

thresholds are configured globally. Please see Global
Alert Thresholds below.
8. Optionally set a value for Minimum Breach Priority if

this field is available. Every model has a priority from
0-5 indicating the breach severity. Providing a minimum
alert priority of 1 to 5 will restrict alerts to models that
fire with a threshold of the priority number or greater.
9. Optionally set a value for Minimum Breach Score if this

field is available. The alert score (model breach score)
is displayed when hovering over the colored line to
the left of a model breach. The score is a percentage
representing the overall priority of a breach and can be
filtered with a slider in the main Threat Visualizer.
10. Optionally set a Model Expression to control alerts

if this field is available. Regular expressions can be
entered to restrict alerts to model names that match a
certain Regex value.
11. Finally, enable Send Alerts and save your changes.
Global Alert Thresholds
Three settings are available to filter the model breaches that Darktrace sends out to external alert platforms: Minimum
Breach Priority, Minimum Breach Score and Model Expression. These settings can be configured globally, or within each
individual email recipient configuration section. If more than one alert condition is configured then a model breach must
meet all criteria to generate an alert.
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 Config button to the right of Alert Outputs, and enabled on a per-format basis
using “Enable Modular Alert Thresholds”.
• Minimum Breach Priority: every model has a priority from 0-5 indicating the breach severity. Providing a minimum
alert priority of 1 to 5 will restrict alerts to models that fire with a threshold of the priority number or greater.
• Minimum Breach Score: the alert score (model breach score) is displayed when hovering over the colored line to
the left of a model breach. 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 Expression: regular expressions can be entered to restrict alerts to model names that match a certain
Regex value.
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 Alert
Outputs.
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.
Configuring the Mobile App for IMAP
The Darktrace mobile app allows users to easily access Enterprise Immune System Alerts when they are on the move.
Please note, IMAP functionality is now deprecated and will be supported on the legacy System Config page only. Please
contact Darktrace support for more information.
Mobile App Alerting Configuration
1. Within the Threat Visualizer, navigate to the ‘System Config’ page in the main menu under ‘Admin’. In the Alerting
section, set ‘Mobile App Alerts’ to true.
Scroll down to the ‘Save all Settings’ button or press

enter when editing a field value to save.
2. Saving the changes should expose additional

configuration options.
Complete your details using the example on the left.
3. Review the following three options at the bottom of the

Alerting section: Minimum Breach Priority, Minimum
Breach Score and Model Expression
These settings control when an app alert should be

generated for a particular model breach. If more than
one alert condition is configured then a model breach
must meet all criteria to generate an alert. If Advanced
Options are configured, mobile app-specific versions of
these fields will appear.
4. Optionally set a value for Minimum Breach Priority.

Every Model has a priority from 0-5 indicating the breach
severity. Providing a minimum alert priority of 1 to 5 will
restrict app alerts to models that fire with a threshold of
the priority number or greater.
5. Optionally set a value for Minimum Breach Score. The

Alert score is displayed when hovering over the colored
line to the left of a model breach.
6. Optionally set a Model Expression to control alerts.

Regular expressions can be entered in the Model
Expression field to restrict app alerts to model names
that match a certain Regex value.
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
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.
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
• == equals
• != does not equal
• > greater than
• >= greater than or equal to
• < less than
• <= less than or equals
• =~ regular expression match
• !~ regular expression negated match
Logical Operators
• () Parentheses for grouping expressions

• && AND (higher precedence)
• || OR
Special
• TRUE
• FALSE
• NIL - used to test the existence (!=) or non existence (==) of a field variable
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
1. Use highly compatible ssh ciphers Configures the SSH server to use a highly compatible set of ciphers.
Disabling this option increases the security of the SSH server.
2. HTTPS: Disable SHA1 ciphers and Enabling this option restricts the cipher suite in use by the HTTPS server
TLS protocols < 1.2 and disables TLS protocols other than TLS v1.2.
3. UI session expiry length Sets the number of minutes after which UI sessions are logged out due to
inactivity.
Enabling this option requires that all users of the Threat Visualizer
provide a second credential to access the user interface. Two-factor
4. Enforce two factor authentication authentication be individually enabled for specific users in the User
Administration page on the Threat Visualizer User Interface. Once enabled,
this setting cannot be globally disabled.
5. Set MTU Configuration This option sets the maximum transaction unit (MTU) size that can be
communicated over the network.
Enabling this option applies the kernel patch to mitigate the Meltdown
6. CVE-2017-5754 Intel “Meltdown” vulnerability (Kernel page table isolation). A reboot is required for changes
patch to take effect. For more details, please refer to “Darktrace Threat Note
Meltdown and Spectre.pdf” available to download from the Darktrace
Customer Portal.
7. Set alternative TSA port Sets the Terminal Services Agent (TSA) to post data to the appliance on
port 1443.
8. Block Darktrace user from
generating PCAPs Restricts the ability to generate PCAPs for the Darktrace user.
Changes the encoding for DHCP hostnames. The Windows DHCP client
9. Set DHCP hostname encoding transfers computer hostnames using the system encoding. Organizations
with Windows machines configured using to use non-ascii charactersets
by default may wish to change this setting.
Automatically generate an Executive Threat Report every Sunday at
10. Generate weekly Executive Threat midnight UTC, unless day and hour are set. Please note, this feature
Report will not run on 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.
14. FIPS 140-2 cryptographic Enforces FIPS 140-2 encryption on inbound HTTPS connections. When
compliance enabled on both Master and Probe, probes will only accept FIPS valid
ciphers in inbound connections from the Master.
HOST VARIABLE DESCRIPTION
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
validation host variable allows validation to be disabled if invalid checksums are
expected within traffic.
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.
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 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.
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.
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.
Configuring a Scheduled Backup via SCP
Scheduled Backups
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.

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

2. A range of backup options are available. Select

Scheduled backup configuration.

may appear stating “Backup configuration not set”".

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.
7. Enter a user to authenticate against for the server and

confirm.
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. Enter the hour, minute and second in UTC for the
backup and confirm.


proceed.
14. Optionally test the configuration.
Configuration can be tested at any time using Test

submenu.
Configuring a Scheduled Backup via S3
Scheduled Backups
Backups via S3
guide will cover backups to S3 compatible services.

2. A range of backup options are available.
Select Scheduled backup configuration.

may appear stating “Backup configuration not set”.

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.
13. Enter the hour, minute and second in UTC for the backup
and confirm.


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

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

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 user name 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 estab-
lished 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.
12. Login into the Threat Visualizer web application and

navigate to Admin, System Status from the main menu.
13. On the Status page, confirm that the software version

has been updated to the latest version.
If so, the upgrade process has been successful.

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 28 2020
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

Darktrace System Administration Guide

Type of Device Tracking�������������������������������������������������������������������������������������� 4

Device Tracking and DHCP������������������������������������������������������������������������������� 10

Log Input for Enrichment���������������������������������������������������������������������������������� 11

Log Ingestion Patterns������������������������������������������������������������������������������������� 13

Labelling Key Devices and Subnets������������������������������������������������������������������� 15

Configuring HTTPS Certification����������������������������������������������������������������������� 17

Working with LDAP Servers������������������������������������������������������������������������������ 18

Example User Permissions������������������������������������������������������������������������������� 22

Guide to User Privileges����������������������������������������������������������������������������������� 23

Configuring An Email Server for Alerts�������������������������������������������������������������� 26

Sending Email Alerts to Specific Recipients������������������������������������������������������ 27

Configuring the Mobile App������������������������������������������������������������������������������ 29

Configuring the Mobile App for IMAP��������������������������������������������������������������� 30

Upgrading Darktrace Models���������������������������������������������������������������������������� 32

Appliance Console Guide���������������������������������������������������������������������������������� 34

Advanced Search Export Formats��������������������������������������������������������������������� 38

Configuring Advanced Search Export for Elasticsearch������������������������������������� 40

Configuring Advanced Search Export for TCP��������������������������������������������������� 42

Host Variables in the Appliance Console����������������������������������������������������������� 44

Creating an Immediate Backup������������������������������������������������������������������������� 46

Configuring a Scheduled Backup via SCP��������������������������������������������������������� 47

Configuring a Scheduled Backup via SMB��������������������������������������������������������� 49

Configuring a Scheduled Backup via S3������������������������������������������������������������ 51

Setting up Email alerts for Scheduled Backup Status���������������������������������������� 54

Restore from a Backup������������������������������������������������������������������������������������� 56

Types of Darktrace Upgrade Bundles���������������������������������������������������������������� 57

Downloading Update Bundles��������������������������������������������������������������������������� 58

Performing a Guided Upgrade��������������������������������������������������������������������������� 59

Performing a Manual Upgrade�������������������������������������������������������������������������� 60

Securely Erasing Captured Data������������������������������������������������������������������������ 62

Restoring the Darktrace Appliance to Factory Settings�������������������������������������� 64

Type of Device Tracking

Understanding Device Tracking

Possible Device Tracking States

DEVICE MODELED SUBNET ADMIN RESULT

Devices tracked by MAC Address seen in DHCP traffic. If DHCP is not

Hostname DHCP: False, Hostname:

IP Address DHCP: False, Hostname:

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

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

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

3. When performing active DNS resolution, the Active DNS

4. The Active DNS Resolution Servers field controls the

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

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

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

3. Review the Hostnames setting. Enabling this setting will

Credential Tracking with Syslog Ingestion

Configuring a Subnet to Track by Credential

Type of Device Tracking�� 4

Device Tracking and DHCP�� 10

Log Input for Enrichment�� 11

Log Ingestion Patterns�� 13

Labelling Key Devices and Subnets�� 15

Configuring HTTPS Certification�� 17

Working with LDAP Servers�� 18

Example User Permissions�� 22

Guide to User Privileges�� 23

Configuring An Email Server for Alerts�� 26

Sending Email Alerts to Specific Recipients�� 27

Configuring the Mobile App�� 29

Configuring the Mobile App for IMAP�� 30

Upgrading Darktrace Models�� 32

Appliance Console Guide�� 34

Advanced Search Export Formats�� 38

Configuring Advanced Search Export for Elasticsearch�� 40

Configuring Advanced Search Export for TCP�� 42

Host Variables in the Appliance Console�� 44

Creating an Immediate Backup�� 46

Configuring a Scheduled Backup via SCP�� 47

Configuring a Scheduled Backup via SMB�� 49

Configuring a Scheduled Backup via S3�� 51

Setting up Email alerts for Scheduled Backup Status�� 54

Restore from a Backup�� 56

Types of Darktrace Upgrade Bundles�� 57

Downloading Update Bundles�� 58

Performing a Guided Upgrade�� 59

Performing a Manual Upgrade�� 60

Securely Erasing Captured Data�� 62

Restoring the Darktrace Appliance to Factory Settings�� 64