Открыть Электронные книги
Категории
Открыть Аудиокниги
Категории
Открыть Журналы
Категории
Открыть Документы
Категории
v4.1
DARKTRACE SYSTEM ADMINISTRATION GUIDE 2
Tracking by Hostname���������������������������������������������������������������������������������������� 6
Tracking by Credentials�������������������������������������������������������������������������������������� 9
Anonymization Mode���������������������������������������������������������������������������������������� 25
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 5
Using the configuration options available in Subnet Admin, the following tracking states can be achieved:
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 6
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Configuration Process
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.
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.
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 13
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.
Credential tracking logs require a username, an IP address and an optional timestamp. The following pattern extracts
these values from the log entry:
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 14
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.
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.
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.
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.
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.
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.
For example:
darktrace@examplecompany.com
cn=darktrace,dc=examplecompany,dc=com
The following steps configure the Threat Visualizer to allow user authentication via LDAP.
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.
LDAP data can also be retrieved to enrich the Threat Visualizer interface.
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.
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.
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.
The following options provide full threat analysis with Advanced Search and capability to identify users. Packet Capture
and Antigena are also available.
Full Administration access to change system configuration and perform details threat analysis. Typically, this level is
granted to System Administrators only.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 23
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.
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.
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 24
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.
Ask the Expert Ask Darktrace Analysts questions about particular Model breaches.
Requires an additional Ask the Expert license.
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 25
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.
• 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
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.
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.
Details for an email server which can be utilized by Darktrace must first be provided before individual recipients can be
configured.
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.
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 29
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 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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 30
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.
1. Within the Threat Visualizer, navigate to the ‘System Config’ page in the main menu under ‘Admin’. In the Alerting
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 32
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
Auto-Updating Models
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 34
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.
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.
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
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 35
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.
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.
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.
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 36
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.
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.
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.
If the installed certificate is blocking access to the UI, the certificate can be removed by the user to restore access.
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.
Please refer to Securely Erasing Captured Data and Restoring the Darktrace Appliance to Factory Settings for
more information on using this submenu.
Please see Configuring a Scheduled Backup via SCP, Configuring a Scheduled Backup via SMB or Configuring a
Scheduled Backup via S3.
This option tests the current scheduled backup configuration by placing a file of negligible size on the backup server.
The transfer key used for SCP backups can be regenerated using this option.
Please see Setting up Email alerts for Scheduled Backup Status for more details.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 37
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.
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.
If you are experiencing issues with the Darktrace Mobile App Service, Darktrace support may use this option to
restart the service.
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 38
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.
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
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'
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
DARKTRACE SYSTEM ADMINISTRATION GUIDE 39
Logical Operators
Special
• TRUE
• FALSE
• NIL - used to test the existence (!=) or non existence (==) of a field variable
Additional Examples
Fields[dest_port] != NIL
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.
Please ensure you have read through the requirements and filter syntax in Advanced Search Export Formats before
configuring the export.
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 42
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.
Please ensure you have read through the requirements and filter syntax in Advanced Search Export Formats before
configuring the export.
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 44
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.
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 45
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.
For the majority, pressing the space bar will toggle the
setting on or off. On is indicated by an asterisk [*].
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.
A backup file can be manually created through the appliance console and accessed via SFTP by the transfer user.
Scheduled Backups
The Darktrace Threat Visualizer application includes configuration options to backup your Darktrace appliances. A backup
includes all Darktrace machine learning, models, breaches, as well as subnet and device information, and configuration
settings on the Threat Visualizer GUI. It does not include transactional data such as connections in the Event Log, Advanced
Search entries and PCAP files, nor configuration settings on the console menu.
In networks with Probe and Master appliances, only the Master appliance needs to be backed up. In Unified View deployments,
or if more than Master is being used, make sure to back up all Masters.
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.
9. Enter the hour, minute and second in UTC for the backup
and confirm.
Scheduled Backups
The Darktrace Threat Visualizer application includes configuration options to backup your Darktrace appliances. A backup
includes all Darktrace machine learning, models, breaches, as well as subnet and device information, and configuration
settings on the Threat Visualizer GUI. It does not include transactional data such as connections in the Event Log, Advanced
Search entries and PCAP files, nor configuration settings on the console menu.
In networks with Probe and Master appliances, only the Master appliance needs to be backed up. In Unified View deployments,
or if more than Master is being used, make sure to back up all Masters.
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 SMB.
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.
Scheduled Backups
The Darktrace Threat Visualizer application includes configuration options to backup your Darktrace appliances. A backup
includes all Darktrace machine learning, models, breaches, as well as subnet and device information, and configuration
settings on the Threat Visualizer GUI. It does not include transactional data such as connections in the Event Log, Advanced
Search entries and PCAP files, nor configuration settings on the console menu.
In networks with Probe and Master appliances, only the Master appliance needs to be backed up. In Unified View deployments,
or if more than Master is being used, make sure to back up all Masters.
Backups via S3
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 to S3 compatible services.
ACCESS_KEY=key
SECRET_KEY=key
10. Enter the Secret Key into the prompt and proceed.
13. Enter the hour, minute and second in UTC for the backup
and confirm.
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.
Select OK to proceed.
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
Select OK to continue.
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:
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:
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:
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 58
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.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 59
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
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:
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.
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.
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.
Press OK.
DARKTRACE SYSTEM ADMINISTRATION GUIDE 64
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.
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).
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