DARKTRACE THREAT VISUALIZER

USER GUIDE v5.2

CONTENTS

THREAT VISUALIZER BASICS 5 OTHER INVESTIGATION TOOLS 59

THE THREAT VISUALIZER EXTERNAL SITES SUMMARY

USING THE WORKSPACE ALTERNATIVE APPROACHES

THE THREAT TRAY APPLYING TAGS

EXPLORE

CYBER AI ANALYST 25 REPORTING

AI ANALYST INCIDENTS

AI ANALYST INVESTIGATIONS THE SAAS CONSOLE 78

GETTING STARTED

INVESTIGATING A DEVICE 34 THE DASHBOARD

FOCUS ON A DEVICE CYBER AI ANALYST

DEVICE EVENT LOGS PROFILES

OTHER INVESTIGATION METHODS OTHER FEATURES

DARKTRACE MODEL BREACHES 49 ADVANCED SEARCH AND INTEL 98

MODEL BREACH ALERTS ADVANCED SEARCH

MODEL BREACH LOGS THREAT INTEL

CONTENTS

MODEL EDITOR 113 THE MOBILE APP 173

USING THE MODEL EDITOR GETTING STARTED

UNDERSTANDING A MODEL CYBER AI ANALYST

MAKING A NEW MODEL DEVICES AND MODELS

OTHER VIEWS AND SETTINGS

ADMIN INTERFACES 137

DEVICE & SUBNET ADMIN

PERMISSIONS ADMIN

SYSTEM STATUS

DARKTRACE RESPOND 148

UNIVERSAL DARKTRACE RESPOND ELEMENTS

DARKTRACE RESPOND FOR THIRD-PARTY PLATFORMS

DARKTRACE RESPOND/NETWORK
INTRODUCTION

Darktrace Threat Visualizer

Next generation threat detection is about more than simply finding what you can conceive of Darktrace’s Threat Visualizer is a powerful tool for intuitive visual storytelling alongside rich
in advance – it is about implicitly understanding what you, as a security professional, need to data that can be used to identify and investigate potential emerging threats as they develop.
know about.
This document is intended to help Darktrace users get the best possible results from the
Darktrace’s threat detection capability uses a self-learning approach. Instead of trying to pre- Threat Visualizer.
define what ‘bad’ looks like, Darktrace builds an evolving understanding of an organization’s
‘pattern of life’ (or ‘self’), spotting very subtle changes in behaviors, as they occur to enable
rapid investigation and response to in-progress attacks.

4
CHAPTER 1 - THREAT VISUALIZER BASICS

THE THREAT VISUALIZER

SUGGESTED WORKFLOWS FOR INVESTIGATING AN ALERT 6
LOGGING INTO THE THREAT VISUALIZER FOR THE FIRST TIME 8
INTRODUCING THE THREAT VISUALIZER WORKSPACE 9
MAIN MENU GUIDE 10

USING THE WORKSPACE

UNDERSTANDING THE SUMMARY PANEL 14
VIEWING THE NETWORK 15
EXPANDING A SUBNET 16
OTHER SUBNET VIEW FEATURES 17
USING THE OMNISEARCH BAR 18
CHANGING THE TIME 19

THE THREAT TRAY

THE THREAT TRAY 20
FILTERING ALERTS WITH BEHAVIOR CATEGORIES 21
FILTERING ALERTS WITH BASIC FILTERS 22
FILTERING ALERTS WITH ADVANCED FILTERS 23
SUGGESTED WORKFLOWS FOR INVESTIGATING AN ALERT

Where to Start Suggested Workflow from a Cyber AI Analyst Incident

Exploring behavior can be useful for improving the understanding of what is truly happening in Cyber AI Analyst will review and investigate all Model Breaches that occur on the system
the digital business and how it is all interconnected. as a starting point for its analysis process. It will then form incidents - a collection of one or
more related events - centered around a device. Incidents involving multiple devices will be
There are five primary ways in which analyst teams can begin seeing and reacting to identified classified as ‘cross-network’.
alerts or incidents produced by Darktrace
The Cyber AI Analyst, with its global network awareness and machine-speed investigation time,
1. The Cyber AI Analyst automatically analyzes, investigates and triages all model performs the heavy-lifting of the analysis process.
breaches on your network. The incidents it creates give a concise summary and
actionable steps to investigate any detected threats further. 1. Log into the Threat Visualizer and click the Cyber AI Analyst icon in the Threat Tray
or open the AI Analyst tab on the Darktrace mobile app. Review the incidents it has
2. A “threat tray” is shown at the bottom of the 3D Threat Visualizer interface in most created.
screens and will be displayed on login. The 3D Threat Visualizer enables deep
investigation of behaviors. 2. Select the most severe incident or the most interesting to you based on your knowledge
of the business and network setup. Review the summary created by Cyber AI Analyst to
3. A Dynamic Threat Dashboard triage screen (accessible from the menu at top left of quickly understand what each incident may involve.
the home screen). This screen is intended for extremely rapid triage with a minimum
of interaction. Note that it will scroll through incidents if left unattended which can be 3. Review the summary of each event within the incident and understand how the events
useful on SOC TV display screens. relate chronologically using the activity-over-time visualization. On the mobile app,
read the incident overview and swipe between the events.
4. A simplified SOC dashboard triage screen is available via the Darktrace mobile app.
4. Scan the detailed event information to gauge the involved connections and review the
5. Automated alerts may be exported into SIEMs or via API to other SOC systems and will related anomalies. Confirm if AI Analyst is currently processing any further breaches
include a link back to the incident data in the Threat Visualizer. for the device. Optionally check the attack stages that AI Analyst has derived for each
event.
Organizations with a Darktrace/Apps, Darktrace/Cloud or Darktrace/Zero Trust module can
utilize the SaaS Console for triage and analysis. This specialized interface is focused on the 5. If the activity of interest relates directly to a model breach, investigate the breach log.
investigation of incidents within SaaS and Cloud environments. For more information, please
see Getting Started with the SaaS Console. 6. Check the Actions section to see if Darktrace RESPOND/Network blocked the
associated activity. Follow up the suggestions made by AI Analyst to resolve the
incident.

7. Optionally create a PDF report describing the events.

8. Acknowledge each event as the investigation is concluded or acknowledge the entire

incident if resolved.

6
Suggested Workflow from a Model Breach

When investigating an alert, a typical workflow will involve starting with summary information. 8. Check whether similar devices are behaving in a similar way (via similar devices in
This is shown by default in the Dynamic Threat Dashboard or can be seen by clicking the eye device summary).
icon. The analyst is not swamped with too much to deal with all at once – enabling you to triage
quickly whether the anomaly is worthy of further review. 9. If appropriate, create and review raw packets (pcap) for interesting connections.

You can then visually playback the behavior and event information, drilling down into increasing 10. Consider using third-party resources for context regarding a suspicious domain, IP
levels of detail, and broadening the investigation to correlate for related behaviors across the address or file.
network at each stage of the investigation. As an example:

1. Log into the Threat Visualizer and either access the Dynamic Threat Dashboard, or filter
the threat tray to include a manageable number of Model Breaches using the severity
slider and adjusting the time period for which to display model breaches i.e.  last 24
hours.

2. Investigate the alerts that seem most interesting to you based on your knowledge of
the business and network setup. Regardless of how anomalous the activity is, if you
are more interested in malware infections than data exfiltration, then looking at a
‘beaconing’ Model Breach first might be more relevant than looking at an ‘unusual data
transfer’ Model Breach.

3. Identify what type of device this is and how it normally behaves.

4. Look at which events contributed to the breach.

5. Look at whether the device has related anomalies at the time or previously.

6. See exactly how anomalous this activity was or plot against related activities to spot
any other anomalies or to display how important Darktrace considers that particular
anomaly (overlay additional metrics including importance metrics in the graph).

7. Consider replaying the events to better understand the context of what was happening.
If in the dynamic threat dashboard, click on the displayed 3D Threat Visualizer widget.
Once in the 3D View, open up the device event log at the top left and press the play
button on the timeline at top right.

7
LOGGING INTO THE THREAT VISUALIZER FOR THE FIRST TIME

The Threat Visualizer interface, powered by Darktrace’s self-learning technology, continuously

assesses the behavior of devices and users across the wider digital estate. Activity from remote
endpoint devices, servers located in local datacenters, serverless architecture in public cloud
environments or users working in third-party SaaS services is surfaced side-by-side.

Anomalous interactions and activity are highlighted to the end-user and prioritized for
investigation by Darktrace’s Cyber AI Analyst. Many operators start with these high-level
investigations and dive down into detailed metadata and device or user activity in specialized
interfaces.

The interface is flexible and accommodates a range of workflows or threat investigation

processes.

The Threat Visualizer interface can be accessed from an IP (physical instance only) or
hostname (e.g., https://[region]-XXXX-01.cloud.darktrace.com). The login
screen will be displayed.

Enter your username and password to login. The password can be reset at any time from the
Permissions Admin page of the interface if required.

If you are accessing the Threat Visualizer via your organization’s SSO system, click the Login
Via SSO button, and log into your SSO system as standard. You will then be redirected to the
Threat Visualizer after a successful login.

For cloud based instances of the Threat Visualizer, or environments where 2FA has been
enabled by an administrator, a QR code will be displayed on first access. Please scan this QR
code with your preferred multi-factor authentication app such as Google Authenticator or Duo
Security.

After login, the Threat Visualizer home screen will be displayed. The default landing page can
be altered from Account Setting, or your administrator may have configured it for you already.
The available options are: Threat Visualizer (default), Dynamic Threat Dashboard, Email
Console, SaaS Console, and System Status Page.

Please note, the minimum supported browsers to access the Darktrace Threat Visualizer
application are Chrome 85, Firefox 81, Safari 14.

8
INTRODUCING THE THREAT VISUALIZER WORKSPACE

After logging in, the Threat Visualizer home screen will be displayed. The main workspace is • In the top right is the time selector. The chosen time is used as a starting point for
used to visualize devices and connectivity, to open investigation windows and event logs, and replaying visualizations of connections and event logs will display events backwards
to view alerts from Darktrace anomaly detection. from this time. Changing the time is covered in more detail in Changing the Time.

In the top left are two icons: • On the left of the workspace is the summary. The summary provides key statistics
about bandwidth, devices and AI Analyst investigations. Each element of the summary
ICON DESCRIPTION is described in Understanding the Summary Panel.

Clear any focused devices or windows and return to the main • The main workspace displays an overview of your network. The default shows a
home Home
workspace visualization of subnets in your network on a world map. This is covered in more detail
in Viewing the Network.
Access a list of key investigation, configuration and administration
bars Main Menu interfaces. A full, detailed list of menu items is available in Main Menu
Guide. • Finally, at the bottom of the workspace, is the threat tray which displays alerts from
Darktrace analysis. The threat tray is explained over a series of articles - starting with
Other key elements of the workspace are always displayed: The Threat Tray is recommended.

• The omnisearch bar can be used to search across devices, users, subnets, and external
endpoints observed by Darktrace. The omnisearch bar is covered in more detail in
Using the Omnisearch Bar. 9
MAIN MENU GUIDE

The Darktrace Main Menu offers an instant way to get to the main features within the UI. envelope Email Console
Clicking on the menu icon in the top left will display all available options. These will change
depending on the user and the permissions granted to them. Pivots to the Darktrace/Email interface for investigation and autonomous actions on your
email domains. Please see the documentation on Darktrace/Email for more information.
search-plus Advanced Search

Opens a new browser tab to Darktrace advanced search. Refer to Darktrace Advanced Search
for more information. cloud SaaS Console

The SaaS Console is a specialized user interface for investigating anomalous activity and
user behavior in and across SaaS and Cloud environments, surfacing the events and analysis
tags Tags from Darktrace/Apps, Darktrace/Cloud and Darktrace/Zero Trust modules in one centralized
location. Please see The SaaS Console for more information.
The Threat Visualizer supports a flexible label system called Tags to allow analysts to be able to
rapidly label and refer to groups of devices within the platform. One use case for this feature is
to enable monitoring of high-risk users or devices such as departing employees or key assets.
Refer to Adding and Reviewing Tags for more information. c AI Analyst Investigations

c Launch Investigation

arrow-circle-down Packet Capture Manually trigger a new AI Analyst investigation on a device or SaaS user. See Triggered AI
Analyst Investigations for more information.
Click to view the list of PCAP files you have created which are stored on the Darktrace appliance.
Refer to Creating Packet Captures for more information. list View Investigations

Opens a list of current and previous AI Analyst triggered investigations.

a Antigena Actions (Darktrace RESPOND)

Presents currently active and expired actions taken by Darktrace RESPOND components
(excludes Darktrace/Email) and allows the actions schedule to be configured. Current and
historic actions can be exported as a CSV. Refer to Reviewing Darktrace RESPOND Actions for
more information.

10
exclamation-triangle Models
wrench Admin
Model Editor
desktop Device Admin
A Model is used to define a set of conditions which, when met, will alert the system to the
occurrence of a particular event. Refer to The Model Editor for more information. This page contains a list of basic information regarding every internal device Darktrace has
ever observed. The list is exportable to Excel and some fields can be altered (e.g., type of
list Model Summary device). Refer to Device Admin for more information.

List of the models with analysis of how many times and how strongly each model has breached cubes Subnet Admin
since the appliance was installed.
Similar functionality but applies to subnets. The DHCP slider shows whether Darktrace should
sync-alt Model Updates be seeing DHCP for that specific subnet. Refer to Subnet Admin for more information.

This page allows you to view recent updates to the models. Refer to Model Updates or the id-card Audit Log
Darktrace System Administration Guide for more information.
This page shows recent interactions with the platform completed by the various users (e.g.,
acknowledging breaches, logging in and out).

book Reporting tachometer-fast System Status

analytics Cyber AI Insights Report System metrics such as ingested traffic quality, master/probe reachability, and protocols
observed can be reviewed.
Cyber AI Insights reports provide an overview of your organization’s current Darktrace
coverage, key statistics on threat trends across deployed components, data on response cog System Config
times by Darktrace RESPOND and analyst engagement. Refer to Cyber AI Insights Reports for
more information. Provides all configuration settings for the Darktrace Threat Visualizer application including
Darktrace RESPOND settings and authentication for DETECT modules and integrations.
Executive Threat reports are high level, visual overviews of network activity and model breach Alerting options can be configured here.
events. Refer to Executive Threat Reports for more information.
user Permissions Admin
newspaper Executive Threat Report
The Permissions Admin interface allows user permissions and data visibility to be controlled
Executive Threat reports are high level, visual overviews of network activity and model breach at an individual and group level. Group permissions for LDAP and SSO users can also be
events. Refer to Executive Threat Reports for more information. configured. For detailed information on users, groups, permissions and data visibility, please
refer to Permissions Admin.
download Download Reports
This interface has replaced the legacy User Admin and Group Admin interfaces.
This page allows Threat Intelligence reports and both manually generated and scheduled 11
Executive Threat Reports to be retrieved.
unlock-alt Permissions random Intel

Users who have created other users (and therefore ‘own’ them) can review their permissions check Trusted Domains
here in a read-only format. The “admin” user can also review permissions for users created via
LDAP and SAML SSO on this page. Trusted domains are endpoints which Darktrace will consider as 0% rare; this feature ensures
that models relying on domain rarity will not fire for activities involving common domains - a
default, editable list is provided. See Trusted Domains for more details.

plug Utilities eye Watched Domains

U Punycode Convertor Watched domains are endpoints which trigger automatic model breaches if observed in
connectivity. The list is not populated by default but may be added to by TAXII feeds, Darktrace
Enter text in the top window to convert to Punycode; enter Punycode in the bottom window Inoculation, via the Threat Visualizer API or by manual edits. See Watched Domains for more
to convert to text. Punycode is used in DNS to encode Unicode international domain names details.
(IDN) into ASCII. Can be identified as it always starts ‘xn—’“.
cog TAXII Config
(.*) RegEx Tester
Permits the ingestion of internal or third-party TAXII feeds and STIX files. The last 10,000
Enter a RegEx in the top bar and an example string to test it in bottom bar. If the string matches observables ingested can be reviewed, whether derived from stand-alone files, subscribed
the RegEx the bottom box’s border turns green; otherwise it remains white/yellow. TAXII collections or Darktrace Inoculation. See TAXII Config for more details.

64 Base64 Convertor bolt Dynamic Threat Dashboard

Enter text to be decoded or encoded using Base64. The Discovery View provides an easy left-to-right dashboard to investigate an incident down
to the connections that caused the alert to fire. Refer to Dynamic Threat Dashboard for more
js JS Beautifier information.

Tool for ‘beautifying’ JavaScript to increase readability

clock Epoch Converter

Converts epoch time in seconds since 1st Jan 1970 (as seen in advanced search) to normal
time.

12
map Explore cogs Account Settings

cube Explore Subnets Change settings for your own account including default color-coding in the event log, enabling
accessibility mode, selecting the AI Analyst language, changing the default landing page and
Explore Mode for subnets gives an overview of all connection events between subnets at threat tray behavior category filters.

a given time interval, filterable by connection size and transfer ratio. Drill-down to a device-
to-device level is also possible. A master layout can be defined to reflect existing network d Customer Portal
topology diagrams.
Opens the Darktrace Customer Portal in a new browser window or tab. The Customer Portal
tag Explore Tags provides access to all product documentation, support tickets, analyst insights and Darktrace
Education materials.
Explore Mode for tags gives an overview of all connection events between Tags at a given time
interval, filterable by connection size and transfer ratio. Drill-down to a device-to-device level
is also possible. A master layout can be defined to reflect existing network topology diagrams.
sign-out-alt Logout

Log out the current user account.

question Help

Ask the Expert

Ask the Expert allows for the creation of incidents which can be submitted to Darktrace
analysts for feedback. Refer to Ask the Expert for more information.

question-circle View Questions

After a request has been generated, you will be able to view your open and closed
questions by clicking View Questions; this window will show the conversation and any relevant
information, as well as the ability to reopen or delete an historic request.

file-code API Help

Provides a link to the Threat Visualizer API documentation hosted on the Darktrace Customer
Portal.

13
UNDERSTANDING THE SUMMARY PANEL

Key statistics about your Darktrace environment can be accessed from the summary panel on The total bandwidth processed over the last 28 days is displayed for both network and endpoint
the left of the Threat Visualizer workspace. By default it is collapsed. Each icon can be hovered data; each bar can be hovered for a breakdown between the two input sources. Processed
for basic statistics or the whole panel can be expanded for detailed information. bandwidth is not equivalent to ingested bandwidth - some ingested connections may not be
processed due to configuration settings such as exclusion rules.
Summary Pane
If Darktrace RESPOND/Network is enabled, statistics on the number of actions taken and
The first section displays information about the devices actioned will be displayed.
number of patterns of life and modeled entities in your
environment. AI Analyst investigates anomalies detected by the Darktrace system at machine speed and
surfaces only those that need human attention. The summary displays the equivalent number
Darktrace creates an overall pattern of life for every of hours it would take a human analyst to perform the same investigations. Of those incidents
entity it sees - whether endpoint devices, users surfaced, the type of activity they represent is broken down by category.
interacting with resources in external platforms, or
servers within the internal network. Networks are
alive with constant activity and repeated patterns;
Darktrace’s self learning AI observes these patterns
and derives a sense of “normal” behavior for devices,
users and peer groups.

Each pattern of life for a device or a peer group is itself

built from of thousands of fragmentary patterns of life -
a unique connection, event or activity that contributes
to the overall understanding of your digital environment.
The number of patterns of life is not expected to match
the number of modelled entities such as devices or
users.

Device counts display the number of entities - users

detected in external platforms (SaaS users), devices,
credentials - that Darktrace has observed and is
actively modelling a pattern of life for. These counts will
change as new devices appear and inactive devices
are no longer seen. Statistics are calculated over 7 days,
28 days or 12 weeks.

14
VIEWING THE NETWORK

The main workspace is used to visualizer connections and devices in 3D in real time. The Individual Subnets
default view is a simplified subnet view.

Workspace The color of the subnet cube can be used to quickly gauge the level of anomaly:

The Threat Visualizer homepage displays an overview of your network. Each subnet is displayed • A green icon indicates at least one device in the subnet has been subject to a
as a “cube” icon. Hovering over a subnet icon will show the label or equivalent subnet range, if Darktrace RESPOND action.
no label has been provided. Where many subnets are located in close geographic proximity,
these are collapsed into a single cube. The list of collapsed ranges is shown on hover. • An icon from yellow to red indicates at least one device in the subnet has been
subject to a model breach, with the color representing severity.
For devices monitored by Darktrace DETECT & RESPOND/Endpoint agents, subnets are
automatically created and grouped by the country that the devices are located in. Subnets Where many subnets are collapsed into one icon, the icon will show the highest anomaly
created directly from network traffic can be relocated geographically by providing a latitude level of the underlying subnets.
and longitude on the Subnet Admin page. Across the top of the workspace are special-
purpose subnets for internal (unmodeled) traffic, internal multicast and broadcast traffic. Clicking once on an icon will center the workspace; when centered, hovering over the
These subnets cannot be moved. icon will give more detailed information on device membership. Clicking again will open a
detailed view of the subnet.

15
EXPANDING A SUBNET

Focusing on a Subnet

Click on any cube on the main workspace to focus on a specific subnet. The visualization will Connectivity
switch to subnet mode. To return to the full network visualization, click the small cube at the
top left of all connecting cubes, or click the home-lg home button. Blue lines represent active connections transferring data. Devices may connect to internal
locations, to external locations or connect to one another within the subnet.
Visualization
Internal subnets are represented by cubes on the left of the visualization. Hover over these
The main workspace now shows a visualization of network devices in the subnet connecting to cubes to see the subnet they represent or click to change the focus to the alternate subnet.
internal and to external locations in real time. SaaS devices are not visualized by subnet view.
Pseudo-subnets are created for devices monitored by Darktrace DETECT & RESPOND/
Devices Endpoint agents, grouped by the devices’ geographic location. As agents monitor devices in
remote networks, inter-subnet connectivity will not be displayed. Nodes for these devices will
Glowing nodes are devices with active connections at the time chosen in the top right. When always be displayed connecting to external locations.
the visualization is unpaused, nodes will appear and disappear as connections start and finish.
Nodes which are colored from yellow to red are devices displaying anomalous behavior. A boundary on the right of the visualization represents the border between internal and external
locations. External connections from devices in the subnet are shown passing through this
Hover over a node to display a tooltip with a summary of the device’s IP, hostname, type and boundary.
applied tags. Click the device to change the focus to the device.
16
OTHER SUBNET VIEW FEATURES

Subnet Statistics Subnet Options

On the right of the workspace is a panel with statistics The network range that represents the subnet is populated in the omnisearch bar. Beside the
about the subnets’ connectivity over the time window subnet range are a selection of icons.
chosen in the selector. The time window - default 5
minutes - is shown below the timezone. The panel
includes the most-used protocols and the largest data
flows to other internal subnets and the wider internet. ICON DESCRIPTION
Each section of the panel can be collapsed by clicking
the heading. Explore is an alternative interface for investigating subnet-subnet
link Explore subnet connectivity. This icon opens the Explore interface focused on the
connectivity chosen subnet. Explore subnets is covered in more detail in Explore
The network statistics panel is useful, for example, to
Mode.
quickly identify devices causing the highest inbound
data transfer in the subnet or to check for the presence Open subnet The graph allows metrics of device behavior to be plotted over time.
of prohibited protocols. Filters applied to the panel also graph In subnet mode, metrics are plotted for all devices in the subnet. The
Open subnet
graph is described in more detail in Other Device Summary Sections
impact the main workspace, allowing visualization to be graph
in the context of individual devices but is also applicable to subnet
restricted to certain protocols (e.g. UDP) or to certain mode.
external endpoints.
This icon opens the model breach log - a list of model breaches
triggered by all devices in the subnet. The default timeframe is 7 days
Click a key on the left of the panel to apply it as a filter. exclamation-triangle View Breaches
but can be altered. Breach logs in general are covered in more detail
The free-text search can also be applied to any key, in Viewing a Model Breach.
allowing specific protocols or endpoints to be located
Edit provides quick access to change the subnet label, geographic
for filtering.
pencil Edit Subnet Info location and tracking information. This information can also be
changed in bulk in the Subnet Admin interface.
Multiple filters can be applied and will appear above
Clicking this icon will trigger an omnisearch query for all devices in the
the panel. Filters applied on this panel will impact other
subnet, not just those currently visualized on the workspace. Scroll
windows and event logs. search Devices on this
to browse or click to change the focus to a specific device. Detailed
subnet
information about omnisearch queries is also available in Using the
Omnisearch Bar.

17
USING THE OMNISEARCH BAR

The omnisearch bar is another way to focus on subnets, devices, models and specific There are many types of information that can be returned by an omnisearch query:
connections or events. The search autocompletes and suggests the most relevant search
results. EXAMPLE RESULT TYPE ACTIONS

For device results, the device options

ws183.holdingsinc.com · described in Device Investigation
ws183.holdingsinc.com
10.15.15.2 · 10.15.15.2 Device
Options are also accessible from the
omnisearch bar.
Change the focus to a specific subnet.
The same subnet options described in
square-full 10.15.15.0/24 Subnet
Other Subnet View Features are also
accessible from the omnisearch bar.
For devices, it is possible to search by label, mac address, IP and hostname. When searching for
For external IPs and hostnames, the globe-americas
devices, a list of suggested devices will be displayed along with their derived device type and
external sites summary can be opened
simple information such as IP, hostname, MAC address (where available). Users - credentials from the omnisearch. The summary
Darktrace has observed being used by a device - can also be returned. The devices currently External
globe-americas view event log for google.com… covers interaction between internal
associated with the user will appear as an indented list underneath their entry. location
devices and the external host over time.
The summary is covered in more detail in
External Sites Summary.
Models can also be searched for from
the omnisearch. If the model is inactive
(disabled), this is indicated. Click the exclamation-triangle
exclamation-triangle Compliance / Telnet Model
triangle icon to open the model editor
for the model, or click the page icon to
open a breach log for the model.
Unique uuids are assigned to every
To focus on a device, subnet or connection - click the entry. The options for each result can be event, connection or group of
clicked without changing the workspace focus. This means event logs and summaries can be connections observed by Darktrace.
chart-network S3a9BRg6DoFtrbpu2e UUID Click the align-justify lines icon to open an event
opened within focusing the view completely on the device.
log for the UUID. The UUID will also be
populated in omnisearch if a pivot from
Advanced Search was performed.

Advanced searches can also be performed with prefixes. For example, using
subnet:10.0.0.0/24 will return devices within this subnet, tag:Test will return devices
tagged with the “Test” tag.

18
CHANGING THE TIME

The time selector in the top right controls the connection visualization and the starting point Time Window
for event logs in the main workspace. Focusing on an alert will change the time in the selector
to the time of the alert so events can be replayed. Some elements use a window of time to display information over. When focusing on a device
or subnet, a panel with statistics appears on the right of the workspace. This element uses
Some elements, such as the threat tray, show alerts over a large time window. These elements the time window to show statistics on data transfer volumes and connections - changing the
have their own time selector and this will be clearly indicated. window will alter this panel.

Changing the Time The size of the time window is shown above the bar. The start and end times are displayed on
either side.
• Click the time in the top right to select a specific
time and date. • Values on the left of the window arrow-to-left make the window smaller when clicked.

To move relatively, use the 1 day, 1 hour, 1 minute • Values on the right of the window arrow-to-right make the window larger when clicked.
buttons at the bottom. Those on the left of the
play play icon move the time backwards, those on Hover within the window at a specific time and click to set the main time selector to that time.
the right move forwards.

• Click the timezone to change the current

location-based timezone. By default, the
browser timezone is used. Any open event logs
will not show the new timezone until closed and
reopened.

• Click the redo return icon to reset the time to the

current time.

• Click the angle-down dropdown arrow to change the time

window. The window is discussed in further
detail below.

• Click the play play button to play the 3D

visualization currently on the workspace real
time from the time chosen.

19
THE THREAT TRAY

Threat Tray
When conditions for a model are met, this creates a model breach and can trigger an alert or
The panel at the bottom of the main threat visualizer workspace contains alerts from Darktrace action. AI Analyst investigates every model breach that occurs on the system and reports only
anomaly detection. For any investigation workflow, the tray is the first place to start. By default, the most interesting activity as incidents.
it will show incidents created by AI Analyst on first access. Afterwards, it will remember the last
mode used. thumbtack Pinned Model Breaches

The tray has four options: c AI Analyst, exclamation-triangle Model Breaches, thumbtack Pinned Model Breaches, chart-area Model breaches can be pinned for quick access. Pinning is specific to each user and persists
Model Breach Cluster View. between logins (requires local storage). A list of pinned model breaches is retrievable by
clicking this icon.
c AI Analyst
Clicking on a model breach from the pin list will open the model breach log. Model breach logs
Incidents are created from AI-powered investigations into anomalies across your digital are covered in further detail in Opening the Model Breach Log.
environment. Every time the conditions for a model are met and a model breach is created,
AI Analyst investigates the activity and concludes whether it needs to be surfaced for human chart-area Model Breach Cluster View
analysts to review. The results of this analysis is then grouped in incidents.
In cluster view, model breach events are plotted onto a graph of severity score against time,
AI Analyst only reports upon the most important or interesting activity - it performs the heavy allowing patterns and clusters of model breaches to be quickly identified. A key of what each
lifting and should be the starting point for any Darktrace operator. point represents is shown on the right. Model breaches are aggregated into single dots by
the model breached, by the device, or by the credential that triggered the model breach.
exclamation-triangle Model Breaches Aggregation is dependent on the “Sort By” chosen.

Darktrace models are a logic framework that allows operators to interact with the output Clicking on a point on the graph will open the model breach log. Model breach logs are
from ‘pattern of life’ and anomaly classifiers. Models are primarily used to identify and alert covered in further detail in Opening the Model Breach Log.
on anomalous and potentially malicious behavior. The Threat Visualizer platform provides a
curated set of default models as standard, designed and constantly tuned by the specialized
Darktrace analyst team.

20
FILTERING ALERTS WITH BEHAVIOR CATEGORIES

The alerts in the threat tray can be filtered in many different ways to support different priorities Categories can be applied to AI Analyst and Model Breaches separately. To see the currently
and investigation workflows. The most important filter to be aware of is behavior categories. applied categories, open the filter Filters tab and click the ellipsis-h three dots icon.

Behavior categories are high level filters that allow an operator to focus in on specific levels When new users are created, the behavior categories they see as default when they first log
of severity or behavior. There are four categories: Critical, Suspicious, Compliance and in can be customized. For existing users, the default behavior categories they see can be
Informational. Categories are used across both AI Analyst and Darktrace models. customized in two ways:

• Critical alerts represent events with the highest anomaly and are where an analyst • In Account Settings, by altering the settings “Default Threat Tray AI Analyst Behavior
should focus their attention in the first instance. Visibility” and “Default Threat Tray Model Behavior Visibility”.

• Suspicious alerts are those which suggest moderate levels of anomaly but do not • By creating a saved filter with the desired behavior categories and setting it as default.
warrant prioritization over critical. This saved filter takes priority over account settings, if set.

• Compliance alerts are raised for behaviors that may be counter to organizational
policies and best operating practices.

• Informational alerts cover low level indicators and notable events which do not
indicator malicious activity in isolation. The informational category is not applicable to
AI Analyst alerts as only events worth analyst attention are surfaced.

21
FILTERING ALERTS WITH BASIC FILTERS

Filters Time

For many operators, there are two more key filters they will use when investigating alerts: AI Analyst incidents and model breaches can be filtered by a time range to control the quantity
time and by score. The time range and score range over which alerts are returned can be of alerts. The range is controlled separately for the two alert types. If a custom range is chosen,
customized. the two date fields will become interactable so a range can be chosen.

AI Analyst incidents are made up of multiple alerts that may occur over a longer time frame. An
incident will be returned if any of its underlying events happened within the range, ensuring
that active, developing incidents are not excluded.

This time range may also impact other investigation elements - this will be noted where relevant.

Score

Both AI Analyst incidents and model breaches can be filtered by a severity score using a slider.
By default, the minimum is set at 20% for AI Analyst incidents and 60% for model breach alerts.
This can be altered manually or overwritten by a saved filter.

AI Analyst incidents are given an overall score from 0-100%, represented by a gradient from
dark (lowest severity) to light blue (highest severity). The score is calculated from the number
of devices, the type of activity and the level of anomaly across all events that make up the
incident. High scores indicate incidents that AI Analyst believes to be high priority for human
attention.

When the criteria for a Darktrace model are met, a model breach is created with a score from
More granular filters are also available for both AI Analyst incidents and model breaches so 0-100%, represented by a gradient from yellow (lowest severity) to red (highest severity). The
that specific types of activity or parts of the network can be focused on. These filters are score is calculated from the type of activity, the priority of the devices involved and the rarity
entirely optional and are in addition to the key filters already discussed. of the model breach for the device.

Filter sets can be saved for AI Analyst incidents and model breaches and set as the default Score can be a useful metric to use when prioritizing within a category - for example, starting
view. with category “critical” and addressing alerts in order of score. The two scores should not be
seen as comparable. AI Analyst only surfaces the most important and interesting activity for
users, whereas model breaches cover the full range of activity from low level, informational
activity to high priority alerts.

22
FILTERING ALERTS WITH ADVANCED FILTERS

Filters

For many operators, there are only two more key filters they will use when investigating alerts:
time and by score. The time range and score range over which alerts are returned can be
customized.

More granular filters are also available for both AI Analyst incidents and model breaches so
that specific types of activity or parts of the network can be focused on. These filters are
entirely optional and are in addition to the key filters already discussed.
Filters
Changing the Default View
FILTER DESCRIPTION
The current set of filters can be saved for AI Analyst Incidents and Model Breaches and applied
This filter allows devices from specific subnets to be removed from
as the default for subsequent sessions.
the returned results. Subnets can be selected from a list or a custom
range (such as 10.0.0.0/8) can be defined. When at least one subnet
Saved filters for both alert types include the behavior category visibility, the score range, the is selected, the filter can be set to “Include Subnets” (only show
time range and subnet filters. Model breach saved filters also include model folder filters, Subnets
devices from these subnets) or “Exclude Subnets” (remove all devices
model tag filters, the sort type and whether results should include acknowledged or exclusively from these subnets). Subnet filters are not applicable to geographic
Darktrace RESPOND model breaches. subnets created for Darktrace DETECT & RESPOND/Endpoint agent
devices.
Turning on “Default Filter” when a filter is saved or edited (and saved) will mean the filter set is Model breach and AI Analyst alerts can be acknowledged as part
applied in subsequent sessions. Include of an investigation workflow. By default, acknowledged alerts are
Acknowledged removed from the returned results. Turn this setting on to include
Saved filters take priority over account settings, if set. these results.
AI Analyst incidents can be globally pinned - this means they will be
AI Analyst Threat Tray Options and Filters Show all pinned returned as part of the results, regardless of whether they are within
incidents the timeframe. Turn this setting off to only include pinned incidents
AI Analyst incidents can be further filtered by network subnet and acknowledgement status. that are within the chosen timeframe.
There are no sort or grouping configuration options for AI Analyst alerts as incidents are always Darktrace Threat Visualizer v5.2 introduces a significant development
sorted by severity and grouped by high-level analysis. in the way AI Analyst incidents are grouped. Events are now linked
persistently through meta-analysis, creating incidents with a wider
The current alerts in the tray can be exported as a PDF. To do so, enter a filename under the Legacy Incidents scope that previously possible. Turn this setting on to see incidents
“Export” header and click Download Incidents. created using (pre-v5.2), or compatible with, the legacy method. This
setting is not compatible with all filter options - some filters may be
ignored when enabled.

23
Model Breach Threat Tray Options and Filters
FILTER DESCRIPTION

Model breach alerts have a large number of additional, optional filters. These filters allow an Model breach and AI Analyst alerts can be acknowledged as part
operator to focus in on very specific activity and return to frequent queries using saved filter Include of an investigation workflow. By default, acknowledged alerts are
sets. Acknowledged removed from the returned results. Turn this setting on to include
these results.

If turned on, only model breaches for Darktrace RESPOND (Antigena)

Antigena Only
models will be included.

The sort controls how model breaches are grouped into tiles. There
are four modes: device, model, user, Antigena CTRL. The impact of
Sort By
the sort is covered in more detail in Model Breach Alerts in the Threat
Tray.
In addition to being sorted into folders, models can also be tagged
to group them together. Common examples are the “AP” tags which
Tags map models to attack phases. If a tag filter is added, model breaches
will only be returned if the model has at least one of the chosen tags
applied.
Filters

FILTER DESCRIPTION

A free text filter which will filter results by device or model name. The
Search value of this field is not saved in saved filters and does not persist if
the page is refreshed.
Darktrace models are sorted into folders that categorize the type
of behavior they are designed to detect. When a folder is unticked,
Model Folders
model breaches of models within that folder will disappear from the
tray.
This filter allows devices from specific subnets to be removed from
the returned results. Subnets can be selected from a list or a custom
range (such as 10.0.0.0/8) can be defined. When at least one subnet
Subnets
is selected, the filter can be set to “Include Subnets” (only show
devices from these subnets) or “Exclude Subnets” (remove all devices
from these subnets).

24
CHAPTER 2 - CYBER AI ANALYST

AI ANALYST INCIDENTS

CYBER AI ANALYST 26
CYBER AI ANALYST INCIDENTS 27
INVESTIGATING AN AI ANALYST INCIDENT 28

AI ANALYST INVESTIGATIONS
DETAILS OF CYBER AI ANALYST INCIDENT EVENT 29
UNDERSTANDING HOW AI ANALYST INVESTIGATED 30
LINKING AI ANALYST EVENTS TOGETHER 31
AI ANALYST INCIDENT OPTIONS AND ACTIONS 32
CYBER AI ANALYST

AI Analyst The output from this analysis process are AI Analyst Incidents - a collection of one or more
related events of anomalous activity. Incidents (v5.2+) are formed through a meta-analysis of
AI Analyst incidents are an excellent place to start when investigating alerts for the first time activity type, devices, and endpoints involved in each event. Each incident can encompass
in the Threat Visualizer. Incidents are only created for the most interesting and high priority multiple stages of activity as it develops.
activity observed by Darktrace.
The layer of abstraction means only high priority activity is surfaced.
Incidents are created from AI-powered investigations into anomalies across your digital
environment. Every time the conditions for a model are met and a model breach is created, Incident to Model Breach Relationship
AI Analyst investigates the activity and concludes whether it needs to be surfaced for human
analysts to review. The results of this analysis is then grouped in incidents. Although a model breach may be the trigger for an investigation, that does not mean the
activity AI Analyst surfaces is directly related to the original model breach. Like a human,
What is AI Analyst? the Cyber AI Analyst uses a model breach as a starting point to investigate the device. The
behavioral analysis it performs may discover anomalies or patterns of activity that were not the
The Darktrace AI Analyst investigates, analyzes and triages threats seen within your Darktrace original trigger point for the model breach but are worthy of investigation.
environment. By learning from the millions of interactions between Darktrace’s expert analysts
and Darktrace DETECT components, the AI Analyst combines human expertise with the Similarly, not all model breaches that are investigated will result in an incident - only activity
consistency, speed, and scalability of AI. the AI Analyst considers high priority. A model breach will indicate if an AI Analyst incident was
created as a result. Users who wish to review all alerts raised by Darktrace should also consult
Darktrace models - a logic framework that allows operators to interact with the output from the model breach view.
‘pattern of life’ and anomaly classifiers - are used a trigger to invoke AI Analyst. When the
conditions for a model are met, a model breach is created; AI Analyst reviews and investigate Please note, the Cyber AI Analyst will only investigate model breaches of default Darktrace
all model breaches that occur on the system as a starting point for its analysis process. models. Custom models are not currently supported. From Threat Visualizer v5 and above, AI
Analyst investigations can be triggered by third-party alerts using a dedicated meta-model.
26
CYBER AI ANALYST INCIDENTS

Investigating an AI Analyst Incident

Users can trigger AI Analyst investigations manually if they wish to look into a device’s behavior
AI Analyst is accessible from the c AI Analyst icon in the bottom left of the threat tray. For new in greater detail. If an event or incident was created from an investigation triggered by a manual
users, it will be the default view when they first access the Threat Visualizer. investigation or a third-party alert, this will be indicated on the tile.

Cyber AI Analyst Incidents

An incident is composed of one or more events; events are a group of anomalies or activity
investigated by Cyber AI Analyst that it considers high priority enough to raise to a human
operator for attention. For new users, start with the first incident in the tray with “critical” severity.

Incidents have a behavior category and an overall score from 0-100%. Behavior categories
are high level filters that allow an operator to focus in on specific levels of severity or behavior.
There are three categories for AI Analyst incidents: Critical, Suspicious, Compliance. Categories
are assigned to incident events and the incident is then given the most severe of all underlying
categories.

The score can be used to filter on a sliding scale; incidents are categorized from dark to light
blue, where light blue indicates a high score and darker blue a lower score. The score can be
a useful way to prioritize within a behavior category - for example, starting with “critical” alerts
and investigating from highest to lowest score before moving on to “suspicious”.

For more information about the filter options available, please see Filtering Alerts with Behavior
Categories, Filtering Alerts with Basic Filters and Filtering Alerts with Advanced Filters.

Each alert in the tray lists the initial device (the device that triggered the first activity AI Analyst
detected), the number of events the incident comprises, the number of devices involved
in the incident, and the behavior category. Hovering over a tile will show more details of the
devices and events.

27
INVESTIGATING AN AI ANALYST INCIDENT

An incident is composed of one or more events; events are a group of anomalies or activity At the top of the panel is a representation of the incident time period. We can see that the first
investigated by Cyber AI Analyst that it considers high priority enough to raise to a human three events AI Analyst has highlighted occurred at around the exact same time. The device
operator for attention. For new users, start with the first incident in the tray with “critical” severity. “10.15.0.1” was observed performing potential port scanning, making unusual large uploads
internally and externally at 4:30am. An alternative view is also available from the list-ul incident
Investigating an AI Analyst Incident timeline option on the left.

In this example, the first incident in the tray is a critical incident with 8 underlying events and 8
devices involved. The incident has been initially triggered by the behavior of a desktop device
(“10.15.0.1”). Hovering over the tile, we can see that the incident is mostly unusual data transfer
after potential port scanning activity. The devices involved are a mixture of desktop devices
and servers.

Model breaches which may be associated with each event will appear as dots, where color
indicates severity. The activity associated with the event selected right now will be highlighted
in blue; long-lived events such as large data transfers may cover a large chronological period.

Like a human, the Cyber AI Analyst uses a model breach as a starting point to investigate the
activity. The behavioral analysis it performs may discover anomalies or patterns of activity
that were not the original trigger point for the model breach but are worthy of investigation.
Once clicked, the incident launches a Cyber AI Analyst pane with the results of the analysis and Consequently, the event period may not correspond with the model breach time.
triage. It will open on the first event to occur as part of that incident. In our example, the first
event is port scanning activity. Additionally, some model breaches require sustained behaviors such as repeated connections,
so the final model breach trigger may be later than the connection of interest. For this port
scanning activity, the “Unusual Activity / Multiple Failed Internal Connections” model was
triggered after repeated activity. The activity AI Analyst has identified therefore stretches back
before the model breach.

Events

The next step is to understand the activity AI Analyst has surfaced and understand why it has
been highlighted to a human operator. Each incident is comprised of events which detail a
specific anomalous activity - or chain of activities - investigated by AI Analyst. Each event will
appear as a tab and can be investigated and acknowledged separately.

28
DETAILS OF CYBER AI ANALYST INCIDENT EVENT

Incident Events Event Details

Each incident is comprised of events which detail a specific anomalous activity - or chain of The key details of the activity AI Analyst detected are provided in a series of panels on the right.
activities - investigated by AI Analyst. When starting to investigate an AI Analyst incident, one The type of information is specific to each event type and can differ significantly.
approach is to work through each incident event chronologically. Each event will appear as a
tab and can be investigated and acknowledged separately. Other approaches which prioritize For our example port scanning activity, the right panels
investigating the most high priority activity first may be more suitable, depending on your include details of the scanned IP addresses, port
organizational priorities and workflow. ranges scanned via TCP and port ranges scanned
by UDP. In other examples, the panels may include
detailed information on the location of external
endpoints or rare user agents detected performing
SaaS administration.

Where devices observed by Darktrace are involved

in the event, detailed information about the device
hostname, IP address and any tags will be included.
These details will vary between device. If clicked, this
section will center the Threat Visualizer workspace on
the device.

It can now be helpful to understand how AI Analyst

detected the activity and how it links together with the
other devices detected behaving anomalously.

Continuing the example incident started in Investigating an AI Analyst Incident, the first event
is potential port scanning activity.

Event Summary

The first panel gives a summary of the event outline. The summary describes the type of activity
AI Analyst detected, the device involved, any endpoints connected to and an explanation of
why the activity is anomalous. The summary is the best way to quickly understand the activity
AI Analyst has flagged for human review. Here, the summary explains why port scanning
activity should be of concern to the security team.

The summary can be localized into any of the current 12 options: English (US), English (UK),
Chinese (Simplified), Chinese (Traditional), French, German, Italian, Japanese, Korean,
Portuguese (BR), Spanish (ES) and Spanish (LATAM). This setting can be changed from
Account Settings. 29
UNDERSTANDING HOW AI ANALYST INVESTIGATED

How did AI Analyst reach the conclusions it did? Investigation Process

Incidents are created from AI-powered investigations into anomalies across your digital The investigation process panel is located below the related model breaches and explains
environment. Every time the conditions for a model are met and a model breach is created, how AI Analyst went from the initial trigger to the final activity presented to the user. Reviewing
AI Analyst investigates the activity and concludes whether it needs to be surfaced for human the process can be a useful way to understand the steps performed.
analysts to review.
The Cyber AI Analyst, when triggered by a model breach, by telemetry data or by a human
For each event, AI Analyst explains the activity that initially triggered the investigation and the operator, initiates an investigation just like a human analyst. It retrieves and analyzes data to
investigation process it followed to come to the conclusions surfaced in the Threat Visualizer. identify related behaviors and activity from the device or user under investigation, and from
the wider network environment - just as a cyber analyst would seek to gain context and identify
Related Model Breaches similar patterns of anomalous behavior elsewhere.

Underneath the event summary for an AI Analyst incident event are the model breaches that However, unlike a human analyst, the Cyber AI Analyst
triggered the initial investigation. AI Analyst is not reliant on model breaches, they primarily can analyze vast quantities of data at machine speed
provide a starting point for its deeper analysis of the device activity around the anomaly time. and investigate potential hypotheses concurrently. It
can perform complex data interrogation on a scale and
A comment-lines comment icon indicates if any related model breaches have been commented on by a a complexity not possible without AI. The investigation
user. These can be reviewed in the incident discussion. process panel displays a summary of this intelligent
analysis process followed by AI Analyst to reach the
Further investigation prioritize the anomalous activity signposted by Cyber AI Analyst first and conclusions displayed in the event.
the model breach conditions second if the two do not directly align. For each model breach, a
series of actions can be performed. As the investigation process proceeds, AI Analyst
narrows down the activity from a wider analysis to
ICON DESCRIPTION a targeted anomaly. Each investigation blends AI,
supervised machine learning and intensive data
This icon opens the model breach log for the related model breach. The Model
analysis. These smart steps are identified in blue - “head-side-brain
exclamation-triangle breach log is covered in great detail in a series of articles, starting with Opening
Carrying out intelligent data analysis”.
the Model Breach Log.
Opens the model breach event log. Model breach logs are covered in more detail As noted before, the behavioral analysis AI Analyst
align-justify
in Exploring the Model Breach Event Log. performs may discover anomalies or patterns of
Center the Threat Visualizer on the device that triggered the model breach at the activity that were not the original trigger point for the
search
time the model breach occurred. model breach but are worthy of investigation.

30
LINKING AI ANALYST EVENTS TOGETHER

The final step is to understand how the activity detected by AI Analyst in the event fits in with Switching to the final event - “Unusual External Data Transfer” - we can see from the linked
the wider incident. incident events panel that it has been connected to the “Unusual External Data Transfer to
Multiple Endpoints” due to a shared external destination. “Unusual External Data Transfer
Threat Visualizer v5.2 introduces a significant development in the way AI Analyst incidents are to Multiple Endpoints” was performed by “10.15.0.1”, the same device that was observed
constructed. New, ‘open’ incidents are created by a meta-analysis of the devices, endpoints performing the port scanning. Therefore, the activity has been linked together indirectly
and activity involved in each event. Events with linking factors are then joined together through this shared endpoint.
persistently to create incidents encompassing a much wider scope of time and activity.

Linked Incident events

The linked incident events panel displays the reasons why AI Analyst chose to link certain
behaviors together.

• The port scanning behavior has been

connected to an “Unusual Internal Upload”
and “Unusual External Data Transfer to Multiple
Endpoints” because they were all performed by Returning to the example incident from Investigating an AI Analyst Incident and Details of
the same device (“10.15.0.1”). Cyber AI Analyst Incident Event, eight events have been connected together.

• This “Unusual Internal Upload” was also to Incidents within Incidents

an IP address seen in the scanning activity
(“10.10.5.213”), which was then observed Incidents can also be subsumed into other incidents - what might appear as disparate
receiving an “Unusual Internal Upload” and behavior initially can be linked by subsequent unusual activity. In this case, the later behavior is
sending data which triggered two instances of subsumed into the initial incident. Links to the later incident will redirect to the initial incident.
“Unusual Internal Download”.
In a simplified example, device A is seen beaconing to two external rare endpoints. Device B
• Finally, another IP observed in the scanning is separately seen performing a chain of administrative SSH connections that end at a key
behavior was seen performing an unusual server. These activities trigger separate investigations and result in two separate incidents.
“Internal Download and External Upload” Subsequently, the credential admin12 is observed on device A and triggers an investigation
for unusual admin credential use. At the same time, the credential admin12 is also seen on
Seven events have therefore been directly linked to the server connected to by device B, triggering an investigation for unusual admin credential
the activity in this event. Some events may not have use. The event for device A and device B are now linked by a shared admin credential -
a direct link to others and are instead linked through a admin12 - and their previous activity is drawn into one overall incident. Where the beaconing
shared event that draws the behavior together. and administrative connections were disparate events at first, the linking credential allows AI
Analyst to present the full picture: device A and B are compromised by the same actor, and
device Bs connectivity is lateral movement associated with that compromise.

31
AI ANALYST INCIDENT OPTIONS AND ACTIONS

To investigate an AI Analyst event, the next step is to look more closely at the activity and
ICON DESCRIPTION
devices involved. Before focusing on a device, it is necessary to understand the actions and
investigation steps that can be taken in the AI Analyst incident pane itself. A flashing Cyber AI Analyst icon indicates that it is currently analyzing
other model breaches that may be relevant. If this analysis deems
c Breaches
Incident Actions the breaches related to the incident, Cyber AI Analyst will create
Processing
additional events. Click the icon to expand the list of processing
breaches.
On the left of the incident panel are a series of actions and views. During initial investigation,
the incident timeline can be used to understand the order of events and filter down by specific This option opens a timeline of all events and their trigger device - it
devices. The attack phases also visualizes the events alongside the stages of a cyber attack is useful to quickly understand the chronology of the incident and
list-ul Incident
they may represent. find events that occurred around the same time. A device filter can be
Timeline
applied in this pop-out which also applies to events returned in the
main panel.

Open a visualization of the events alongside the stages of a cyber

angle-double-down Attack Stages
attack they may represent.

Opens the comment pane where users can discuss the incident.
comment View Incident Comments on related model breaches will also be displayed in the
Discussion discussion. Users may comment from the Threat Visualizer interface
as well as the mobile app.
Opens a dialogue to create a downloadable PDF report from the
download Create a Report incident. Any text entered into the “Report Name” field will be used as
the filename and appear as a title in the generated PDF.
Keeps the Incident at the left-hand-side of the threat tray regardless
of the time range chosen. When the incident is pinned, the tab will
thumbtack Pin the Incident appear lighter. Individual events may also be pinned - if one or more
events are pinned, the entire incident will be pinned. Pinned incidents
do not interact with the pinned model breaches functionality.
This icon will acknowledge all underlying events for the incident at
Pinning the incident, commenting or downloading a PDF report can be useful for collaboration the time of click. If all events are acknowledged, the incident will be
with other analysts on event investigation. check Acknowledge shown/hidden from the incident tray depending on the filter settings.
Incident Events can also be acknowledged individually as part of an incident
investigation workflow - some individually acknowledged events do
not prevent the overall incident being returned.

copy Copy to
Copies a link to the incident to the clipboard.
Clipboard

32
Actions for an Event Investigating activity

On each event are a series of actions that can be taken. These actions only affect the chosen Once the outline of the event and incident as a whole is clear, focus on a device within the
event or related alerts. incident to better understand its normal activity patterns and gather context about its role in
the digital environment. Investigating a device is introduced in Focusing on a Device.

ICON DESCRIPTION

Events can be acknowledged individually, rather than as part of

check Acknowledge
the whole incident - this is a common workflow as a threat analyst
this event
investigates each underlying event in turn.
check-double Acknowledge
In addition to acknowledging this event, this icon will also
this event and
acknowledge the model breach alerts listed under the “Related
related model
Model Breaches” heading.
breaches
Click this icon to pin or unpin just this event. Incidents with at least
thumbtack Pin/Unpin
one pinned underlying event will be returned regardless of whether
incident event
they fall within the time range chosen.

Incidents and events can be acknowledged when they have been investigated. This removes
them from the threat tray by default. A common workflow is to investigate each event and
acknowledge individually.

33
CHAPTER 3 - INVESTIGATING A DEVICE

FOCUS ON A DEVICE

FOCUSING ON A DEVICE 35
DEVICE INVESTIGATION OPTIONS 36

DEVICE EVENT LOGS

DEVICE SUMMARY 37
OTHER DEVICE SUMMARY SECTIONS 39
USING THE DEVICE EVENT LOG 41
TYPES OF EVENT IN THE DEVICE EVENT LOG 42
INVESTIGATING A CONNECTION IN THE DEVICE EVENT LOG 43
INVESTIGATING SAAS ACTIVITY IN THE DEVICE EVENT LOG 44
FILTERING THE DEVICE EVENT LOG 46

OTHER INVESTIGATION METHODS

TRIGGERED AI ANALYST INVESTIGATIONS 47
OTHER DEVICE INVESTIGATION WINDOWS 48
FOCUSING ON A DEVICE

Investigating a Device

Focusing on a device is the next stage in any investigation workflow. To understand whether an re-enactment of connections will resume. Clicking on any other device will change the focus
anomalous activity might be malicious, it is important to understand the device and to acquire to it.
context about its historic behavior.
The color of the device is decided by the highest severity of model breaches that it has
There are many ways to focus the Threat Visualizer workspace on a device. Three common triggered in or around the time selected in the top right. A green square around the device
methods are: indicates it has been recently subject to a Darktrace RESPOND action.

• From an AI Analyst incident event, click the device name in blue above the graph. Click The icon for the device is decided by its device type. Device type is derived by Darktrace from
the time in the same subheading to also set the Threat Visualizer to that exact time. observation of the device behavior - it can be overwritten in Device Admin (see Device Admin)
or from the icons in the omnisearch bar (see below).
• From a model breach log, click the search magnifying glass icon. This will center the Threat
Visualizer on the device that triggered the model breach at the time of the model Below the device options are any tags that have been applied to the device. Tags offer a simple
breach. labelling system for network devices, credentials and users detected in external platforms
(SaaS users) which can be used to identify important resources, control eligibility for Darktrace
• From the subnet view, click any glowing point that represents a device. RESPOND responses and alter model logic . More information can be found in Adding and
Reviewing Tags.
Workspace
On the right of the workspace is a panel with statistics about the device’s connections over the
The workspace will change. In the center is a visualization of the chosen device and any other time window chosen in the selector. The time window is shown below the timezone. By default,
devices it is connected to at the time chosen. The time in the selector at the top right controls the time window is 5 minutes.
the visualization. If the play play button is clicked on the time selector, time will progress and the
35
DEVICE INVESTIGATION OPTIONS

Device Options ICON

APPLICABLE
DESCRIPTION
TO
At the top of the workspace, in the omnisearch bar, the device focused upon is shown. The bar This icon opens the device summary, a key window
displays the device label, hostname and IP address, where available. For SaaS user devices, for understanding statistics about a device and its
the device name is displayed in the format [SaaS::][service] [username]. For devices Device
Device Summary
Summary All historic behavior. Device summary is covered in
monitored by Darktrace DETECT & RESPOND/Endpoint agents, only the hostname and label more detail in Device Summary and Other Device
are displayed as the device may have many concurrent IPs. Summary Sections.
The device event log is a detailed log of device
connectivity, activity, changes, and anomaly
notifications from Darktrace analysis. it is a key
align-justify Device Event Log All
investigation tool. The device event log is covered
separately in more detail, starting with Using the
Device Event Log.
On the left of the device name is an icon representing the device type. The device type is
automatically derived and can be manually overwritten. This icon opens the device breach log for the device
- a list of model breaches triggered by the device.
exclamation-triangle Model Breach Log All The default timeframe is 7 days but can be altered.
To the right of the device name are a series of icons; these icons and options will differ
Breach logs in general are covered in more detail in
depending on the type of device.
Viewing a Model Breach.

Device Options For network and endpoint devices, this option

allows a label (or nickname) to be set for the device.
APPLICABLE Network, The device type and priority can also be altered. The
ICON DESCRIPTION pencil Edit Info
TO Endpoint priority impacts the score for models the device
AI Analyst investigates anomalous activity in your triggers. These settings can also be changed for
digital environment, surfacing only the most high multiple devices in Device Admin.
priority findings. Users can trigger their own AI The graph allows metrics of device behavior to be
c AI Analyst
All Analyst investigations into devices and users plotted over time. The default metric for non-SaaS
Investigation Open Graph
detected in external platforms (SaaS users). Open Graph All devices is connections and activity for SaaS devices.
This icon opens a dialog to trigger an AI Analyst The graph is described in more detail in Other
investigation into the focused device. Device Investigation Windows.
Darktrace RESPOND takes autonomous actions
against devices to control and contain anomalous The Darktrace SaaS Console is a purpose built
behavior. This option opens the Darktrace Antigena id-badge Open Profile in SaaS interface for investigating SaaS and cloud user
Actions window, focused on the device. The default SaaS
a Antigena Actions Console behavior. This icon opens the equivalent user profile
timeframe is 7 days but can be altered. For user in the SaaS console to continue investigation there.
(Darktrace RESPOND All
devices, this window can also be used to trigger
Actions)
manual Darktrace RESPOND actions against the
View Connections The connections data window visualizes the
user account for eligible modules. It will not appear
View Connections
Data Network, connectivity of a chosen device against those
for users of modules which do not have Darktrace
Data Endpoint Darktrace has derived as peers. This is described in
RESPOND available.
more detail in Other Device Investigation Windows.
36
 DEVICE SUMMARY

APPLICABLE When investigating a device, it is important to understand the context of how it behaves and
ICON DESCRIPTION
TO where it fits within the network. Device summary is a key tool for gathering this information
For every device, Darktrace identifies peer devices quickly. It displays key information about devices, their historic behavior, any acknowledged or
- those it derives as having a similar pattern of life. unacknowledged alerts and similar peer devices.
View Similar The similar device map is a 3D visualization of these
View Similar
Device Map Device Network,
similar devices, clustered by how similar they are. The timeframe for connectivity data is 1 month and 7 days for credential history. For summary
Map Endpoint
The list of peer devices is also available in device data and interface data, the information is the most up to date at the time the summary is
summary and by clicking the “view similar devices” opened. The timeframe for other elements can be altered on the section itself.
option.
As above, for every device, Darktrace identifies peer Summary
View Similar Network, devices - those it derives as having a similar pattern
View Similar Devices
Devices Endpoint of life. This option opens a clickable list of similar The summary section appears for all device types. It contains key information such as IP
devices.
address, hostname, the time the device or user was first seen, the device priority and any tags
Network, Returns the focus to the subnet view for the subnet applied to it. The information that appears in the summary differs between network, endpoint
square-full Go to device subnet and SaaS devices. For example, devices monitored by Darktrace DETECT & RESPOND/
Endpoint the device is in.
Endpoint cSensor agents will include information about the software version of the agent itself.
d c Monitored by This icon is not interactive - it indicates that the
Darktrace Endpoint Endpoint device is monitored by a Darktrace DETECT &
agent RESPOND/Endpoint cSensor agent.

Darktrace will attempt to derive operating system information for a device from passive
observation of its behavior and display it in the summary. For devices monitored by Darktrace
DETECT & RESPOND/Endpoint cSensor agents, this information will be populated directly
by the agent. The Darktrace Defender Advanced Hunting integration also populates OS
information for devices observed by both Darktrace and Microsoft Defender in the summary.
37
IPs, Credentials and ASNs

Device summary populates information about recent IP addresses, credentials, ASNs and
interfaces associated with the device. Credentials associated with network or endpoint devices
will be displayed first, if present. The historic information will differ between network, SaaS and
endpoint devices and will only be returned where possible. For example, if no credentials have
been associated with the device, this subsection will not appear.

For SaaS user devices, ASN history - the ASNs for IP Addresses seen connecting to the SaaS
account - is provided. An ASN is a group of IP addresses controlled by one Internet Service
Provider or entity. As SaaS activities are often performed by users on mobile devices or
tethering to mobile devices, their IP may change regularly but the ASN will stay consistent.
Greater variation in IP address is therefore not as indicative of anomaly as large changes in
ASN usage. Click the align-justify log icon to open a log of activities for the user from that ASN.

Historic IP information is displayed for network devices - the timeframe can be extended up
to 6 months. For each IP change, the reason why a new IP was associated with the device is
provided. Devices monitored by Darktrace DETECT & RESPOND/Endpoint cSensor agents
can have multiple concurrent IPs due to multiple network adapters - instead, details of all
network interfaces observed by the cSensor agent (both IP and MAC Address) are listed.

38
OTHER DEVICE SUMMARY SECTIONS

Alerts
To switch Threat Visualizer focus to one of these similar devices, click the search magnifying glass
Device summary lists all historic AI Analyst incidents and model breach alerts for the device, icon beside the device name. To view model breaches triggered by the peer device, click the
separated into acknowledged and unacknowledged. The default timeframe is one week but exclamation-triangle model icon.
can be extended to 6 months, data dependent.
Connectivity

For network and endpoint devices, a breakdown of the top five endpoints and ports the device
has connected to/from will be displayed. This data is calculated over the last month.

For model breaches, hover over the model name for a description tooltip. Click the exclamation-triangle model
icon to view the model breach log for the model and the selected user.

For AI Analyst incidents, click the c AI Analyst icon to open the incident event.

Other Sections
Similar Devices

A list of similar peer devices is returned for network and endpoint-monitored devices. Similar
devices are devices Darktrace has derived as having a similar ‘pattern of life’ - the list is also
accessible from “View Similar Device Map” and “View Similar Devices” in device omnisearch
options.

39
Vulnerability Data

If the Darktrace Defender Advanced Hunting integration or integrations with Tenable and
Rapid7 vulnerability scanners are configured, CVE data for devices observed by both platforms
will be populated in an additional device summary section.

globe-americas Geolocation

For SaaS user devices, an additional tab is displayed. The location tab displays a map of the
approximate geolocation for all IP addresses that have performed SaaS or cloud activities for
this user in the last month.

IP Addresses are grouped by ASN and the ASN location is represented as a point on the map.
Light blue locations indicate sustained activity and dark blue locations are those which are
rare for the user.

40
USING THE DEVICE EVENT LOG

The device event log is a detailed list of activity and connections in chronological order. When OPTION DESCRIPTION
investigating an alert, reviewing the behavior of the device before and after the alert can be
useful to acquire important context. This options opens the Darktrace Advanced Search interface to
search-plus View advanced explore a more detailed version of the event or connection log for
search for this granular analysis For some events there may be more than one
Understanding the Device Event Log
event search result with additional contextual information. More information
about Advanced Search can be found in Darktrace Advanced Search.
Each log entry is sorted in time order, working backwards from the time selected in the top
right. Each log entry describes the device and the activity performed. For network devices, this arrow-to-bottom Create a packet Opens a dialog to create a packet capture device for the specific
capture file for this chosen connection (see Creating Packet Captures). This option is not
might be a connection from the device IP to a specific host on a specific port. For SaaS user
event available for SaaS user devices.
devices, the log is structured to show the action, the user and the location it was performed
from. The event log also contains contextual information like changes to device information, If the Darktrace Defender Advanced Hunting integration is configured,
commentary from Darktrace anomaly detection and model breaches triggered. users can request process data from Microsoft Defender for
info-circle Search
connection events. This option will only appear for connections
Defender for
older than 15 minutes for devices observed by both Darktrace and
Process Details
Microsoft Defender. For more information, please see Darktrace
Microsoft Defender Advanced Hunting Integration.
If the Darktrace Defender Advanced Hunting integration is configured,
users can request a list of users who logged into the device around
user Search Defender the time of the activity from Microsoft Defender. This option will
for User Logins only appear for devices observed by both Darktrace and Microsoft
Defender. For more information, please see Darktrace Microsoft
Defender Advanced Hunting Integration.

copy Copy to
Copies the exact log line to the clipboard.
clipboard

This option opens a 3D visualization of historic similar connections

history Visualize such as those on the same port, those to the destination device and
connection history those for the connection pair. This option is not available for SaaS user
devices.
Multiple options to filter the log by specific aspects of the connection
filter Filter Event Log
Between the time stamp and log line is an caret-down arrow icon with extra options: will appear. Granular filters can be applied to the event log to focus on
by this [protocol/
specific behavior; these are discussed in more detail in Filtering the
port/IP]
Device Event Log. This option is not available for SaaS user devices.

41
TYPES OF EVENT IN THE DEVICE EVENT LOG

Entry Types

There are seven “types” of event that can appear in the logs - these events can be filtered on
or excluded to focus on specific activity.

TYPE DESCRIPTION

Connection entries are indicated by an arrow. A long-arrow-left left-facing arrow

indicates the connection was outbound. A long-arrow-rightright-facing arrow
Connections indicates the connection is inbound. An arrow with a cross indicates a
failed connection. A flashing arrow means the connection is ongoing
at the Threat Visualizer time selected.
Unusual connections are displayed in the same manner as
Unusual
connections but include commentary below the log line with the
Connections
reason Darktrace has deemed the connection unusual.
New connections are displayed in the same manner as connections
New connections but include commentary below the log line describing why it has
been identified as new.
Unusual activity entries are indicated by the d Darktrace logo.
Darktrace monitors behavior metrics for each device as part of
Unusual Activity the pattern of life. If the value of one of these behavior metrics is
anomalous, an unusual activity entry may be added to the device
event log. The metric is clickable and will open the metric graph.
Model breach entries are indicated the triangle icon. If a device
triggers a model breach during the timeframe of the log, an entry is
created. The model name can be clicked to open the model breach
Model Breaches
log for further investigation. Some models can be triggered without
creating a model breach; these models will also be returned but with
limited information.
Notices are indicated by the info-circle info icon. Notice entries can be events
or contextual information - SaaS user activity falls under this category.
Notices
Clicking the info icon will open a detailed tooltip. Notices can be
“popped out” to refer back to.
History entries are indicated by purple text. History events are created
History when information about the device changes, such as IP, contextual
information and credential usage.

42
INVESTIGATING A CONNECTION IN THE DEVICE EVENT LOG

Investigating a Connection Entry

A typical network or endpoint device will have a log made up mostly of connection events.
Connections are indicated by an arrow pointing in the direction of the connection. Each
connection entry is broken up into important parts.

For example:

• If the source or destination is an internal device, hover over the name of the device for
a summary tooltip with basic information about the device. Click the device name to
change the Threat Visualizer focus to this other device.

• If the source or destination is an external hostname, multiple interactions are available:

• Hover over the endpoint or host for a summary tooltip with basic information about
long-arrow-left ws123.holdingsinc.com was still connected to darktrace.com via proxy.holdingsinc.com the rarity of the endpoint in the context of the network.
[443]
• Click the external-link-alt link icon to open the external sites summary. Similar to device summary,
First is the connection direction - a long-arrow-left left-facing arrow indicates the connection was outbound, this summary gives information devices that have connected to the external
a long-arrow-right right-facing arrow indicates the connection is inbound. An arrow with a cross indicates a location. More information is available in External Sites Summary and External Sites
failed connection. A flashing arrow means the connection is ongoing at the Threat Visualizer Summary for IPs and Hostnames.
time selected.
• Click the hostname or endpoint name to open an additional event log focused on
Click the direction arrow for detailed information about the connection such as source and that host.
destination IPs, data transferred and protocol. This info can be “popped out” in a separate
window to refer back to. • If workflow integrations that allow lookups for external IPs and hostnames are
enabled (such a VirusTotal), a exclamation-circle pivot icon will appear for these entries.
Next, hover over the name of the device for a summary tooltip with basic information about the
device. The first device in the log line should be the device currently focused on. If a proxy is in use, it will appear here as a “via”.

After the device is a simple description of the connection status. Examples include “connected Finally, depending on the color coding chosen, extra information such as protocol, port or
to”, “made a successful DNS request for”, “was blocked from connecting to”. The connection rarity may be displayed at the end of the log line. For network connections, color coding is
direction is part of this status: “was still connected to by” indicates our chosen device is the available by protocol, application protocol, source/destination port, by notice and by endpoint
destination, “connected to” means it was the source. rarity. The default color coding is controlled in user Account Settings or can be altered using
one of the filter options.
Following the status is the endpoint, device or host that was connected to (or the device was
connected to by). 43
INVESTIGATING SAAS ACTIVITY IN THE DEVICE EVENT LOG

Investigating a SaaS Activity Entry (Notice)

Log lines for SaaS and cloud users are structured slightly differently to connection events. The
log lines take the format of event, actor, resource, source. For example:

info-circle Login performed by [email protected] - from 172.217.169.36 (ASN

Example ASN)

info-circle FileUploaded performed by [email protected] on Document.docx -

from 172.217.169.36 (ASN Example ASN) [File] After the event is the actor - the user who performed the action (“performed by”). In most
cases, this user will be the same user the Threat Visualizer is focused on. However, users can
info-circle Update User performed by [email protected] on User isabella.west_admin@ also change things about other users such as an admin changing their permissions. In this
holdingsinc.com - from 172.217.169.36 (ASN Example ASN) case, the SaaS user device currently focused on is the resource being changed. These events
will appear with the user who performed the action as the actor, and the chosen device as the
The info-circle info icon that appears first can be clicked to open a tooltip with detailed information resource. Color coding the log by actor can be a useful way to identify these inbound events.
about the event, the user and the resource that was changed. This info can be “popped out” in Click the actor to change the focus of the Threat Visualizer.
a separate window to refer back to.
If the action impacts a resource such as a folder, a calendar invite, a user, a file - this will
Users can perform a wide range of actions across different SaaS platforms; for ease, events appear next. The resource can also be the user currently focused upon if another user does
are grouped into high level categories such as “SaaS Login” or “SaaS Resource Modified”. something to affect them. Color coding the log by resource will also add the resource type in
Click the event to open an event log of all actions in the same category across all users. The square brackets at the end of the line.
SaaS-specific “event” color coding allows rare events to be distinguished amongst frequent
logins or file actions.

44
The final interactive part of the log is the source IP. Both the IP and the ASN are listed. Users
using mobile devices or private home networks may have natural variation in source IP but a
stable ASN. ASN variation is therefore a better gauge of anomalous location than change in
source IP for users detected in external platforms (SaaS users).

• Click the external-link-alt link icon to open the external sites summary. For SaaS source locations, the
external sites summary focuses on an ASN and user pair. More information is available
in External Sites Summary and External Sites Summary for SaaS Activity.

• Click the IP itself to open an additional event log focused on that IP.

45
FILTERING THE DEVICE EVENT LOG

Filtering the Log Information Advanced Filters and Options

When you are familiar with the parts of each log line, the next step is to filter the log to focus on ICON DESCRIPTION
just the information and activity of interest. At the top of the event log several device-related
The device event log displays activity logs going backwards
options are available. The options that appear will vary depending on your environment and
history Unsync from chronologically from the time selected in the top right. If the time is
the makeup of network traffic or user activity returned by the log:
Threat Visualizer time changed, the log will change. Unsyncing the log allows the time to
be changed whilst still preserving the logs.
ICON DESCRIPTION
Unsync
Unsync loglog
fromfrom The connection panel on the right of the workspace can be filtered
This icon allows a text filter to match against fields such as hostname, Threat Visualizer
the Threat Visualizer to show specific ports or hostnames. These filters are also applied
application protocol and ASN in the log entries. Only one filter of filters to the event log unless it is unsynced.
each type can be defined.

Remove filters This icon will appear if filters are applied and can be used to remove bars Hide duplicate If a device repeatedly connects to an endpoint, this filter restricts
Remove filters connections the log to show only one entry per-endpoint and port.
the current filter set.

The device event log includes many different types of event; the filter Darktrace anomaly detection may add commentary to events that
align-left Hide event
limits the log to just specific types of events, or filters out specific are deemed unusual. This filter hides those comments inline in the
descriptions
event types. The log can be filtered to show or exclude all network event log.
filter Choose which
connections, new connections, unusual connections, connections Limit events in the log to those that transferred over a defined
type of events to greater-than Any Size
blocked by Darktrace RESPOND, changes to device information threshold of data.
show in the log
(“history”), model breaches triggered by the device, and contextual
information or activity (“notices”). SaaS user activity is always of the This icon opens the Darktrace Advanced Search interface to
“notice” type. explore a more detailed version of the event log for granular
Choose
Choose whether
whether search View advanced analysis. By default, the search is limited to the device IP over a
toshow
to showinternal
internalor
or For connectivity, filter the log to show only events to/from internal search period of 1hr before the Visualizer time selected. More information
externalevents
external eventsin
in endpoints, to/from external endpoints, or both. about Advanced Search can be found in Darktrace Advanced
thelog.
the log. Search. This option is not available for SaaS or endpoint devices.
Opens a dialog to create a packet capture device for connections
Toggle
Toggle incoming/ Filter the log to only incoming connections, outgoing connections or to/from the device IP over a chosen time window (see Creating
incoming/outgoing
outgoing events both. arrow-to-bottom View packet Packet Captures). For devices monitored by Darktrace DETECT &
events capture RESPOND/Endpoint agents, the interface IP for which the capture
should be created must be selected first. This option is not
Color-code the event log lines by the specific filter. Doing so will available for SaaS user devices.
add additional details after the event line. For example, coloring by
palette Color-code
port will add the port in square brackets (e.g. [443]). Default color
events by their
coding is controlled in each user’s account settings. Event logs for
properties
SaaS user devices will present different filtering options specific to
SaaS activity.

Provides access to advanced options and filters. Refer to the table

ellipsis-v Advanced options
below for more information.
46
TRIGGERED AI ANALYST INVESTIGATIONS

Investigating a User or Device

To trigger an AI Analyst investigation, a device or SaaS user and a time are required. The Current and completed investigations can be reviewed by navigating to AI Analyst
device is the subject of the investigation and the time is the starting point for analysis. Investigations > View Investigations in the main menu.

In the Threat Visualizer, the c AI Analyst Investigations item is available from the main menu.
The c Launch Investigation item will open the investigation dialog without a device selected.
Here, the field acts as a search bar which can be used to locate the device for investigation.

When an investigation is triggered, AI Analyst will perform a close analysis of the activity for
the device or user for a period of roughly one hour, using the time provided as a central point.
It will then contextualize this behavior against historic activity and connectivity for the entity
and its peers. If a finished investigation has the result “No Incident Found”, AI Analyst did not
locate any identifiable anomalous activity around the investigation time. If anomalous activity
is detected, one or more incident events will be created.

In the Threat Visualizer interface, click the eye Incident button to open the investigation result.
Incidents created from triggered investigations follow the same format as AI Analyst incidents
created automatically.
An AI Analyst investigation can be triggered on a specific device from the omnisearch bar
in the Threat Visualizer with the c AI Analyst icon. When an investigation is launched from a For details on triggering AI Analyst investigations from third-party alerts, please see AI Analyst
specific device or SaaS profile, the Device or Account field is already completed. Third Party Investigations or the Darktrace System Administration Guide.

Click Investigate to start the investigation.

Investigations

Investigations display the device or user under analysis, the analysis time, the user who
triggered the analysis and the current investigation state.

Investigations have three states - pending, processing, finished. A pending investigation

waiting for AI Analyst to start the analysis. A processing investigation means analysis is
underway and a finished investigation means the investigation has concluded.

47
OTHER DEVICE INVESTIGATION WINDOWS

Other Investigation Windows Connections Data Visualization

After consulting the device summary and event log, many users move on to close examination This option visualizes historic connectivity for the device. It is only available for network and
of activity using the Darktrace Advanced Search interface. However, there are additional endpoint devices.
investigation views for a device that can be useful for gathering further context of normal
behavior. The primary graph displays the device behavior over the last week - number of connections
or data transfer volume - in the context of peer devices. Device similarity decreases from front
Metric Graph to back.

The graph can be used to plot device behavior over time for a number of metrics and against Two additional graphs display port and device breakdown for the connectivity visualized. The
model breaches the device has triggered. The default metric for network and endpoint main graph can be further filtered by clicking on ports or devices represented on the two
devices is “Connections”, for SaaS user devices it is “SaaS All” (all SaaS activity). donut charts.

The time period, number of devices, and display mode of the graphs can be customized.

Up to two metrics can be displayed on the graph. To add an additional metric, click the plus plus
icon. For metrics with in/out values such as data transfer and connectivity, click the eye eye
icon beside the direction to show or hide it.

The time range defaults to center around the time selected in the top right of the Threat
Visualizer. The window can be changed using the dropdown or by clicking and dragging
across the graph. Clicking on the graph when a time tooltip is shown will change the time in
the selector to the clicked time.

If model breaches are shown on the graph, these points are clickable and will open a model
breach log for the model breach chosen.
48
CHAPTER 4 - DARKTRACE MODEL BREACHES

MODEL BREACH ALERTS

DARKTRACE MODEL BREACHES 50

MODEL BREACH ALERTS IN THE THREAT TRAY 51

MODEL BREACH LOGS

OPENING THE MODEL BREACH LOG 52
MODEL BREACH LOG OPTIONS AND FILTERS 53
ENTRIES IN THE MODEL BREACH LOG 54
UNDERSTANDING WHY A MODEL BREACH WAS CREATED 55
UNDERSTANDING EXAMPLE MODEL BREACH LOG ENTRIES 56
ACTIONS FOR MODEL BREACH LOG ENTRIES 57
EXPLORING THE MODEL BREACH EVENT LOG 58
DARKTRACE MODEL BREACHES

What are Model Breaches Model breaches have a behavior category and an overall score from 0-100%. Behavior
categories are high level filters that allow an operator to focus in on specific levels of severity
Darktrace models are a logic framework that allows operators to interact with the output or behavior. There are four categories for model breaches: Critical, Suspicious, Compliance
from ‘pattern of life’ and anomaly classifiers. Models are primarily used to identify and alert and Informational.
on anomalous and potentially malicious behavior. When conditions for a model are met, this
creates a model breach and can trigger an alert or action. The score can be used to filter on a sliding scale; where a yellow line and icon indicate a
low score and red a high score. The score can be a useful way to prioritize within a behavior
AI Analyst already investigates every model breach that occurs on the system and reports only category - for example, starting with “critical” alerts and investigating from highest to lowest
the most interesting activity as incidents. Users who wish to dive down deeper and investigate score before moving on to “suspicious”.
specific behaviors after investigating AI Analyst incidents can move to the model breach view
of the threat tray. The information displayed on the tile will change depending on how model breaches are
grouped. If model breaches are grouped by device or user, the highest category and highest
Threat Tray score of the underlying model breaches for the device will be displayed.

When the threat tray is switched to model breach view, model breach alerts appear as tiles. For more information about other filter options available, please see Filtering Alerts with
Each tile will list the number of model breaches that have been grouped together. Behavior Categories, Filtering Alerts with Basic Filters, and Filtering Alerts with Advanced
Filters.

50
MODEL BREACH ALERTS IN THE THREAT TRAY

Model breaches can be grouped in a number of different ways - this is controlled by the Sort • If sorting by model is chosen - indicated by the exclamation-triangle icon - the name of the model that
By option in the filter panel. There are four options: was triggered is shown on the tile.

• Devices groups model breaches by device. • If sorting by user (credential) is chosen - indicated by the user user icon - the credential
that was associated with the device when it triggered the model breach is displayed.
• Models groups model breaches by the model that was breached.
• If sorting by device or Antigena Ctrl is chosen - indicated by a desktop device type icon - the
• Users groups model breaches by the credential associated with the device (if name of the device that triggered the grouped model breaches is displayed on the tile.
applicable) at the time the model breached. It also restricts the results returned to The device type is also indicated by the icon on the tile.
just model breaches for devices that had a credential associated within the timeframe
selected. Hover over a tile to open a tooltip with more information about the model breaches or devices
that were grouped:
• Antigena Ctrl groups model breaches by device. It also restricts the results returned to
just model breaches for devices that experienced a Darktrace RESPOND Action within • If sorting by device, user, or Antigena Ctrl, the hover will show the names of models that
the timeframe selected. were triggered and the time that the model breach occurred.

Within each option the results can be ordered alphabetically, by score, time, quantity and • If sorting by model, the names of the network or SaaS user devices that triggered the
number of user comments. When grouped, each tile will show the highest score and most model breaches are listed with the time that the model breach occurred.
severe behavior category for the underlying alerts.
Each entry in the tooltip is clickable to open a model breach log focused on only that one
Individual Tiles occurrence. If the tile itself is clicked, a model breach log with all grouped model breaches is
opened instead.
The information displayed on the tile will change depending on how model breaches are
grouped. Tiles will always display the highest underlying category, highest underlying score, The next step is to understand the model breaches and the log itself.
number of grouped model breaches and the number of comments made by users on
underlying model breaches.

51
OPENING THE MODEL BREACH LOG

Model Breach Logs In this example, the log has been opened from a threat tray tile for the device “SaaS::Dropbox:
[email protected]”. The log has opened filtered on that specific device. If a
Models are primarily used to identify and alert on anomalous and potentially malicious model breach log is opened from a tile grouped by device, it will open focused on the device.
behavior. Models can also be used to profile a device, assign tags, highlight misconfigurations If alerts are grouped by model, clicking a tile will open a model breach log focused on the
or trigger autonomous responses from the Darktrace RESPOND framework. individual model.

Model breach logs contain a list of model breaches for a model, a device or a subnet over a • A model breach log filtered on a device will display the device name and type in the top
chosen time window. Each entry in the log is an instance where the criteria for a model were left as a heading. Click the device to change the visualizer focus to the device.
met by a entity in your digital environment.
• A model breach log filtered on a model display the name of the model as a heading.
Reviewing the model breach log for a device can, for example, be valuable in understanding If enabled in account settings, the model description will appear below. Collapse the
the low-level anomalies that it displayed before a significant incident. Similarly, reviewing the description using the angle-up arrow icon.
model breach log for a compliance model is a simple way to view all non-compliant devices.
Underneath is the time range for model breaches to be included in the log. The default range
Breach Log is taken from the current threat tray filter but can be altered using the time selectors.

Starting from the threat tray, click on one of the breaches to open the Breach Log. The breach The log can also be filtered to show only unacknowledged model breaches, only acknowledged
log can be opened from any location - including from a Cyber AI Analyst incident - where the model breaches, or both states of model breach. By default, acknowledged alerts are removed
exclamation-triangle icon appears. from the returned results. Most investigation workflows include acknowledging an alert after
it has been investigated. For a device, it can be helpful to review anomalous behavior already
investigated by other analysts when trying to understand the background to a more severe
model breach.

52
MODEL BREACH LOG OPTIONS AND FILTERS

Log Options ICON DESCRIPTION

Above the log entries are a series of filters and actions. These options are particularly useful to Focus the log on a specific device, model breach ID or metric with
filter Add/remove
filter the log when there are many model breach entries returned. custom filters custom free text or Regex filters.

ellipsis-v Additional actions Open a dropdown with additional actions.

Clicking this icon will acknowledge all model breaches currently

in the log. Acknowledging model breaches removes them from
check-double Acknowledge All display by default - it is a good way to indicate that an alert has been
successfully investigated. This option appears under ellipsis-v Additional
actions.
This icon will only appear when the log is filtered to show
undo Unacknowledge “Acknowledged” model breaches. On click, it will unacknowledge all
All model breaches currently in the log. This option appears under ellipsis-v
Additional actions.
Some options will only appear in a specific mode.
Clicking this icon will acknowledge all model breaches currently in
comment-alt-check Acknowledge All the log and add a comment to all those acknowledged. This can be
ICON DESCRIPTION helpful if, for example, a custom model developed by a user has over-
and Comment
triggered alerts. This option appears under ellipsis-v Additional actions.
Defeats are a way to control model behavior without impacting
automatic updates from Darktrace analysts. One click defeats allow
users with the “Edit Models” permission to quickly exclude specific
One Click Defeats
toggle-off Add Model
conditions from triggering a model breach. A detailed description of
Defeats Defeats are a way to control model behavior without affecting automatic updates from
defeats is covered in the guide to the Model Editor (Model Defeats).
This option only appears if the model breach log is filtered to a single Darktrace analysts. A detailed description of defeats and their purposes is covered in the
model. guide to the Model Editor (Model Defeats).
Clicking this icon will open a graph to the right of the log of model
chart-area View breaches Users with appropriate permissions (Edit Models) will see a toggle at the top of the log to “Add
breach score against time. The timeframe will reflect that for the log.
graphically model defeats”. When enabled, a remove minus-circle icon will appear beside every field in the model
The device/model, score and time are displayed in hover.
This icon opens the Model Editor interface focused on the model. The breach entry.
exclamation-triangle View model model editor interface is introduced in The Model Editor. This option
only appears if the model breach log is filtered to a single model. To add a defeat, click the blue icon beside the desired value. A popup will appear describing
Users can comment on model breaches to provide context or the change to the model. Confirm to add the defeat.
indicate to other users they are working on the alert. Comments
comment-exclamation Only show remain within the Threat Visualizer interface or any configured alert
discussed outputs - to discuss a model breach with Darktrace analysts, please
use Ask the Expert or the Darktrace Customer Portal. This option will
only be displayed if model breaches in the list have comments.
53
ENTRIES IN THE MODEL BREACH LOG

Log Entries
Entry headings
Model breach logs contain a list of model breaches for a model, a device or a subnet over a
chosen time window. Each entry in the log represents an instance where a device performed The main part of the log entry includes key information about the device and model breach.
activity that met the criteria of a model and triggered a model breach.
• If the model breach log is filtered on a specific model, each log entry will display the
In this example, the log has been opened from a threat tray tile for the model “Anomalous device that triggered the model breach at the top. Hover over the name of the device
Connection / New or Uncommon Service Control”. The log has therefore opened filtered on for a summary tooltip with basic information about the device. Click the device name
that specific model. to change the visualizer focus to the device.

• If the model breach log is filtered on a specific device, each log entry will display the
name of the model that was triggered. Click the model name to open the model editor
interface for the chosen model in a new tab.

• If the model breach log is filtered on a subnet or a user, both the model name and the
device that triggered the model breach are displayed.

AI Analyst investigates every model breach that occurs on the system and reports only the
most interesting activity as incidents. If a model breach has triggered an AI Analyst incident,
this can be quickly accessed by clicking the “c Review AI Analyst Incident” text that appears
on the entry.

Entries are sorted chronologically with newest first. The colored bar on the left indicates the
severity of the model breach on a gradient from yellow (low) to red (high). In this case, the
model has a medium severity,

Next to the bar is the model breach ID - this numeric ID is a unique reference to this model
breach in this threat visualizer instance. Click the ID to copy a shareable link to the model
breach to the clipboard. In Unified View environments, model breach IDs are prefixed with a
number to indicate the source master.

Underneath the model breach ID is the time at which the model breach occurred.
54
UNDERSTANDING WHY A MODEL BREACH WAS CREATED

Each log entry gives context as to why the device activity met the model criteria. In bold is the
activity (“metric”) that the device performed that caused the model breach to be triggered.

For example, this could be a connection, a data transfer over a certain size, a SaaS Admin action,
or any activity which is considered new or unusual in the context of the devices’ ‘pattern of life’.
Continuing the example of “Anomalous Connection / New or Uncommon Service Control”, the
device performed a DCE-RPC Request that met the requirements of the model.

Not all SaaS Admin or DCE-RPC Requests will have met the model criteria - models have
additional restrictions that the activity must meet. For example, the model may be looking
for unusual connections from ports other than 443 or SaaS activity from an ASN that is 100%
unusual. If there are criteria which were not included by the model creator in the main info
section, a “Show More” box will appear. This box contains details of these extra criteria that
were met by the activity.

In this example, the SaaS user device performed a SaaS Admin action that met the criteria.

Click the words in bold to open a graph of that metric for the device over time.

Metrics and Filters

Underneath the key metric is further information about the activity and criteria it met to trigger
the model breach. This information is useful context for an analyst to understand the activity
and potentially why the activity was anomalous.
Some models may look for multiple types of activity so these elements may appear more than
For example, it is helpful to know the resource that was changed by the administrative action once on a single log entry.
in the SaaS environment or the DCE-RPC operation that was performed. The information
included is chosen when the model is created (“display fields”). Therefore, the amount of If workflow integrations that allow lookups for external IPs and hostnames are enabled (such a
information can vary greatly between models. VirusTotal), a exclamation-circle pivot icon will appear for these entries.
55
UNDERSTANDING EXAMPLE MODEL BREACH LOG ENTRIES

Worked example - Network Worked example - SaaS

Taking all the sections discussed already together, we can see that the device “vem01.
ad.holdingsinc.com” performed a DCE-RPC request containing a “CreateServiceW” function
to port 49669 using the credential “administrator”. Using the additional model criteria, we can
see this was 100% unusual for the device.
Performing the same process on the SaaS example, the device “SaaS::Dropbox: benjamin.
This activity triggered the “informational” category model “Anomalous Connection / New or [email protected]” performed a “MemberTransferAccountContents” action on another
Uncommon Service Control”. AI Analyst subsequently investigated and raised an incident for user “[email protected]” in Dropbox. Although the ASN and IP for the action are
“Suspicious DCE-RPC Activity”. not unusual, it is outside the ‘pattern of life’ for the user to perform admin actions and this is
the first time this user has performed this specific action at all.
This activity was linked with multiple new and unusual credential usage on the same device,
suggesting a wider incident. In conclusion, the behavior suggests they may be trying to elevate permissions or access
resources they are restricted from and has triggered the “informational” category model
“SaaS / Unusual Activity / Unusual SaaS Administration”. AI Analyst subsequently investigated
and raised an incident for “Possible Hijack of Dropbox Account”.

56
ACTIONS FOR MODEL BREACH LOG ENTRIES

Once the reason for the model breach is understood, a number of actions and further Advanced Options
investigation steps can be taken. Each entry has a series of actions and options on the right.
OPTION DESCRIPTION
OPTION DESCRIPTION
This option adds the device to a list, preventing it from ever triggering
empty-set Ignore any
This icon changes the focus of the main visualizer workspace to the another model breach for the model. For more information, please
future breaches…
search View this model device that triggered the model breach at the time of the model see Other Model Tabs for more information.
breach in visualizer breach. It is one of the ways to access the device investigation tools The Darktrace SaaS Console is a purpose built interface for
introduced in Focusing on a Device. cloud View this model
investigating SaaS and cloud user behavior. This icon opens
breach in the SaaS
Users can comment on model breaches to provide context or the equivalent model breach in the SaaS console to continue
Console
indicate to other users that they are working on the alert. Comments investigation there.
on a model breach that triggered an AI Analyst incident are also
comment Discuss this exclamation-triangle View Model in This icon opens the Model Editor interface focused on the model. The
pulled through to the incident discussion. Comments remain within
model breach Model Editor model editor interface is introduced in The Model Editor.
the Threat Visualizer interface or any configured alert outputs - to
discuss a model breach with Darktrace analysts, please use Ask the Models maintained by the Darktrace analyst team have been mapped
Expert or the Darktrace Customer Portal. sitemap View MITRE
to the MITRE ATT&CK framework where applicable. This mapping is
The model breach event log is a filtered event log, similar to the ATT&CK mappings
a valuable tool to understand coverage and for teams with internal
device event log introduced in Understanding the Device Event Log. for this model
list View model playbooks for how to address each technique. Click to open a window
The log contains only the activity that met the model criteria and breach
breach event log listing the mapped techniques.
caused a model breach to trigger. The metrics and filters of a model define the activity the model
One click analysis is a quick way to understand the events that is looking for. When these criteria are met, the model breach is
eye Analyze this triggered the model breach. Clicking the icon will open an event info Explain metrics triggered and the criteria are displayed on the log entry in the
model breach log with the events that triggered the model breach and a graph used in this model format “Hostname google.com” or “Source has tag Antigena All”. To
displaying relevant metrics that the model itself was looking for. breach understand what these metrics and filters are looking for, click this
Acknowledging model breaches removes them from display by icon to review definitions written by Darktrace analysts for metrics
check / times Acknowledge default - it is a key part of many investigation workflows. Click this and filters relevant to the model breach.
/ Unacknowledge icon to acknowledge a model breach. If the model breach has
clipboard Copy to Copies the breach details to the clipboard including the device, the
this model breach already been acknowledged, hover the icon to see the user who
Clipboard model breach display fields and a link to the model breach.
acknowledged it and when, or click to unacknowledge.
Pinning a model breach means it can be retrieved at a later date from
thumbtack Pin this model the thumbtack pin icon in the bottom left of the threat tray. Click again to unpin
breach the model breach. Pinned model breaches are specific to each user
but will persist between sessions (requires local storage).
When the model breaches in the log are displayed graphically,
filter Filter graph by
this filter allows just model breaches for the chosen model to be
this model breach
displayed. This option will only be shown if the graph is open.

Open a dropdown with additional actions. These advanced options

ellipsis-v Additional actions
are described below.

57
EXPLORING THE MODEL BREACH EVENT LOG

Investigate a Breach Log Entry

The investigation process for model breaches is very similar to AI Analyst investigations:

1. Understand the activity that caused the alert

2. Focus on the device that triggered the alert

3. Gather context about the way it behaves

4. Deep dive into detailed metadata

5. Action the alert internally if necessary

6. Acknowledge the alert

AI Analyst performs a significant amount of these actions for the user and presents the For most models, the event log will contain a small number of entries that are relevant. The
information as part of the AI Analyst incident. For model breaches, these steps must be following actions are useful to understand this activity better:
performed by moving through logs and investigation dialogs in the Threat Visualizer interface.
Many of these features such as the device event log and device summary have already been • For events or notices, click the info-circle info icon to open a detailed pop-up.
discussed in detail and should be familiar.
• For connections, click the arrow to see details of the connection. Use the arrow-to-bottom packet
To start, open the list model breach event log from the breach log entry. capture functionality to create a replayable version of the connection at a packet level.

Model Breach Event Log • Use the caret-down arrow icon to pivot to the Advanced Search interface to see detailed
metadata about the entry.
The model breach event log is a filtered event log; the log contains only the activity that met
the model criteria and caused a model breach to trigger. The model breach event log is very similar to the device event log and is easy to navigate if
the latter is already understood. The filter options used in the model breach event log are
For example, for a model breach relating to unusual SSH connectivity, the model breach event the same as the device event log (see Filtering the Device Event Log). The investigation
log might display a single anomalous SSH connection (or possibly more than one). In contrast, workflow for model breach event logs also mirrors that of device event logs and is covered in
for a model breach relating to excessive HTTP errors or port scanning, the event log will display detail in Using the Device Event Log, Types of Event in the Device Event Log, Investigating a
far more events, because for these types of behavior it is a number of events in combination Connection in the Device Event Log and Investigating SaaS Activity in the Device Event Log.
that all contribute to the detection of an anomaly.
The next step, as with AI Analyst investigations, is to now focus on one or more key devices that
triggered the model breach. Click “search View this model breach in visualizer” from the breach
log entry to focus the workspace on the device and investigate its behavior as described in
Focusing on a Device.
58
CHAPTER 5 - OTHER INVESTIGATION TOOLS

EXTERNAL SITES SUMMARY

EXTERNAL SITES SUMMARY 60
EXTERNAL SITES SUMMARY FOR IPS AND HOSTNAMES 61
EXTERNAL SITES SUMMARY FOR SAAS ACTIVITY 62

ALTERNATIVE APPROACHES
DYNAMIC THREAT DASHBOARD 63
ASK THE EXPERT 65
CREATING PACKET CAPTURES 66

APPLYING TAGS
ADDING AND REVIEWING TAGS 67
COMMONLY APPLIED TAGS 68

EXPLORE
EXPLORE MODE 70
FILTERING THE EXPLORE WORKSPACE 72

REPORTING
CYBER AI INSIGHTS REPORTS 74
EXECUTIVE THREAT REPORTS 76
EXTERNAL SITES SUMMARY

External Sites Summary The timeframe for alerts and lists of devices or users is taken from the current time range of
the threat tray.
External sites summary provides statistics on the historic interaction between internal devices
and external endpoints. The summary can appear in two formats, depending on how it was Rarity Tab
launched. There are three tabs - information, rarity and location.
The rarity graph tab reports how common the external endpoint is in the context of network
To open the external sites summary, click the globe-americas globe icon from the omnisearch bar or the external-link-alt behavior or global SaaS activity over time. Endpoints on the “Trusted Domains” list will always
external link icon in event logs. be reported as 0% rare.

Most frequently, external sites summary is launched from omnisearch or connection event Location Tab
logs. In this scenario, it will provide statistics on internal devices that have connected to the
external location and the general rarity of the location in the network. For IPs and hostnames, the locations tab displays the approximate location of the external
host on a map using ASN geolocation data. For SaaS activity, the locations tab instead displays
If external sites summary was instead launched from a SaaS or cloud action, it will visualize the the approximate geolocation for all IP addresses that have performed SaaS activities for this
relationship between the ASN / IP and the SaaS user from the event. user. In both cases, the ASN for the IP under investigation will pulse to highlight its location.

Information Tab

The external sites summary will open on the information tab to display statistics on the external
endpoint and interaction with internal devices. The contents of the information tab differs
when the summary is opened from connectivity information or from SaaS activity.

Click on any location marker to see the associated IP addresses, the ASN and - for SaaS activity
- the frequency at which the activities were performed. Both the ASN or IP in the tooltip can be
clicked to launch event logs.

Locations for SaaS user activity are also colored in this mode to display rarity: light blue
locations are observed frequently for the user, dark blue locations rarely.

60
EXTERNAL SITES SUMMARY FOR IPS AND HOSTNAMES

When the summary is focused on network connections to and from the external location,
ICON DESCRIPTION
the hostname or IP appears as heading in the top left. The first time the location was seen in
connections observed by Darktrace is also displayed. This will persist between tabs. This icon populates the panel to the right with a chart breaking down
chart-pie View graph
the ports that the device used to contact the external location.

exclamation-triangle Open device Opens a model breach log focused on the device. Model breach logs
model breach log are covered in more detail in Exploring the Model Breach Event Log.

Switches the focus of the main workspace to this device. Focusing

search View device in
on a device is covered in more detail across a series of articles,
visualizer
introduced in Focusing on a Device.

If the summary is focused on an external IPs, a section will appear with related hostnames
that have been associated with the IP in DNS queries observed by Darktrace. If the summary
is focused on a hostname, the IPs seen in DNS will instead be displayed. New external sites
summary windows can be opened for these related IPs and hostnames using the external-link-alt external
link icon.

On the right is a list of unacknowledged, potentially uninvestigated, alerts where the external
location was involved in the activity that triggered the model breach. Click the exclamation-triangle triangle icon
to open the model breach log.

Underneath the related IPs or hostnames is a list of internal devices that have been observed
connecting to the external location. The panel on the right will not populate until a device has
been chosen using the chart-pie chart icon.

61
EXTERNAL SITES SUMMARY FOR SAAS ACTIVITY

SaaS ICON DESCRIPTION

When the summary is opened from SaaS or Cloud activity, the information displayed is This icon populates the panel to the right with a chart breaking down
focused on the combination of user and external location. This user and IP/ASN pair appears chart-pie View graph the activities the user performed when they connected to a SaaS
as heading in the top left. service from the IP or ASN selected.
Opens a model breach log focused on the user device. Model breach
exclamation-triangle Open device
logs are covered in more detail in Exploring the Model Breach Event
model breach log
Log.
Switches the focus of the main workspace to this device. Focusing
search View device in
on a device is covered in more detail across a series of articles,
visualizer
introduced in Focusing on a Device.

The summary section on the left contains information about the external IP that was used to
perform SaaS activity, including approximate geographic location and rarity in the context of
the network.

On the right is a list of unacknowledged, potentially uninvestigated, alerts where the external
location was involved in the activity that triggered the model breach. Click the exclamation-triangle triangle icon
to open the model breach log.

The bottom right displays a summary of activity the user has performed from the same ASN
over the last month in chart-format. This activity is grouped into high-level categories for clarity.

On the left are other users who have connected to a SaaS service using the same ASN or IP.
The activity chart can be switched to one of these other users by clicking the chart-pie chart icon.
Changing the filter between ASN and IP will also change the chart.
62
DYNAMIC THREAT DASHBOARD

Accessing the Dashboard Search Bar

The Dynamic Threat Dashboard view dashboard can be accessed from the main menu, or The search bar allows for powerful filtering by multiple search terms.
navigated to directly from the URL. It provides a full screen interface for viewing model
breaches and key information for each breach. This screen is intended for extremely rapid
triage with a minimum of interaction. Note that it will scroll through incidents if left unattended
which can be useful on SOC TV display screens. • Free text searches are converted to filter terms upon pressing return.

This page allows for the quick sorting, viewing, and acknowledging of breaches for triage • Typing additional text and pressing return constructs a second filter term. This process
purposes. If a breach requires additional investigation, the user can pivot back to the 3D can be continued to add additional filters to narrow results down. Each subsequent
View to view further information. Selections flow from left to right across the dashboard, and filter is AND-ed to the previous ones.
keyboard arrow keys can be used for navigation.
• Filters can be removed by clicking the “x” in each “pill” in the search bar.

• All breaches that match the current search filters can be acknowledged with the
“Acknowledge Filtered Breaches”.

The contents of the dashboard can be globally filtered by the search bar on the top right.

63
Left-hand Panel Breaches Panel

This panel provides the top-level navigation for breach The panel lists individual breaches for the selected
information. device or model. The entries are sorted by breach score,
displayed in the radial icons. The entries will be labelled
The selector icons in the title bar switches between with either the name of the model that breached (in
model and device grouping. device view), or the name of the device that breached
the model (in model view), and the number of other
In model grouping the panel lists the models that have breaches for that model or device. Each breach entry
breached during the specified time frame, sorted by has buttons to acknowledge or filter.
total score for that model. Each entry includes either
the time of breach (for models with only one breach) Clicking the filter button will populate the search bar
and the count of the number of breaches for the model. with a filter term to match the other breaches for that
model or device. These automatically produced filters
In device grouping, the panel lists the devices that can be combined like any other filter within the search
have breached models during the specified time bar. The filter can be removed by clicking the x beside
frame, sorted by total score for that device. Each entry the filter term in the search bar.
includes either the time of the breach (for devices
with only one breach) and the count of the number of
breaches for the device. Selecting an entry populates
the Breaches panel with the breaches for that model
or device.

In users grouping, the panel lists user credentials

that were associated with model breaches within
the specified time frame. Not all model breaches will
have an associated user credential; this panel will not
encompass all model breaches, only those where a
credential can be associated. Each entry includes
either the time of the breach (for users with only one
breach) and the count of the number of breaches for
the user. Selecting an entry populates the Breaches
panel with the breaches for that user.

64
 ASK THE EXPERT

Details Panel What is Ask the Expert

The right-hand side panel displays summary Ask the Expert allows for the creation of incidents which can be submitted to Darktrace
information for the selected breach. This information is analysts for feedback. Creation of an incident is done within the Threat Visualizer by entering
designed to allow for quick decision making about the text and dragging relevant data into the creation window. Submitted incidents become open
events in question. questions which can be viewed, and commented with updates both by Darktrace analysts and
local user accounts. Questions have associated statuses and function as “tickets” that can be
The top section displays overall threat score and closed when resolved.
information about the device in question. The sections
below contain dynamically populated content showing Ask the Expert is available from the Main Menu, under Help – the “Ask the Expert” menu item
connections and visualizations that contributed to the allows for the creation of new questions, and the “View Questions” menu item allows for the
breach. viewing of existing questions and their statuses.

The most relevant information will be automatically Viewing Questions

displayed.
The “View Questions” pop up lists all previously submitted questions with their timestamp,
If the displayed information is inconclusive, clicking the owner, and status. Possible question statuses are:
“Investigate” button will navigate to the 3D View with
the device, time, and breach event log for the current • New
breach selected.
• Responded

• Closed

The toolbar in the popup allows for filtering and highlighting of the incidents by their attributes,
as well as searching by author or name.

Clicking on a question opens a new popup that allows the viewing of Darktrace responses and
the addition of new comments. Questions can be closed or deleted – closing will mark the
status of the question as closed and resolved, without actually removing from the question list.

65
CREATING PACKET CAPTURES

Packet Captures To: The end time of the packet capture. The end time can be altered by clicking on the gray
‘To’ box. The time range defaults to Darktrace’s best guess as to which range will capture the
Packet Captures can be generated from connections seen in the Darktrace Threat Visualizer connection of interest (for example if it knows that the connection ended at a certain time).
for further investigation. There are two ways of viewing raw packets (in PCAP format): firstly, by
creating the PCAP from the dropdown next to any connection in the device event log, secondly Create: This option starts the packet capture.
by creating it from the device event log when a device is selected.
Cancel: This option closes the window.
If you have a distributed deployment, raw traffic is stored on the probes, which can cause a
time delay in retrieving PCAPs. Any PCAPs created are then saved on the master appliance. Use Connection: This option is only available when creating a packet capture for an event.
Clicking this will further filter the selected packets by the connection. The time fields default
Be aware that PCAPs are truncated due to storage requirements so you may not see the to the start and end second of the connection selected and the source and destination ports
entirety of the data flow between the devices in question especially where large amounts of are as specified in the connection.
data (e.g., files) are transferred. However, the PCAP typically gives you enough information to
get an idea of what is happening. Viewing the PCAP File

Creating Packet Captures The file can be viewed by clicking the PCAP option from the main menu. PCAPs can be viewed
in the Threat Visualizer interface or downloaded for use in external tools.
For advanced users who wish to access raw packets
relating to device communications there are options
within the device event log for creating a packet
capture file.

Tip: If creating a packet capture file for a single device

from the device event log, the Source and Target fields
are not shown. The field shown instead is ‘IP’ (referring
to the IP address of the device) – no destination is
specified.

Source: This shows the source IP address pre-populated with the value from the event which
has been selected.

Target: This shows the target IP address pre-populated with the value from the event which
has been selected.

From: The start time of the packet capture. This is pre-populated from the event which has
been selected. The start time can be altered by clicking on the gray ‘From’ box.
66
ADDING AND REVIEWING TAGS

Tags offer a simple labelling system for network devices, credentials and users detected in To review a tag, click on it. A summary page will specify (where applicable) the devices tagged,
external platforms (SaaS users) which can be used to identify important resources, control models that apply the tag, models dependent on the tag for breach logic and models that
eligibility for Darktrace RESPOND and alter model logic. Tags can be automatically applied as have the tag applied to them. All models and devices or users can be clicked. To further refine
a model action, used in model defeats to exclude devices, or factored into model logic. For the list, the filter filter icon can be used to add an additional tag, filtering only by models/devices
users detected in external platforms (SaaS users), tags may be also be applied automatically that share both tags.
by the module to identify the roles assigned to the user - these tags are identified by “(CG)”.
To edit or delete a tag, click the pen edit icon beside the tag name.
A small number of tags are restricted for system use only and are used to indicate devices
excluded from monitoring or behaving erratically. See Commonly Applied Tags for an
explanation of commonly applied tags and their purpose. Add a New Tag

Viewing and Editing Tags To add a new tag, click Add Tag from the Tags Manager.

When creating a new tag, a description can be added

to help identify the purpose of the tag. Selecting a color
assists identifying the tag when assigned to a device.
Click Save.

The new tag will appear on the tag manager.

Tags can be managed in the tags manager, accessible from both the SaaS Console or the Tags can also be created via the API.
Threat Visualizer, or via the API (/tags). Select tags Tags from the Main Menu to open the
manager.
Tag a Device
A list displaying all current tags will appear, optionally filterable with the search. In the top right,
the link link icon pivots to Explore Mode in Explore Tags mode. In the Threat Visualizer, tags can be added when a device is focused upon from the global
omnisearch or from an event log. The tags associated with the device are listed below the
search.

Click the plus plus icon to open a dialog to add an additional tag. In the pop-up window, locate
the tag and click on it to add to the device.

When the device has many tags, these are collapsed and can be shown in a popup, searchable
dialog by clicking the “+[#] tags”

67
COMMONLY APPLIED TAGS

The Threat Visualizer supports a flexible label system called Tags to allow analysts to be able to
TAG DESCRIPTION
rapidly label and refer to groups of devices within the platform. One use case for this feature is
to enable monitoring of high-risk users or devices such as departing employees or key assets. This tag is applied to client devices which are unable to be assigned
Tags can be applied manually, applied automatically by models as a breach action or applied to a cluster by mathematical modelling due to having a unique
as part of the Darktrace mathematical modeling. fingerprint of network behavior. It is allocated by Darktrace’s machine
Unique Clients
learning and is part in of the clustering of devices into ‘peer groups’ or
‘similar devices’. This tag is applied by the system and not controlled
The following tags are commonly used within the Darktrace platform:
by models.
TAG DESCRIPTION This tag is applied to server devices which are unable to be assigned
to a cluster by mathematical modelling due to having a unique
fingerprint of network behavior. It is allocated by Darktrace’s machine
Device will be excluded from common admin related models (for Unique Servers
Admin learning and is part in of the clustering of devices into ‘peer groups’ or
example, unusual admin session models).
‘similar devices’. This tag is applied by the system and not controlled
Device is a known security device which can affect the behavior by models.
of other devices by making thousands of inbound connections - Unusual A device has performed such an anomalous volume of connections
Security Device
excludes it from related models for such activity (for example, network Connectivity that it is no longer tracked for unusual connectivity, as its pattern is so
scanning models). Excluded erratic / high volume.
Exclude Data Device should not breach on unusual data transfer models (for Domain Device has authenticated with a domain controller within the last 0.5
Transfer example, backup servers). Authenticated days.

Device will not breach any models, but its connections are still Internet Facing Device has received incoming external connections but is not tagged
Model Excluded
recorded and visible as normal. System as a server (i.e. internet exposed device).

Device has breached a network scan or attack tools model in the past Re-Activated A device was inactive for at least the past 4 weeks and has re-
High Risk
48 hours. Device appeared on the network.
Device has breached a Darktrace RESPOND/Network (Antigena
Active Threat Network) model (excludes Compliance models) with a breach score External DNS Device has performed an external DNS connection.
greater than 25% in the past two hours.
Devices within IP ranges that have no tracking will be tagged (requires
Device has authenticated using a key user account (requires
Key User No Device Tracking configuration of the corresponding model). Devices with this tag will
configuration of key users in the corresponding model).
be excluded on unusual activity breaches.
Device has been detected using at least three different user agents
Conflicting User Devices performing the functionality of DNS servers - will be excluded
in individual connections within the last 4 minutes (for example, Linux, DNS Server
Agent from models which look for unusual DNS activities.
Windows and iOS).
Device was seen sending or receiving lots of email. Devices with this
Device has been identified to relay local DHCP requests to a DHCP
DHCP Relay Mail Server tag will be excluded from models which look for unusual volumes of
server.
emails sent.

68
TAG DESCRIPTION

A device is operating as a Windows Server Update Service (WSUS) /

System Centre Configuration Manager (SCCM). A device with this tag
is excluded from breaching on some common activity patterns such
WSUS / SCCM as unusual internal data transfers to new devices. This tag should be
added automatically by the WSUS or SCCM Tag model but in some
circumstances, it may not be possible to automatically detect the
service, and the tag can be added manually.

Devices that trigger an inoculation breach receive an Inoculation tag

Inoculated Device
for 1 week.

69
EXPLORE MODE

Opening Explore Components

The Explore feature can be accessed from the Main Menu item Explore, where the user may The Components subsection gives a list of the visible Subnets and Tags and further
select from tag Explore Tags or cube Explore Subnets. Alternating between Tags and Subnets is information about the average rate of transfer in MiB/s or KiB/s. These components can be
also easily performed within Explore itself. The pivot icon is also available in the main Threat further explored by clicking on them.
Visualizer when investigating a specific Subnet, or from the Tag Manager.
Refer to Filtering the Explore Workspace section for further information about exploring
Connections and Components.

The Explore function utilizes the same time selector as the main Threat Visualizer to adjust
the point in time represented, and the increase window feature allows for expansion of the
time window itself. Explore presents a cross-section of the network at a specific point in time,
therefore it does not display real-time connection information.

Using Explore

Communication between subnets or tags is indicated by a dashed line, where dash length
correlates with the amount of data transferred, i.e. the shorter the length and more numerous
the dashes present in a connection, the more data transferred and respectively, the longer
the length and less numerous the dashes present in a connection, the less data transferred.

LINE KEY

On the Explore Tags and Explore Subnets pages respectively, tags and subnets are clearly Less data transfer.
labelled and color coded to enhance the user experience. Zooming in and out is possible in
order to improve visibility.

On the right-hand side of both the tag Explore Tags and cube Explore Subnets pages, there is a
More data transfer.
panel with a list of Connections and Components, which can be accessed by clicking on the
respective title.

Connections
represented visually as concurrent connections in both directions may be observed at the
The Connections subsection gives a list of the visible connections together with information same moment between numerous devices in the particular Subnet or represented by the
about the average rate of transfer in MiB/s or KiB/s. These connections can be further explored specific Tag.
by clicking on them.

70
The severity of any alerts generated by devices in a Subnet during the time frame is indicated From this Device view, clicking further on a specific line of connection between two devices
by the color of the icon, where white indicates no breaches and a gradient from light yellow to will open the Event Log on the right hand side of the page. The log for connectivity connection
red indicating severity. The Subnet color is determined based on the highest scoring device of between the two devices is represented within the specified timeframe. The log includes time,
all breaches for all devices in that Subnet taking account for the last seven days. date and connection direction. By hovering over the arrow, further information is available,
including start time, source, destination, and protocol.
Tags can be customized in the main Threat Visualizer Tag Manager.

Investigating A Device

• When in Subnets or Tags View, hovering over a subnet or tag will display key information.

• When in Subnets View, hovering over a subnet will display the subnet’s name, the
number of devices it encompasses and the number of tags applied to devices within it.

• When in Tags View, hovering over a tag will display the tag’s name, the number of
devices within that tag and the number of subnets that devices with the tag are part of.

To return to previous levels of connection, click on one of the available options that appear in
the top left hand side corner of the screen after Explore >. This submenu represents the route
taken to reach the currently observed Event Log.

From either Subnets or Tags View, clicking on a particular line of connection (i.e. clicking on
a visual dash connecting subnets or tags) will reveal much more detailed information about
the chosen connection. While in this Device View mode, hovering over any of the icons
representing various components provides relevant information such as name, vendor, mac
address, operating system, type, subnets and tags.

71
FILTERING THE EXPLORE WORKSPACE

Filtering the Explore page

Average rate (KiB/s)/ Total size (MiB or GiB)
When in Subnets or Tags view, on the right hand side of the screen where the Connections
and Components can be explored, clicking on the filter icon next to Investigate a Connection If the Transfer Rate box is ticked, the option to search for connections based on the average
will open a filter pane. Filtering will focus the workspace by removing connections that do not rate of transfer in Kibibyte per second (KiB/s) is available. By using the slider, the workspace
match the given conditions. The available filters: can be customized based on the transfer rate. The Subnets, Tags or Devices (depending on
where this search is being performed) that are applicable will stay in the workspace. Items
Connections Involving which do not match the criteria will disappear from view.

If the Connections Involving box is ticked, the “Search device” field underneath it will allow In the same way, by using the same slider, the workspace can be customized based on total
free text input to search for a device. Once text is inserted, this will remove Subnets or Tags size of data transferred, in MiB (Mebibytes) or GiB (Gibibytes), which is displayed underneath
from the workspace that do not contain the search text nor are in connection with the devices the sliding pointer.
that contain the search text. Elements which are in connection with the devices that contain
the search text but do not match the search will appear slightly faded. Transfer Ratio

Filtering with a search term is a helpful function in narrowing down a specific device or devices If the Transfer Ration box is ticked, the option to search for connections based on the transfer
and clearly observing their connections. ratio is available. The transfer ratio filters Subnets or Tags on the workspace by the ratio of data
uploaded versus that of data downloaded during the time frame. The left slider controls the
downloaded amount and the right slider controls the uploaded amount. At the highest level,
this controls the total amount of uploaded:downloaded between the two subnets. At a lower
level, this ratio is on a device to device level.

Where Subnets or Tags that fall within the slider bounds have connected to/been connected
to other elements that do not fulfil the filter conditions, these elements will remain but will be
greyed out. Other elements which do not meet the criteria and have not connected to these
nodes will disappear.

72
Explore Layout

The distribution of Subnets and Tags in the Explore screen dynamically updates to Exclusive Tags
position connection events in the clearest format; initial locations are derived only from the
communications observed during the time window. At the top left of the workspace are view To use Exclusive Tags, activate the relevant toggle on the main workspace. When enabled, the
toggles. Exclusive Tags toggle restricts the connections visualized between tags. If a device has more
than one tag in common with the device it is connecting with, when tags are exclusive, Explore
Fixed Positions will not render a connection between the tags that are shared between the devices.

The Fixed Positions toggle locks subnet and tag nodes in place, preserving their location on For example, if two devices (a & b) are tagged with iOS device and iPhone and Exclusive Tags
the workspace when deep-diving into particular connection events and returning to the main was disabled, the behavior of Explore would draw a connection between iOS device and
overview. iPhone and iPhone to iOS device to represent this communication. With Exclusive Tags, no
connection line would be drawn between these shared tags. If device b is also tagged with
Once the Fixed Positions toggle is enabled, another toggle appears next to it - Allow Editing. New Device, exclusive tags would render the connection between iOS Device and New Device
If the toggle Allow Editing is enabled, the nodes can be individually dragged and dropped to and the connection between iPhone and New Device, but not the connection between the
alter their persistent position. This function allows nodes to be places according to the user’s shared tags.
understanding of the network layout. Each user maintains their own local layout.

73
CYBER AI INSIGHTS REPORTS

Cyber AI Insights reports can be generated within the Threat Visualizer and present an overview Report Options
of coverage, user engagement and value provided by your Darktrace deployment. The report
displays currently deployed components, integrations, probes and modules against those To generate a report, navigate to Cyber AI Insights Report in the main menu (Reporting >
generally available. Cyber AI Insights Report). A new window will open. The following configuration options are
available.
The data contained in each report is specific to your organization and includes trends in
processed network traffic, the categories of threat that triggered Darktrace RESPOND OPTION DESCRIPTION
response and a breakdown of events detected by AI Analyst by threat stage. To measure user
Accepts a time range for the report period. The actual date period
engagement, the average time-to-acknowledge for human operators is calculated across the
covered will be displayed in the two boxes beside the selector.
timeframe. Time Period
Reports can generated for any period of less than 1 year, data-
dependent.
Reports can cover a single day or up to 12 months (data-dependent) and can be customized
to include estimate costs savings from AI-augmented incident response and triage. Where Timezone Alters the timezone of the report to that specified.
applicable, reports will also include data on threat trends and response from Darktrace/Email.
Please note, this data is restricted to the last 4 weeks, regardless of overall report timeframe.
To produce an estimate of the savings generated by Darktrace
Estimated Incident
RESPOND, provide the expected cost in the chosen currency (default
Response Cost
USD) of a successful cyber incident to your organization.
To produce an estimate of cost savings created by AI Analyst
Analyst Hourly
investigations, provide the expected hourly wage of a cyber analyst in
Wage
the chosen currency (default USD).

Currency Select a currency for monetary fields.

Information about response times to model breaches (time to

Include Human
acknowledgment) can be optionally included if acknowledgment is
Response Data
part of your organizational workflow.
Behavior categories are high level filters that allow an operator to
focus in on specific levels of severity or behavior. There are four
categories: Critical, Suspicious, Compliance and Informational.
Behavior Visibility
Select the categories to restrict data on the optional “Mean Time to
Acknowledgement” page. Requires “Include Human Response Data”:
On.
Cyber AI Insights reports can also be automatically generated and sent to recipients by email; For operator acknowledgment statistics on the optional “Mean
this is configured on the System Config page. For more information on scheduling reports, Human Response Time to Acknowledgement” page, set a minimum model breach
please refer to Scheduling Automatic Report Generation. Minimum Breach score for response time to be calculated against. This allows
Score acknowledgement time to be focused on high-level events. Requires
“Include Human Response Data”: On.

74
Generate a Report

Once all desired options have been selected, click the Generate Report button to create the
report. The generated report will appear within the popup window, where it can be downloaded
as a PDF.

Previously generated reports and those over a larger timeframe can be retrieved from the
Download Reports page (Reporting > Download Reports). Users with the “Download My
Reports” permission can review reports they have generated there. Users with the “Download
All Reports” permission can review reports generated automatically or by manually all users.

75
EXECUTIVE THREAT REPORTS

Executive Threat Reports can be generated within the Threat Visualizer and present a simple
OPTION DESCRIPTION
visual overview of model breaches and activity in the network environment. The report is
separated into a graphical representations of network traffic, model breaches and Darktrace Accepts a time range for the report period. The actual date period
RESPOND response and an optional detailed breakdown more suitable for advanced covered will be displayed in the two boxes beside the selector.
Report Period
audiences. Reports can generated for any period of less than 1 year, data-
dependent.

Timezone Alters the timezone of the report to that specified.

Reports can be generated for a single subnet, or for multiple subnets.

By default, all subnets are included. Multiple entries can be selected
Subnets
from the dropdown. Please note, enabling SaaS Report will clear this
field.
Alters the report to include only unacknowledged model breaches
Filter Breaches (default), only acknowledged breaches or both acknowledged and
unacknowledged.
Behavior categories are high level filters that allow an operator to
focus in on specific levels of severity or behavior. There are four
Behavior Visibility categories: Critical, Suspicious, Compliance and Informational. Select
the categories to restrict included Model Breaches to only those that
match the category filter.

Generates only high level summary pages, excluding the detailed

Minimal Report
appendix.

Restricts the content of the report to only SaaS user devices and
SaaS breaches. The Darktrace RESPOND page is also restricted to
Reports can cover a single day or up to 12 months (data-dependent) and can be customized SaaS Report
RESPOND actions from platform environments such as Darktrace
to include extra details or restricted to high level information. Executive Threat Reports can RESPOND/Zero Trust and Darktrace RESPOND/Apps only.
also be automatically generated and sent to recipients by email; this is configured on the
System Config page. For more information on scheduling reports, please refer to Scheduling Includes any comments made by users or analysts in the detailed
Include Comments
appendix.
Automatic Report Generation.
Emails the report to the users specified in the “Executive Threat
Report Options Send Report Via Report Recipients” field. This field is configured on the Modules
Email section of the Darktrace System Config page (Workflow Integrations
To generate a report, navigate to Executive Threat Report in the main menu (Reporting > › Report Scheduler › Executive Threat Report)
Executive Threat Report). A new window will open. The following configuration options are
available.

76
Generate a Report

Once all desired options have been selected, click the Generate Report button to create the
report. The generated report will appear within the popup window, where it can be downloaded
as a PDF.

Previously generated reports and those over a larger timeframe can be retrieved from the
Download Reports page (Reporting > Download Reports). Users with the “Download My
Reports” permission can review reports they have generated there. Users with the “Download
All Reports” permission can review reports generated automatically or by manually all users.

77
CHAPTER 6 - THE SAAS CONSOLE

GETTING STARTED
THE SAAS CONSOLE 79
GETTING STARTED WITH THE SAAS CONSOLE 80
MAIN MENU 82
UNIVERSAL ELEMENTS 84

THE DASHBOARD
THE DASHBOARD 84
USING THE THREAT TRAY 86
EVENTS TAB AND LOGS 87
OTHER MODEL BREACH TABS 88

CYBER AI ANALYST
CYBER AI ANALYST FOR SAAS & CLOUD 89
TRIGGERED AI ANALYST INVESTIGATIONS IN THE SAAS CONSOLE 91
SAAS AND CLOUD INCIDENTS 92

PROFILES
USER PROFILES 93
TAGS IN THE SAAS CONSOLE 95

OTHER FEATURES
SAAS EXECUTIVE THREAT REPORTS 96
ASK THE EXPERT IN THE SAAS CONSOLE 97
THE SAAS CONSOLE

Introduction Access

Many organizations use SaaS (Software-as-a-Service) solutions as part of their everyday Where Darktrace DETECT is monitoring SaaS, Zero Trust or Cloud environments and Darktrace/
workflow for file storage, collaboration, and centralized access control, or Cloud solutions Email is monitoring your organizational email domains, the SaaS Console can be selected
for their virtualized infrastructure and R&D. In many of these solutions, user interactions take from the main menu of the Email Console. Pivot points to Darktrace/Email are also provided
place and organizational data is hosted in a third-party managed environment with a separate throughout the user interface and the Email Console is available from the SaaS console menu
audit log and security interface; keeping track of alerts and activity across multiple SaaS and for easy movement between the interfaces.
Cloud environments can be a challenge for many security teams.
Organizations that have Darktrace DETECT coverage over both network devices and users
in SaaS and Cloud environments can access the SaaS Console from the main menu. The
console is a dedicated interface for investigating model breaches and incidents in the SaaS
environment; users can continue to investigate SaaS alerts within the main 3D Visualizer user
interface if desired.

The SaaS Console is a specialized user interface for investigating anomalous activity and
user behavior in and across SaaS and Cloud environments, surfacing the events and analysis
from Darktrace/Apps, Darktrace/Cloud and Darktrace/Zero Trust modules in one centralized
location. The console is powered by the Cyber AI Analyst and Darktrace’s unique ‘pattern of
life’ anomaly detection; the interface is purpose built for monitoring and analysis in these
environments whilst also maintaining existing workflows for operators already familiar with the
Darktrace Threat Visualizer.

Please note, the SaaS Console is focused on administrative activity within Cloud environments.
If you wish to extend visibility over network traffic in your virtualized infrastructure, please
discuss the deployment of Darktrace virtualized sensors with your Darktrace representative.

79
GETTING STARTED WITH THE SAAS CONSOLE

There are multiple entry points in the Darktrace SaaS Console through which analyst teams c AI Analyst
can begin seeing and reacting to identified alerts or incidents produced by Darktrace.
Cyber AI Analyst will review and investigate all Model Breaches that occur on the system as a
starting point for its analysis process. It will then form incidents - a collection of one or more
related events - centered around a SaaS user. The Cyber AI Analyst, with its global awareness
and machine-speed investigation time, performs the heavy-lifting of the analysis process.

The AI Analyst will only surface incidents that are considered high priority - this can be a useful
place to begin investigation and familiarization with the Darktrace environment.

AI Analyst can be accessed from the main menu or the Number of Incidents statistic above
the global map in the dashboard.

Profiles

The profiles page provides an overview of all SaaS and Cloud users detected by Darktrace,
as well as real-time feeds of actions performed and source locations for activity. Accounts
exclamation-triangle Model Breaches will only be added to the profiles when activity is observed by the relevant DETECT module.
Profiles are also grouped cross-platform where possible to give the fullest picture of user
A model is used to define a set of conditions which, when met, will alert the system to the activity.
occurrence of a particular event: Darktrace model breaches are the most fundamental
alert type. A model can be formed of specific triggers, specific thresholds for ‘pattern of life’ Operators are more likely to interact with individual profiles as part of an investigation workflow
anomaly or multiple combinations of the two. The severity of a breach is calculated from the or when seeking further information on a specific user or platform.
priority of the device, the level of anomaly associated with the breach, the priority of the model
and the frequency of similar breaches. The Profiles page can be accessed from the main menu or from the Number of Active Users
statistic.
The majority of Darktrace operators review, investigate, remediate and acknowledge model
breaches as the basis of their workflow. Users have many different preferences as to how
breaches are sorted and the order in which they are investigated; we recommend that new
operators begin with the highest severity and work downwards.

Model breaches can be accessed from the threat tray on the left of the dashboard, the
Number of Model Breaches statistic above the global map, or individually by clicking a node
on the breach graph at the bottom of the dashboard.

80
Suggested Workflow from a Cyber AI Analyst Incident Suggested Workflow from a Model Breach

1. Access the SaaS Console and click the Cyber AI Analyst icon from the menu or the When investigating an alert, a typical workflow will involve starting with summary information.
Number of Incidents statistic above the global map in the dashboard. Review the As an example:
incidents created.
1. Access the SaaS Console and filter the threat tray to include a manageable number of
2. Select the most severe incident or the most interesting to you based on your knowledge Model Breaches - filtered by user or by model - using the severity slider and adjusting
of the business and network setup. Review the summary created by Cyber AI Analyst to the selected time window.
quickly understand what each incident may involve.
2. Investigate the alerts that seem most interesting to you based on your knowledge of
3. Review the summary within the incident and understand how the events relate the business and SaaS platforms under monitoring. Regardless of how anomalous the
chronologically. activity is, you may prefer to begin with key users or SaaS and Cloud platforms, based
upon the priorities of your investigation.
4. Scan the detailed event information to gauge the involved activity and actor. Optionally
click on the account to review the user profile and historic locations for SaaS activity. 3. Review the breach description to understand what the alert concerns.

5. If the activity of interest relates directly to a model breach, investigate and optionally 4. Identify the SaaS user performing the activity and review the pattern of life on the
acknowledge the model breaches. graph - has the event that triggered the breach been performed before?

6. Optionally create a PDF report describing the events. 5. Look at the expanded SaaS activity in the log that triggered the breach and the further
information about the event shown on the right.
7. Acknowledge each event as the investigation is concluded.
6. Confirm whether the user has any anomalous locations for access and activity.

7. Review the chain of behavior graphically and confirm any additional anomalous activity.

8. Look at whether the device has related anomalies at the time or previously.

9. Optionally pivot to Advanced Search for further investigation.

81
MAIN MENU

Threat Investigation Users, Actions and Reporting

Home Profiles

The dashboard provides a global map of all SaaS logins, important statistics about SaaS and The profiles page provides an overview of all SaaS and Cloud users detected by Darktrace, as
Cloud environments, and access to model breaches for triage and investigation. well as real-time feeds of actions performed and source locations for activity.

c AI Analyst a Darktrace RESPOND Actions

Cyber AI Analyst will review and investigate all Darktrace Model Breaches that occur on the Presents currently active and expired actions taken by Darktrace RESPOND against users
system as a starting point for its analysis process. It will then form Incidents - a collection of detected in external platforms and allows the actions schedule to be configured. Current and
one or more related events - centered around a device or SaaS user. historic actions can be exported as a CSV. Refer to Reviewing Darktrace RESPOND Actions for
more information.
envelope Email Console
tags Tags Manager
Pivots to the Darktrace/Email interface for investigation and autonomous actions on your
email domains. Please see the documentation on Darktrace/Email for more information. Tags offer a simple labelling system for users detected in external platforms (SaaS users)
which can be used to identify important users, display relevant contextual data and alter model
search Advanced Search logic. Tags can be automatically applied as a model action, used in model defeats to exclude
devices, or factored into model logic. Refer to Tags in the SaaS Console for more information.
Opens the Advanced Search interface. Refer to the Darktrace Advanced Search introduction
for more information. download Download Reports

Allows Threat Intelligence reports and Executive Threat Reports to be retrieved.

newspaper Executive Threat Report

Executive Threat reports are high level, visual overviews of activity and model breach events.
Refer to SaaS Executive Threat Reports for more information.

82
Models Help

exclamation-triangle Model Editor Ask the Expert

A Model is used to define a set of conditions which, when met, will alert the system to the Ask the Expert allows for the creation of incidents which can be submitted to Darktrace
occurrence of a particular event. Refer to The Model Editor for more information. analysts for feedback. Refer to Ask the Expert in the SaaS Console for more information.

System Configuration and Administration User Settings

user User Admin cogs Account Settings

User permissions can set access and view on a per-user basis. See Guide to User Privileges or Change settings for the current account including changing password, enabling Accessibility
the Darktrace System Administration Guide for a full list of User Permissions. Mode or registering the Darktrace Mobile App.

users User Groups

Allows permissions to be controlled in groups which are then assigned to multiple users,
instead of on a per-user basis.

cog System Config

Provides all configuration settings for the Darktrace Threat Visualizer application including
Darktrace RESPOND settings and authentication for SaaS modules. Alerting options can be
configured here.

tachometer-fast System Status

System metrics such as ingested traffic quality, master/probe reachability, and protocols
observed can be reviewed. The visible statistics on the Status page will depend on your
environment.

83
UNIVERSAL ELEMENTS THE DASHBOARD

A severity slider is displayed at the top left - by default, all model breaches with a score
between 0 and 100 will be shown. Moving the controls will filter out breaches which do not
have a score within the range selected. In user view, users will be filtered by the scores of the
model breaches associated with them. In User view, all users will be displayed when the slider
is set to 0.

The sensitivity slider does not affect any underlying processing, only what is currently
displayed in the dashboard.

The timeframe to display model breaches and AI analyst incidents for is located in the top right.
The available options are: Today, Yesterday, Last 24 Hours, Last 7 Days, Last 30 Days or This
Month. Clicking the user icon (user-clock) will provide options to change the current time zone.
Four headline statistics can be reviewed at the top of the dashboard; clicking on a statistic will
open the relevant interface.

The search function can be used to view user profiles or filter the dashboard by a specific SaaS
service or a specific user.

• The AI Analyst icon c opens a dialog to launch an AI Analyst investigation on the user.
• Number of Incidents opens AI Analyst for the timeframe selected.
• The profiles icon will open the profile for the specified user.
• Number of Model Breaches will expand the model breach with the highest score in
• The filter icon filter will filter all data by the platform or user specified. Filters can be the timeframe selected.
cleared by clicking the times.
• Number of Active Users opens the Profiles page.
For example, searching for “Office 365” and clicking the filter icon will filter the dashboard
(including model breaches) and the profiles page by only users within office 365. A user filter • Number of Active Antigena (Darktrace RESPOND) Actions (SaaS actions only) opens
can be applied at the user level (e.g., [email protected]) which will filter for their the Antigena Actions page.
accounts across multiple platforms, or platform-specific (e.g., “benjamin.ash@holdingsinc.
com (Office 365)”).

Using the View Acknowledged toggle will hide (Hidden) or include (Visible) acknowledged
model breaches and AI Analyst incidents. This will also affect the Number of Incidents and
Number of Model Breaches statistics displayed on the dashboard.

To logout, click the (sign-out-alt) button in the top right of the window.
84
The dashboard displays a global map of all SaaS and Cloud login activity over the last three
weeks, grouped by the ASN that the activity is performed from.

The breach graph displays all model breaches within the time frame and the associated breach
score. Nodes are colored by user, with only users with the highest scoring model breaches
during the timeframe individually represented. Clicking on a user will open the relevant entry
in the Profiles page.
An ASN is a group of IP addresses controlled by one Internet Service Provider or entity. As SaaS
activities are often performed by users on mobile devices or tethering to mobile devices, their
IP may change regularly but the ASN will stay consistent (usually the mobile provider). Greater
variation in IP address is therefore not as indicative of anomaly as large changes in ASN usage.

Hovering over a node will produce a tooltip with the exact time and model that was breached.
Clicking a node will open the breach investigation window, focused on the specific breach.

Lighter locations indicate sustained activity and darker locations are those which are rare for
the organization. Click on any location marker to see the associated IP addresses, the ASN
and the frequency at which the activities were performed. Within this information pop-up, click
the IP address or ASN to open a log overlay with events seen from that location within the
timeframe selected.

85
USING THE THREAT TRAY

On the left-hand side of the dashboard is the threat Details Pane

tray, displayed per Model or per User. This can be
altered by clicking the model exclamation-triangle button or the user user
button to switch view.

Clicking the cog cog icon will display sorting options for
the returned breaches. Model breaches can also be
filtered by the parent folder that the model is contained
within.

Clicking on a model breach or a user will open the

breach investigation overlay, centered on the
selected model or user. The investigation overlay can
be closed by clicking the times or the model/user entry
once more.

The central column contains an entry for every model On the right side of the investigation overlay is the details pane. This window contains
breach; each entry contains important information important information about the breach, the user, their historic locations for SaaS activity and
about the breach event including the time, the breach the specific interactions that triggered the breach.
ID, the SaaS service, the user involved and any display
fields that have been assigned to the model in the The user under investigation will always be displayed in the top left of the window, for example
Darktrace model editor. Where a model has breached “Details: [email protected]”.
multiple times, or a user triggered multiple model
breaches, this column will contain multiple entries - the There are three tabs available for the details pane: Events, Locations and Anomalous
cog cog icon will display sorting options for these entries. Interactions.
A description of the model and a suggested action to
take in response to the breach are displayed at the top.

When a model breach is selected, the log will open

and the relevant entry for the action that triggered the
breach will be expanded to show additional metrics. By
default, the breach investigation window will open on
the first sorted entry in Breaches list.

86
EVENTS TAB AND LOGS

Events Tab Logs

At the top of the log pane are three icons:

• The double arrow icon angle-double-up collapses all log entries so no additional metrics are visible.

• The cloud icon cloud allows the log entries to be filtered by a specific SaaS service.

• The filter icon filter controls the types of event shown in the log. Individual (and multiple)
events can be toggled, and model breaches and unusual activity notices can also be
enabled or disabled.

Log Entries

The Events tab will display a graph of all activity by the user under investigation from the start
of the timeframe until the time of the model breach. This is the default view. The graph and the
logs can be focused on a specific timeframe by clicking and dragging a window on the graph
itself.

Listed beside the graph are all event types currently displayed. Clicking the name of an event
in the key will hide it from the graph; hiding an event type in the graph will also hide it in the log
and vice versa. Shift-click the name of an event to hide all other types apart from that event. Each log entry is composed of an icon describing the kind of action or event, a short description
of the entry, the time it occurred, the user that caused it and the SaaS or Cloud platform it was
performed on. When the log is opened from a model breach, it will open with the model breach
selected, and the relevant entry for the action that triggered the breach will be expanded to
show additional metrics. Clicking ‘Load More’ will load additional event log entries until the end
of the selected timeframe is reached.

87
 OTHER MODEL BREACH TABS

Beside each event, one or more of the following icons may be displayed: Locations Tab

• The search search icon pivots to the exact entry in Advanced Search.

• Where Darktrace/Email is also monitoring the email environment, the email envelope icon
pivots to the Darktrace/Email console filtered on the selected user.

• The down angle-down and up angle-up arrows show or hide additional metrics in the logs. All log lines can
be collapsed by clicking the double arrows angle-double-up icon at the top of the log.

• Where Ask the Expert is enabled, the clipboard clipboard-list icon will appear against log entries.
This icon allows log entries to be copied to a clipboard functionality for inclusion in Ask
the Expert questions. See Ask the Expert in the SaaS Console

Please note, some buttons may not be visible due to user permissions. The locations tab displays a global map of SaaS and Cloud activity for the user under
investigation from the start of the selected timeframe, grouped by the ASN that the activity is
The pane at the right of the log will always show further information about the action, breach, performed from. Lighter locations indicate sustained activity and darker locations are those
IP or ASN selected: which are rare for the organization.

• When a model breach is selected, the right pane can be toggled between the breach The map can be toggled to show login events only using the slider in the top left.
summary and discussion, where comments on the breach can be made or reviewed.
Clicking on any location marker will produce a pop-up with the associated IP addresses, the
• When an action (log entry) is selected, the right pane will display further metrics about ASN and the frequency at which the activities were performed. Within this information pop-up,
the activity. A small arrow beside a metric (sort-down) provides additional options such as click the IP address or ASN to open an additional event log with events seen from that location
filtering the logs by the selected metric (for example, by a source IP) or reviewing more within the timeframe selected. These events are restricted by user.
detailed information in Advanced Search.

Any filters added via this method can be removed through the filter filter icon above the
logs.

• When an ASN or IP is selected, the pane will contain a summary of activity and model
breaches associated with that source over the selected timeframe. The option “View
Logs” will open a new, focused log window with activity and logs from that specific IP or
ASN across all users in the selected timeframe.

88
 CYBER AI ANALYST

Anomalous Interactions Tab Introduction

The Darktrace Cyber AI Analyst investigates, analyzes and triages threats seen within your
Darktrace environment. From a global position within the environment, the Cyber AI Analyst
accelerates the analysis process, continuously conducting investigations behind the scenes
and operating at a speed and scale beyond human capabilities.

The Cyber AI Analyst will review and investigate all Darktrace Model Breaches that occur on
the system as a starting point for its analysis process. It will then form Incidents - a collection
of one or more related events - centered around a device or SaaS user. Incidents involving
multiple devices will be classified as ‘cross-network’. Incidents created by Cyber AI Analyst
do not encompass all model breaches in the environment, only those deemed particularly
unusual or in need of further investigation.

AI Analyst incidents displayed within the SaaS Console are filtered to only show those specific
The anomalous interactions tab provides a simple visualization of all activity involved in the to SaaS and Cloud platforms. Network incidents may be reviewed from the Threat Visualizer
model breach. Each action is visualized as a series of connected nodes with directional homepage.
arrows. Clicking on an end node will fill in the chain of activity at the top left of the tab. The
key distinguishes resources, actions, services and users. Every chain of behavior relates to a Please note, the Cyber AI Analyst will only investigate model breaches of default Darktrace
model breach. models. Custom models are not currently supported.

An example chain of behavior is represented by a user (central node) acting upon a SaaS
service (cloud icon node connected to user node), performing a delete (trash can icon
connected to the cloud node) on a file (file icon node connected to the trash can).

Each node uses a simple graphical representations to give an at-a-glance awareness to

a cyber-analyst, allowing them to quickly establish the chain of anomalous behavior. For
example, a large number of file icons under a download icon indicate a user potentially about
to exfiltrate data - this can be seen quickly and without diving into the details.

89
Cyber AI Analyst View

AI Analyst for SaaS and Cloud can be accessed via the Incident stats on the dashboard or by
clicking the c AI Analyst icon from the main menu. Incidents are categorized from blue to
white, where white indicates the highest level of threat.

An incident is composed of one or more events; events are a group of anomalies or SaaS and
Cloud user actions investigated by Cyber AI Analyst that pose a likely cyber threat. Click on an
Incident to review the available “Events” and the “Details” for those events.

Click the language language icon to select an alternative language for AI Analyst incidents.

Click the AI Analyst c icon to switch between Incidents and Investigations. Incidents are
generated automatically in response to model breaches. Investigations are triggered manually
and may result in an incident if anomalous behavior is found.

90
TRIGGERED AI ANALYST INVESTIGATIONS IN THE SAAS CONSOLE

Investigating a User When an investigation is triggered, AI Analyst will

perform a close analysis of the activity for the user
To trigger an AI Analyst investigation, a device or SaaS user and a time are required. The for a period of roughly one hour, using the time
device is the subject of the investigation and the time is the starting point for analysis. provided as a central point. It will then contextualize
this behavior against historic activity and connectivity
An AI Analyst investigation can be triggered on a specific device from the omnisearch bar with for the entity and its peers. If a finished investigation
the c AI Analyst icon, or from a specific Profile in the SaaS Console with the “c Investigate” has the result “No Incident Found”, AI Analyst did not
button. locate any identifiable anomalous activity around the
investigation time. If anomalous activity is detected,
one or more incident events will be created.

Click the incident tile to open the investigation result.

Incidents created from triggered investigations follow
the same format as AI Analyst incidents created
automatically.

When an investigation is launched from a specific device or SaaS profile, the Device or
Account field is already completed.

Click Investigate to start the investigation.

Investigations

Investigations display the device or user under analysis, the analysis time, the user who
triggered the analysis and the current investigation state.

Investigations have three states - pending, processing, finished. A pending investigation

waiting for AI Analyst to start the analysis. A processing investigation_ means analysis is
underway and a finished investigation means the investigation has concluded.

In the SaaS Console, the AI Analyst view can be toggled between Incidents and Investigations
using the c AI Analyst icon at the top of the first column (Incident tray) to see current and
completed investigations.

91
SAAS AND CLOUD INCIDENTS

Selecting an incident will display the events that comprise the incident. Further information for Further investigation by an operator should prioritize the anomalous activity signposted by
each event displays on the right-hand side in the “Details” pane. Cyber AI Analyst first and the model breach conditions second if the two do not directly align.

Actions

• The download icon download creates a downloadable PDF report of the Incident.
The summary gives an accessible overview of the activity AI Analyst has detected and a
potential response to the activity an operator may take. Model breaches that triggered Cyber • The copy icon copy copies a link to the incident to the clipboard.
AI Analyst investigation will be listed as related model breaches. The Cyber AI Analyst is not
reliant on model breaches, they primarily provide a starting point for its deeper analysis of the • The check icon check acknowledges the incident event. If all events are acknowledged,
user activity around the anomaly time. the incident will be shown/hidden depending on the user settings.

• The search icon search will open the breach investigation overlay, centered on the specific • The double check icon check-double acknowledges the incident event and all related model
model breach. breaches.

Like a human, the Cyber AI Analyst uses a model breach as a starting point to investigate the
device. The behavioral analysis it performs may discover anomalies or patterns of activity
that were not the original trigger point for the model breach but are worthy of investigation.
Consequently, the event period may not correspond with the breach time. Additionally, some
model breaches require sustained behaviors such as repeated actions before breaching, so
the final breach trigger may be later than the action of interest.

92
 USER PROFILES

Finally, the right-hand panels will breakdown key elements of the event and the involved users The profiles page lists all SaaS and Cloud users detected by Darktrace; only users that have
detected in external platforms (SaaS users); the data is specific to each event type. performed an action whilst Darktrace monitoring was enabled and during the specified time
window will be listed. Here, user activity can be reviewed and investigated in more detail and
across SaaS and Cloud platforms.

The full page can be accessed from the main menu icon or via the Active Users stat on the
dashboard. Individual profiles can also be reviewed by using the search bar or as part of
an investigation workflow, for example, by clicking on an actor within an AI Analyst incident
summary.

Each entry lists the user and SaaS or Cloud platform(s) they have been detected on by the
relevant Darktrace/Apps, Darktrace/Cloud or Darktrace/Zero Trust module. The first listed
profile will open by default.

Using the search functionality to filter the profiles by SaaS or Cloud platform can be a useful
way of limiting the returned profiles to a specific subset of users or accounts.

Darktrace RESPOND

Users currently being actioned by Darktrace RESPOND have a green bar beside their profile
tile.

Hovering over the a Darktrace RESPOND icon will also display a message that the user is
under Darktrace RESPOND control.

93
User Pane Tabs

Profiles contain the same elements as the breach investigation window: a log and graph of • In the Events tab, all activity the user has performed in the selected timeframe is
user activity, further information about those actions, historic locations for SaaS activity and displayed on the graph and in the logs. Please see Events Tab and Logs for further
any anomalous interactions seen for the user. Unlike the breach window, information in these information about interacting with the logs.
elements is displayed from the start of the specified timeframe until the current time and is
updated in real time when new events are seen. Profile logs are updated in real time - the log can be paused or resumed with the pause
pause and play play icons.
The selected user is displayed in the top left of the window - SaaS and Cloud platforms they
have been detected upon are listed below. Tags applied to the user across their detected • The Locations tab contains all historic locations that the user has performed SaaS or
Cloud activity from over the specified timeframe. The map can be toggled to show
login events only. More information about interacting with the locations tab can be
found in Other Model Breach tabs.

Logs for ASN or IP are filtered by the specific user when accessed from the user profile.
To review logs for all users, please use the ‘View Logs for this IP’ or ‘View Logs for this
ASN’ buttons in the summary.

• The Anomalous Interactions tab displays anomalous chains of behavior that triggered
a model breach within the specified timeframe. Please see Other Model Breach tabs
for further information.

• The User Information tab (select SaaS Modules only) displays contextual data about
the user including group membership, assigned roles and assigned licenses, retrieved
from the SaaS environment. This contextual data provides valuable insight when
SaaS accounts are also displayed and additional tags can be added. See Tags in the SaaS investigating user behavior and potentially anomalous access.
Console for further information on adding and editing tags.

On the right are the action buttons:

• The “c Investigate” button opens a dialog to launch an AI Analyst investigation for the
user.

• The “a Antigena” button opens a dialog to perform manual Darktrace RESPOND

actions on the user.

94
TAGS IN THE SAAS CONSOLE

Tags offer a simple labelling system for users detected in external platforms (SaaS users) which Add a New Tag
can be used to identify important users, display relevant contextual data and alter model logic.
Tags can be automatically applied as a model action, used in model defeats to exclude devices, To add a new tag, click Add Tag from the Tags Manager.
or factored into model logic. For SaaS users, tags may be also be applied automatically by the
module to identify the roles assigned to the user - these tags are identified by “(CG)”. When creating a new tag, a description can be added
to help identify the purpose of the tag. Selecting a color
A small number of tags are restricted for system use only and are used to indicate devices assists identifying the tag when assigned to a device.
excluded from monitoring or behaving erratically. Click Save.

Viewing and Editing Tags The new tag will appear on the tag manager.

Tag a SaaS User

In the SaaS Console, tags are added on the profiles page for the desired user.

Tags are applied to and removed from users on a per-module basis. As Darktrace may observe
a user on multiple SaaS platforms, tags on the user’s profile indicate which environment they
Tags can be managed in the tags manager, accessible from both the SaaS Console or the are associated with. For example, “Office365 | Application Administrator (CG)”.
Threat Visualizer, or via the API (/tags). Select tags Tags Manager from the Main Menu to open
the manager. Click the plus plus icon to open a dialog to add an additional tag. In the pop-up window, locate the
tag and click on it to add to the device. Where the user has multiple SaaS platforms associated,
A list displaying all current tags will appear, optionally filterable with the search. the account to be tagged can be altered with the dropdown in the bottom left.

To review a tag, click on it. A summary page will specify (where applicable) the devices tagged,
models that apply the tag, models dependent on the tag for breach logic and models that
have the tag applied to them. All models and devices or users can be clicked. To further refine
the list, the filter filter icon can be used to add an additional tag, filtering only by models/devices
that share both tags.

To edit or delete a tag, click the pen edit icon beside the tag name.

When the user has many tags, these are collapsed and can be shown in a popup, searchable
dialog by clicking “View More”
95
SAAS EXECUTIVE THREAT REPORTS

Executive Threat Reports can be generated within the SaaS Console and present a simple Timezone
visual overview of model breaches and activity in the SaaS environment. The report is
separated into a graphical representations of network traffic (environments with network Alters the timezone of the report to that specified.
and SaaS only), model breaches and Darktrace RESPOND response and an optional detailed
breakdown more suitable for advanced audiences. Filter Breaches

Reports can cover a single day or up to 12 months (data-dependent) and can be customized Alters the report to include only unacknowledged model breaches (default), only
to include extra details or restricted to high level information. acknowledged breaches or both acknowledged and unacknowledged.

In the SaaS Console, the content of the report is restricted to only SaaS user devices and SaaS Minimal Report
breaches. The Darktrace RESPOND page is also restricted to RESPOND actions from platform
environments such as Darktrace RESPOND/Zero Trust and Darktrace RESPOND/Apps only. Generates only high level summary pages, excluding the detailed appendix.
This is the equivalent of the “SaaS Report” option in the main Threat Visualizer.
Include Comments

Includes any comments made by users or analysts in the detailed appendix.

Send Report Via Email

Emails the report to the users specified on the System Config “Executive Report Recipients”
field. This can be found beneath the configuration for Email Recipients, in the Workflow
Integrations section of the Modules page.

Generate a Report

Once all desired options have been selected, click the Generate Report button to create the
report. The generated report will appear within the window, where it can be downloaded as a
PDF.
Report Options
Previously generated reports and those over a larger timeframe can be retrieved from the
To generate a report, navigate to Threat Report in the main menu - the following configuration Download Reports page.
options are available.

Report Period

Accepts a time range for the report period. The actual date period covered will be displayed
in the two boxes beside the selector. Reports can generated for any period of less than 1 year,
data-dependent.
96
ASK THE EXPERT IN THE SAAS CONSOLE

What is Ask the Expert Open Tickets

Ask the Expert allows for the creation of incidents which can be submitted to Darktrace analysts Within the Ask the Expert page, previously submitted questions are listed with their timestamp,
for feedback. Submitted incidents can be reviewed and commented upon both by Darktrace owner, and status. Tickets can be filtered by status or sorted alphabetically or chronologically.
analysts and local users. Questions have associated statuses and function as “tickets” that can
be closed when resolved. In the SaaS Console, Ask the Expert is available from the Main Menu. Clicking on a question allows Darktrace responses to be reviewed and new comments or log
elements to be added. Questions can be closed or deleted – closing will mark the status of the
Incidents can be created with just textual input, or specific log lines and model breaches can question as closed and resolved, without actually removing from the question list.
be copied to a special clipboard for use in an incident. Where the clipboard clipboard-list icon appears,
the element can be copied to the Ask the Expert clipboard. This element, with any other
copied element, can then be inserted into a new or open Ask the Expert ticket using “Add from
Clipboard”.

97
CHAPTER 7 - ADVANCED SEARCH AND INTEL

ADVANCED SEARCH
DARKTRACE ADVANCED SEARCH 99
NAVIGATING ADVANCED SEARCH 100
CHANGING THE LAYOUT AND FILTERING ADVANCED SEARCH RESULTS 103
BUILDING A COMPLEX ADVANCED SEARCH QUERY 105

THREAT INTEL
TAXII CONFIG 107
WATCHED DOMAINS 110
TRUSTED DOMAINS 111
DARKTRACE ADVANCED SEARCH

What is Advanced Search?

Main Menu
Darktrace analyzes network traffic through Deep Packet Inspection; each connection is
processed and logs containing key metadata about the connection are produced. Similarly, Select “search-plus Advanced Search” from the main menu of the Threat Visualizer, or “search Advanced
Darktrace/Apps, Darktrace/Cloud and Darktrace/Zero Trust modules and other integrations Search” from the SaaS Console sidebar.
analyze activity data from third-party platforms and create log entries for each event. The
Threat Visualizer interface displays a relevant subset of this metadata in device event logs and Event of Interest
breach logs, however as an investigation progresses, the need can arise to review connections
and events in more detail. To review a Threat Visualizer event log entry in Advanced Search, click the caret-down triangle icon
beside the entry and select the option “View advanced search for this event”. This applies to
The Advanced Search interface provides searchable access to the detailed metadata logs all log types, including the model breach log, device event log, and event log. This option may
produced by network traffic and event analysis. For advanced users, complex query syntax not be available for all connections or events.
and data aggregation analysis are available. For those just getting started, simple queries can
be built up slowly and saved for future use. For the SaaS Console, Advanced Search can be accessed from any event log line with the search
search icon. Additionally, the caret-down triangle icon may appear beside detailed event properties such
Launching Advanced Search as actor or IP address. Selecting “Search Advanced Search for [this value]” from the options
will open a simple search for that characteristic.
There are two ways to access Advanced Search: from an event of interest or from the main
menu. 99
NAVIGATING ADVANCED SEARCH

Overview

By default, all events from the last 15 minutes are displayed in order by time, with the most The graph shows the results that match the search criteria across the timeframe selected,
recent events at the top of the screen. If Advanced Search is accessed for specific event, the grouped by the unit specified in the dropdown. The grouping defaults to larger units like Day or
time will be focused on the event time and only relevant log lines will be shown. Hour when the search period is longer. Hovering over a bar of the graph will display how many
events it contains. Clicking within the graph and dragging to create a window will zoom in on
The Darktrace icon in the top left will reset the page to the current time with no search and the that timeframe and filter the log events accordingly.
default timeframe selected.
Each page displays 50 results, sorted by time from newest to oldest. The “backward Older” and
Searches can be manually typed out in the search bar or constructed from the building blocks “Newer forward” buttons can be used to move through the results, or the step-forward return button to return
available - how to perform a search will be explained in more detail later. to the start. Matching results can also be exported as a CSV file.

To the left of the search bar is the current search timeframe - this can be selected from one The notepad functionality can be used to note down interesting connections or analysis
of the preset options or entered as a custom timeframe using the date selectors above the comments. Local storage must be enabled to use this feature, as well as saved layout and
graph. The search period can also be moved forwards or backwards using the arrows below searches.
the graph.

100
 Searching Advanced Search

Default Layout A query consists of a field and a value, for example @type:"dns" where @type is the field
and "dns" is the value. Simple searches for values like IP addresses or SaaS credentials, as
By default, the columns displayed are (from left to right): well as wildcards (*) are also supported.

• Time: Date and time that the log entry was created, in the time zone of the device used Multiple fields and multiple values can be connected together with comparators, for example:
to access Advanced Search. Dates are shown in ISO format: YYYY-MM-DD hh:mm:ss.

• @type: The log entry type - may be the protocol that was inspected, an event such as
a connection or refer to the module that created the entry. For example: @type:conn
indicates a connection, @type:kerberos indicates the protocol Kerberos was @type:"dns" AND @fields.source_ip=10.1.23.2. These additional conditions can
inspected and @type:Office365 indicates the entry was analyzed by the Darktrace/ be added manually, or by using the following buttons:
Apps Microsoft 365 module.
• The equals equals button adds a new AND condition to the current search.
• @message: A tab-separated summary of the fields contained within the log entry.
Some fields are included in the detailed log entry but not in the message field. For @ • The not-equal does not equal button adds a new AND NOT condition to the current search.
type:notice, a list of possible messages is available.
As a search term is entered, Advanced Search will attempt to match it to saved searches
(name and query) and the last 10 historic searches. Matching searches will appear in a list
below the bar.

Saved searches are listed by the name given and indicated by the save save icon. Historic
searches are indicated by the history history icon.

Please note, these features require local storage to be enabled. If local storage is disabled,
historic and saved searches will be lost.

Set the timeframe to 15 minutes, enter @type:"conn" in the search bar and click Search. All
connections processed by Darktrace in the last 15 minutes will be returned. For deployments
with no network traffic, such as SaaS or Cloud only, substitute conn for a log type that can be
seen in your environment such as @type:office365 or @type:amazon.

101
Investigating an Entry Each row of the table can also be used to refine the current search or start a new search based
on the log entry.
From the search results, click an entry to expand the event and show a table with a list of fields
and their values. • The equals equals button adds the field and its value as a new AND condition, narrowing the
query to only those entries which match that value. For example, clicking this button in
the @fields.proto row would add AND @fields.proto:"udp" to the query and
limit the valid results to only those connections using UDP.

• The not-equal does not equal button adds the field and its value as a new AND NOT condition
to the current search, effectively results which have that value in the specific field. For
example, clicking this button in the @fields.service row would add AND NOT @
fields.service:"dns" to the query and exclude any DNS queries from the results.

• The sync circular arrows button does not modify the current search and instead starts
a new search using the criteria in the entry. When this button is clicked in a row, a new
In the left column are fields - distinct pieces of data or metadata that are produced during search is created with the Source IP and Destination IP of the entry, as well as the field
analysis. Each log contains universal fields such as the time the entry was created (@ and value in the row where it was selected. For example, the row @fields.dest_port
timestamp), a unique identifier (@fields.uid) and type specific fields which are only would create a new query: @fields.source_ip:"10.0.18.224" AND @fields.
produced for that protocol or log type (@fields.saas_actor, @fields.query_class). dest_ip:"192.168.72.4" AND @fields.dest_port:"53".
Some fields, such as source and destination IP fields, are shared across connection log types
and others are optional - appearing only where a value can be found in the processed traffic
or event.

In the right column are the values that were derived for each fields during processing and
analysis. Where a value has a external-link-alt link icon, the Threat Visualizer interface can be opened with a
focus on that value. For example, focused on a specific connection (@fields.uid) or device
(@fields.dest_ip) in the event log.

102
CHANGING THE LAYOUT AND FILTERING ADVANCED SEARCH

Changing the Layout Field Summaries

On the left of the page is a list of fields which appear in the results; the list can be collapsed When the name of a field is clicked, a pop-up will appear with a breakdown of values seen and
with the chevron-left hide button. Each field listed can be added as a column in the results, making it options to perform data aggregation queries.
easy to compare the value across all entries. This can be particularly useful to identify unusual
log entries within a wide search criteria, or where the connection of interest is not yet known.

Adding, as an example, @fields.dest_port as a column allows an operator to quickly skim a

list of connections for anomalously high ports or those unusual for the protocol under analysis.

• The plus plus icon adds the field as a column in the results. The default @type and @
message columns are removed. Some fields are optional and will not return for all log entries - optional fields can be added as
a requirement or an exclusion from the current search query:
• The minus minus icon removes a column from the results layout.
• The equals equals button beside the name of the field will add a condition to the query that
Useful layouts can be saved by clicking the save save icon and providing a name for the layout field must be present in each result. This takes the format AND _exists_:"@fields.
template (Requires local storage). Existing templates can be loaded by clicking “Columns caret-down” example".
and selecting from the dropdown.
• The not-equal does not equal button beside the name of the field will add a condition that
the field must not be present. This takes the format AND NOT _exists_:"@fields.
example".

The number of results that include the field in question can also be highlighted by clicking “#
events on this page”.

103
The Values tab shows a summary of the values across The Field Description tab shows a brief description of
the 50 results currently shown on the page, sorted the information the field contains. The same field may
by frequency of occurrence. The summary allows an appear in multiple protocols but perform a different
operator to get a sense of the logs returned and spot function - in this case, all possible type/description
outlier results which may be unusual. Beside each combinations are listed.
result is the percentage of log entries that include that
value in the specified field - clicking a value highlights
the log entries it appears in.

• The equals equals button beside each value adds

the field and its value as a new AND condition, Data Queries
narrowing the query to only those entries which
match that value. Where the value is ‘Blank’, a At the bottom of each field summary are four buttons: “Score”, “Trend”, “Terms” and “Stats”.
AND NOT _exists_:"@fields.example" These buttons perform specific operations on the data returned by the search query and can
condition will be added instead. be very useful to summarize large numbers of results.

• The not-equal does not equal button adds the field

and its value as a new AND NOT condition to
the current search, effectively results which
have that value in the specific field. Where the
value is ‘Blank’, a AND _exists_:"@fields. • The Score action ranks values by frequency across the most recent 10,000 log
example" condition will be added instead. entries that match the overall search query. Up to 100 values will be ranked in order
of occurrence. In large instances, up to 100,000 results may be available for analysis.
The Related Fields tab shows other fields that
frequently appear in the same log entries as the • The Trend action provides an estimation of the change in frequency for values across
selected field. Related fields are ordered by the the time period. A segment of matching entries at the start and end of the time period
percentage frequency that they occur alongside the are analyzed and the change in value occurrence calculated.
selected field out of all currently displayed log entries
where the selected field appears. • The Terms action also ranks values by frequency across log entries that match the
query. This action is faster and performed against a larger number of results than
the Score analysis, however it provides a less precise count. The number of entries
analyzed where the field was missing will appear as a blank row above all other values.

• The Stats action is only available for fields with numeric values. This analysis produces
statistical information about the field value across the timeframe including the average
value, the sum, the count and the min/max limits. In this mode, each bar of the graph
displays the mean field value during that time interval on hover.

104
BUILDING A COMPLEX ADVANCED SEARCH QUERY

Constructing a Search Searching by Field

Advanced Search allows for complex structured searches to be performed to retrieve detailed To search for (or within) the value of a field, use the name of the field followed by a colon:
log information on connections. A wide starting search can be quickly focused using the
buttons found across the interface to include and exclude values and fields. Examples:

Searches over a longer period will take longer to complete. Searches that take too long will @fields.host:www.darktrace.com
be aborted to prevent negative impacts on the performance of other parts of the Darktrace @fields.source_ip:10.10.*
system. Narrowing the scope of the search by time or by making a more specific query will
help the search to return results more quickly. For numeric values, greater-than (>) and less-than (<) operators can be used to identify values
above or below a certain threshold.
Basic String Search
Example:
Words can be entered freeform and will be looked for across all values in the database.
Enclosing a value in quotation marks will search for an exact string match and treat spaces as @fields.orig_bytes:>0
part of the search term.
The notation TO within square brackets designates a range of numbers.
Example:
Example:
"google"
@fields.dest_port:[6881 TO 6999]
A wildcard (*) can be used to represent any number of characters,
The example above identifies a range of ports associated with the use of the BitTorrent file-
Examples: sharing protocol.

*.darktrace.com Please note, this notation is not compatible with IP address ranges.
@fields.certificate_issuer:*.com AND @fields.certificate_subject:*.net

The latter example matches specific top-level domain extensions - regardless of the hostname
- that are indicative of encryption certificates used by TOR nodes.

105
Combining Search Conditions

Conditions can be combined using the standard Boolean operators AND, NOT, OR. Most
conditions added using the equals equals and not-equal does not equal buttons will take this format.
Parentheses are also supported to group search conditions together

The default operator (if no operator is specified) between space-separated values is AND.

Examples:

@type:conn AND @fields.proto:"tcp"

@type:"azuread" AND (@fields.saas_metric:"Saas::Login" OR @fields.saas_
metric:"Saas::FailedLogin")

Boolean operators can also be used within parentheses to create shorter queries - the
following two examples provide the same outcome.

Examples:

@fields.source_ip:10.10.4.3 OR @fields.source_ip:10.10.4.4 OR @fields.

source_ip:10.10.4.7
@fields.source_ip:(10.10.4.3 OR 10.10.4.4 OR 10.10.4.7)

Regular Expressions

Basic Regular Expressions (regex) can also be used for very specific searches.

A regex must be preceded and followed by a forward-slash character (/)

Example:

@fields.host:/w{3}\.darktrace\.co.+/

Regular expressions can also be combined with the previous syntax examples.

Complex Queries

Advanced Search supports the Lucene 4 Query syntax

106
TAXII CONFIG

Accessing TAXII Config Servers

Darktrace can connect to TAXII servers and also import STIX XML files, these are used to Lists the hostnames of currently configured TAXII servers with details of the specific polled
provide threat intelligence. The Threat Indicator model will create model breaches when an feed (collection).
observable derived from TAXII intelligence is seen.
IOCs
Darktrace supports the following indicators: Domains, Hostnames and IPv4 addresses. URIs
are not supported. Each indicator will be searched for historically and added to the watchlist The “total” value corresponds to the number of IoCs that have been collected from the TAXII
in case it appears in the near future. TAXII services with multiple polling endpoints are not feed.
currently supported.
IoCs that have been checked against the network and successfully added to the watchlist are
To access the TAXII Config page, navigate to the main menu and select Intel > TAXII Config considered “processed” - this is displayed by the ““% Processed” value. If the Valid Until field is
from the available options. The page is also accessible from the Modules section of the a date before the Source Time (the time when the IoC was received by Darktrace) the IoC will
System Config page, or from the sidebar of another page in the Intel category. not be processed.

Summary STIX Inbound Sources

The summary page gives an overview of the TAXII servers and feeds subscribed to and the The STIX inbound sources page displays details of the last 10,000 observables received by
IoCs derived all sources. Darktrace. Each entry will describe the time of the last seen observable, the confidence and
the processed observables from the feed. To view all ingested IoCs from each source, click the
expand project-diagram icon beside the source name.

Sources

The number of sources that have contributed IOCs - includes manual uploads and TAXII fees.

107
 ADDING TAXII FEEDS & STIX FILES

Sources are derived from information contained within each STIX package - for STIX 1.2, this TAXII Services
is typically the “Information Source” field. Information derived from STIX uploads and TAXII
feeds can be viewed on the STIX Inbound Sources tab. For STIX packages uploaded without a TAXII threat intelligence feeds can be added on the Configure TAXII Servers tab.
defined “Information Source” field, the source will be ‘Ingested’. Where the STIX file originates
from a defined feed and no source is provided, the source will default to the collection. STIX
files produced by Darktrace Inoculation will have the source ‘Darktrace’, or rarely ‘Inoculation’
in the case of older IoCs.

Confidence

Each source will be assigned a default confidence of 50%. The source confidence can be
modified by clicking the edit edit icon beside the source name.

• When a feed is initially added, Darktrace will request STIX packages that are a maximum
of 2 weeks old. Subsequent queries will ask for STIX packages which have arrived on
the TAXII server since the last known threat indicator received from that service.

• When polling is turned on, Darktrace will poll the TAXII server for new IoCs at the stated
interval.

• Indicators which are downloaded in a STIX package from a TAXII service are then
checked against data within Darktrace.

• Each IoC will be checked against historic connection data up to 2 weeks in the past
(dependent on data stored).

• Each IoC will be added to the Watched Domains/IPs list with a default expiry date of
two weeks in the future.

• If the STIX package includes a ‘valid until’ date this will be used as an expiry time for the
IoC in the Watched Domains/IPs list.

108
Adding a TAXII Feed Uploading a STIX file

On the Upload tab, STIX files can be uploaded. Darktrace supports the following indicators:
Domains, Hostnames and IPv4 addresses. URIs are not supported. Each indicator will be
searched for historically and added to the watchlist in case it appears in the near future.

Navigate to the Upload tab and select the STIX-formatted XML or JSON file for upload. STIX
versions 1.1.1, 1.2, 2.0 and 2.1 are supported. On successful upload, the number of observables
and metadata fields derived from the file will be displayed. These can be reviewed on the
Inbound Sources tab.

1. Navigate to the Configure TAXII Servers tab and click “Add New TAXII Service”.

2. Complete the required details of the TAXII feed Hostname, Collection, Discovery Path.
Fields indicated with a * are mandatory.

3. Select a polling time in seconds to refresh the feed. There is a maximum setting of
86400 seconds (1 day) and a minimum of 60 seconds. This is the time between polling
the individual TAXII services.

4. From the dropdown, select the STIX/TAXII version sent by the TAXII server.

5. Optionally configure a proxy and any authentication fields required by the third-party
feed. Multiple methods are supported including Basic, Client Certificate and JWT
authentication.

6. Finally, add the service by clicking Save Changes.

Ensure that TAXII polling is enabled or the feed will not be refreshed.
109
WATCHED DOMAINS

Watched Domains Adding New Entries

Watched domains are endpoints of concern - whether due to known compromise, anomalous At the top-right corner of the Trusted Domains
behavior or compliance - which will trigger a model breach and optional Darktrace RESPOND/ workspace, click Add to add new domains, hostname,
Network response if observed in ingested traffic. IP addresses or IP address ranges to the Watched
Domains list. If adding a range of IP addresses, the
Domains can be added manually, through the API (/intelfeed), or via configured STIX/TAXII maximum subnet range is /8 (previously /16).
intelligence feeds. No default list exists for watched domains. The Watched Domains page
accepts the following formats when added manually: Choose between Import CSV or Manual Input from
the drop-down menu.

• Choose Import CSV to upload an appropriately-

formatted CSV format file.

• Choose Manual Input to add an IP address,

domain or IP address range. The endpoint
entered will be automatically detected as a
Domain, IP or Hostname.

The Exact Hostnames flag indicates the value should be treated as an exact string
only.

A free text Description, a selection of Sources, an Expiry Date, and a Strength from 1 to
100 can be set.
• IP addresses (192.168.0.1)
Finally, Flag for Antigena will trigger an automatic Darktrace RESPOND/Network action
• domains (example.com) and domains with a single subdomain (example.example.com) if the entry is seen.

• IP address ranges (maximum subnet range is /8, previously /16) To add multiple endpoints concurrently, while at the Manual Input panel, click +Add
another domain and a further free-text field will appear. This entry will share the
An advanced configuration setting is available to allow a greater number of subdomains. parameters of the previous entry.

Access the Watched Domains page from the Threat Visualizer main menu under Intel. When all the information has been input, click Add to Watched Domains.

In the Watched Domains workspace, all hosts, IP addresses, IP address ranges and endpoints At the bottom of the screen, a notification will confirm the new addition.
on the watch list are listed and searchable. At the top-left corner of the workspace, you can
use a free text search bar to locate a specific entry, and results can be filtered by clicking the
filter filter icon. The default option is to search by Domain/IP address, which can be altered to
Description and Source from the drop-down menu. 110
 TRUSTED DOMAINS

Deleting and Exporting Endpoints Trusted Domains

Trusted domains are domains which Darktrace considers as 0% rare. This feature ensures
that models relying on domain rarity will not fire for activities involving common domains such
as “google.com”. The list includes Domains, IP Addresses and IP Address Ranges. There is a
default list, to which entries can be added on the Trusted Domains page.

Access the Trusted Domains page from the Threat Visualizer main menu under Intel.

Delete an Endpoint

To delete a specific trusted endpoint from the list, click the square square icon on the left side of
an entry.

The icon will become ticked check-square and the Delete button on the top right will illuminate. Click
Delete to remove the selected entry.

To delete multiple entries, select all applicable entries and click Delete.

To delete all entries, select the checkbox at the top of the list to select all entries, and then
click Delete.

Export an Endpoint

To export a specific trusted endpoint, select the square square icon on the left side of an entry. In the Trusted Domains workspace, all endpoints that have been deemed as non-rare, or
added by a user, are listed and searchable. At the top-left corner of the workspace, you can
The icon will become ticked check-square and the Export Selected button on the top right will illuminate. use a free text search bar to locate a specific entry.
Click Export Selected to export the selected entry in CSV format.

To export multiple entries, select all applicable entries and then click Export Selected.

To export all entries, select the checkbox at the top of the list to select all entries, and then click
Export Selected, or without selecting any entries click Export All.

Both actions will exporting all trusted domains as a CSV file.

111
Adding New Entries Deleting and Exporting Endpoints

Trusted endpoints are excluded from rarity calculations

and models which use domain rarity - be careful when
selecting new endpoints to be added.

At the top-right corner of the Trusted Domains

workspace, click Add to add new domains or IP
addresses.

Choose between Import CSV or Manual Input from Delete an Endpoint

the drop-down menu.
To delete a specific trusted endpoint from the list, click the square square icon on the left side of
• Choose Import CSV to upload an appropriately-formatted CSV format file. an entry.

• Choose Manual Input to add an IP address, domain or IP address range as free text. The icon will become ticked check-square and the Delete button on the top right will illuminate. Click
Delete to remove the selected entry.
To add multiple endpoints concurrently, while at the Manual Input panel, click +Add
another domain and a further free-text field will appear. To delete multiple entries, select all applicable entries and click Delete.

When all the information has been input, click Add to Trusted Domains. To delete all entries, select the checkbox at the top of the list to select all entries, and then
click Delete.
At the bottom of the screen, a notification will confirm the new addition.
Export an Endpoint

To export a specific trusted endpoint, select the square square icon on the left side of an entry.

The icon will become ticked check-square and the Export Selected button on the top right will illuminate.
Click Export Selected to export the selected entry in CSV format.

To export multiple entries, select all applicable entries and then click Export Selected.

To export all entries, select the checkbox at the top of the list to select all entries, and then click
Export Selected, or without selecting any entries click Export All.

Both actions will exporting all trusted domains as a CSV file.

112
CHAPTER 8 - MODEL EDITOR

USING THE MODEL EDITOR

THE MODEL EDITOR 114
MODEL EDITOR OVERVIEW 115

UNDERSTANDING A MODEL
LOOKING AT A MODEL 117
COMPONENTS AND FILTERS 118
MODEL BREACH LOGIC 119
MODEL CONDITIONS AND SCORING 121
MODEL ACTIONS 122
MODEL DEFEATS 124
OTHER MODEL TABS 125
MITRE ATT&CK MAPPINGS 125

MAKING A NEW MODEL

CREATING A NEW MODEL 127
ADDING COMPONENTS TO A MODEL 128
ADDING FILTERS TO A MODEL COMPONENT 129
DEFINING MODEL COMPONENT BREACH CONDITIONS 132
TUNING MODEL SCORING 134
TIPS FOR NEW MODEL MAKERS 136
THE MODEL EDITOR

Introduction to the Model Editor Model Updates

Darktrace models are a series of logical statements and conditions which, if met, trigger an Darktrace will periodically update the standard supplied models – either automatically for
alert or action; models are primarily used to identify and alert on anomalous and potentially customers with Call-Home, or manually through software updates. If changes are made to a
malicious behavior. The Threat Visualizer platform provides a curated set of default models as model logic outside of the defeats system, it will no longer be eligible for automatic updates.
standard, designed and constantly tuned by the specialized Darktrace analyst team. Darktrace-
maintained models are frequently updated in parallel with the evolving threat landscape. Please see Upgrading Darktrace Models or the System Administration guide for more
information.
The models framework leverages both the underlying ‘pattern of life’ detection and outputs
from Darktrace Deep Packet Inspection, telemetry inputs, Darktrace/Apps, Darktrace/Cloud
and Darktrace/Zero Trust modules. Output from the complex anomaly framework is available
in accessible, building block format and can be combined with simple conditions and logical
expressions to create tailored activity detection.

Models can also be used to profile a device, assign tags, highlight misconfigurations or trigger
autonomous responses from the Darktrace RESPOND framework. Creating custom models
can be a straightforward and powerful way to integrate Darktrace into your existing security
processes or replicate a SOC playbook.

114
MODEL EDITOR OVERVIEW

The Model Editor Model List

In the Threat Visualizer interface, the Model Editor is accessible from the main menu under Models are sorted into folders which describe the
Models > Model Editor or from any breach log with the “ Click to view model” button. From general purpose and detection area of the model.
the SaaS Console interface, the Model Editor is available from the sidebar (“exclamation-triangle Model Editor”). Models can also be tagged to identify the purpose or
the potential attack phase for the activity it detects.
Using tags can be particularly useful when categorizing
custom models or when constructing filters to send
email alerts to specific teams or users.

When the view is set to tags, all tags applied to models

are shown in the sidebar. Clicking on a tag will list
all models it is applied to. Above the model list is a
selection of suggested tags to filter by - clicking these
suggested tags will add them to the filter. Tag filters
can be removed with the trash-alt trash icon.

The list of models can be sorted alphabetically, by

The editor is comprised of a list of current models (left) and a main workspace where model priority, by creation date or by last edited date.
logic can be reviewed and edited. If the editor is opened from an event log - such as a model Searching for a keyword or model title will filter the
breach log - the main workspace will be focused on the model. list of models and folders to only those with a title that
matches the search terms.
The home home button can be used to return to the main Threat Visualizer interface and the
log out button to exit the Threat Visualizer platform. The ellipsis-h more options button in the top Clicking the name of a folder or the line beside a folder
right provides access to the legacy model editor, bulk model import and bulk model export will expand to show the models and subfolders it
functionality. contains. Clicking again will collapse the folder. The folder-tree
directory icon collapses all open folders.
The Active Only toggle hides models which have been disabled. De-activating a model can be
a useful way of preserving the logic for future tuning without removing it entirely. Deactivated
models in the model list are indicated by darker text.

The “Add” button opens a new, blank model for configuration. New models will be covered in
more detail in Creating a New Model.

115
Models can also be sorted by the action they perform The following options are available for bulk edit:
as a result of breaching. This can be a useful way to
identify all Darktrace RESPOND models (“Antigena”), or • Model Priority
all models which apply tags.
• Active status
When the view is set to action, all model actions are
shown above the list of models. Clicking on an action • Auto Updates
will list all models that perform it. Additional actions
can be added, or filters can be removed with the trash-alt • Auto Suppression
trash icon.
• Automatic Antigena

Bulk Actions • Model Tags

Certain settings can be changed across multiple The purpose of these settings will be covered in more detail as we proceed through the model
models at the same time using bulk actions. When editor overview.
one or more model is selected, a dropdown will appear
where the sort option was previously. Individual Models

• Clicking the check-circle tick icon that appears to the left Beside each model in the list is an question-circle info icon. Clicking this icon will open a summary tooltip
of the model name will select that model. containing:

• Clicking the check-circle tick icon that appears to the left • The Folder(s) the model is in.
of a folder name will select all models contained
within. • The model title.

• Clicking the circle circle icon at the top left of the • Tags applied to the model, if applicable.
list below ‘Folders’ will select all models.
• The model priority.

• Actions in response to a breach.

• A Model description, where available.

• Last edited date.

116
 LOOKING AT A MODEL

The tooltip can be useful to quickly review a list of models in a folder before selecting one to For this example, we will look at a version of the “Anomalous Connection / 1 GiB Outbound”
duplicate for editing purposes. model. Clicking on the name of any model will open the model overview on the right.

Please note, as Darktrace models are tuned and updated with high frequency by a specialized
analyst team, the versions of the model here may not correspond with the versions in your
environment. These models are only used for example purposes and the concepts apply to
any model - custom or default - which you may encounter.

Main Overview

At the top of the overview is the folder, the model name and any tags applied. Both the top-
level folder and tags can be used as filters in the threat tray. Underneath is a description of the
behavior the model is targeting and a potential action to take in response to a model breach.

Click on a model to open a detailed overview in the right-hand pane.

There are three toggles:

• Active: Determines whether the model is active or not. Allows the user to turn a model
off - rather than deleting it and having to recreate it at a later date - so it will not breach
during that time.

• Auto Update: Where models are set to update automatically in the global config
setting, individual models can have auto-update disabled so that updates must still be
manually approved.

• Auto Suppress: Determines whether this model will be automatically suppressed if it

breaches repeatedly in a short timeframe for the same device and with the same set
of breach conditions. If a repeatedly breaching model is suppressed, from that point
onward it will generate at most one breach per week for any given device and the same
breach conditions. Recommended for most models.

117
 COMPONENTS AND FILTERS

Breach Logic Tab Components

The first tab of the model overview contains a summary of the model logic. Models are Components are made up of metrics and filters. Each component looks at exactly one metric,
constructed from components - a series of logical statements evaluated against a connection, filtered with zero or more filters. The metric is the main behavior, event, or condition that defines
event or device. the component, and filters are restrictions or stipulations that matching events or activity
must meet for the whole component to be satisfied. The list of filters changes according to
the selected metric - only filters that are relevant to a metric are available.

Metrics can cover many different types of activity or event, for example:

• Specific activity performed by a device, such as number of connections or volume of

data transfer.

• Distinct events, such as a failed login to a SaaS platform or the use of a new credential.

• Activity deemed unusual in comparison to the ‘pattern of life’ and other outputs from
Darktrace Cyber AI.

• A reference to components in another model or Antigena (Darktrace RESPOND)

A model may have more than one component. The dropdown indicates the relationship actions that have taken place.
between those components that is required to produce a model breach. There are two types
of component relationship: “All Components Are True” and “A Target Score is Reached”.

All Components Are True

In this mode, all components in the model must evaluate as “true” for the model to breach.
This is known as a ‘checklist’ model.
In this example, the metric is “External Data Transfer (Client)” and the activity must meet the
A Target Score is Reached condition “> 1 GiB” within the timeframe of 1 hour. The component is therefore targeting large
data transfers from standard, non-server devices to an external location. Each component is
In this mode, components are assigned a positive or negative weighting and a target score summarized in this way to give a quick understanding of the type of activity that it is looking for.
is set for the whole model. This is known as a ‘weighted’ model. If a component evaluates
as “true”, it then contributes the ‘points’ it has towards the target score. A negative weighting
can be used as a control. If enough components evaluate as “true” to meet the target score
in the timeframe specified, the model will breach regardless of the status of any remaining
components.

118
 MODEL BREACH LOGIC

Filters Breach Conditions

The number of filters applied to the metric is also listed - click the component line to expand Each filter is assigned an alphabetical reference which is used to define the breach conditions.
the filters. Breach conditions for a component are a list of possible filter combinations that should trigger
a breach. In this example model, the relationship between the three filters is very simple - all
Here, there are three filters applied to the External Data Transfer: the data transfer must be three filter conditions must be met for the component to evaluate as true - and therefore the
outbound, it must be to the same IP and it must not be to an address in the Multicast network breach conditions are represented as “A & D & E”.
range.

Frequently a component will have many filters which cover different scenarios or act as
controls, where the filters are not intended to all be used at once. In this case, multiple lines of
logic will be defined in the Breach Conditions.

For example, the “Active Remote Desktop Tunnel” model has “Active Connections” components
where the filters correspond to a selection of ports. Each filter in this case reflects a slightly
different connection scenario and consequently, multiple combinations of these filters can
trigger a breach.

119
 Where a component has multiple lines in the breach conditions, these should be treated as an Display Fields
‘OR’ relationship. In this example above, the logic looks like “A & B & E & I OR B & D & E & I OR B
& E & H & I”. For a component to evaluate as true overall, one of these lines of breach condition Display fields are extra filters which do not have an impact on the component logic. Instead,
logic must be satisfied. they are used to include additional information in the model breach alert or breach log entry
when a component breaches. For example, adding a display field of “Source Port” will result
in the port number that the breaching connection originated from being included in the log.

Display fields make it easier to triage model breaches in the threat tray, as you can quickly see
the interesting features of the activity Darktrace has detected as anomalous.

120
MODEL CONDITIONS AND SCORING

Component Settings Weighted Model

Where a model has more than one component, component settings can be defined which
limit the timeframe and order in which components must be triggered for a model breach.
Component settings available differ between the two model types: checklist and weighted
models.

Checklist Model

Target Score

All components must be breached in the above order The total score that must be reached when adding the points assigned to triggered
components to create a model breach.
When true, components must be triggered in order from top to bottom. Components can be
rearranged by clicking and dragging. Delay Breach

All components must be breached within the following seconds If the model has a negative component, this option will appear. If turned on, adds the “Delay
Breach By (seconds)” field to specify a delay to allow activity to happen that meets the negative
A limit on the time within which all components must trigger for the model to breach overall. component’s criteria.

All components must share endpoints Delay Breach By (seconds)

Requires components to be triggered by the same destination endpoint for the overall model Minimum delay in seconds after a positive-scoring component has fired before the overall
to breach. This option will not be displayed if there is only one component in the model. model score is calculated. This option is useful to prevent a model breach where the negative
component activity may occur shortly after.

Target Score must be reached within the following seconds

A limit on the time within which enough components must trigger to reach the target score, so
that the model may breach overall.

121
 MODEL ACTIONS

All components must share endpoints Model actions are system actions which can be triggered in response to a model breaching.

Requires components to be triggered by the same destination endpoint for the overall model
to breach. This option will not be displayed if there is only one component in the model.

Score Modulation

Determines the modulation curve for this model – when the same device repeatedly breaches
a model, the score of subsequent breaches will be adjusted. For some behavior types,
repetition indicates that the activity is likely less worthy of attention from the security team.

Generate Model Breach (+ Breach)

The most basic response is breach, which triggers the system to generate a model breach
alert in the Threat Visualizer threat tray. In the majority of cases, triggering a threat tray entry
For other behavior types repetition makes the activity potentially more serious. Selecting a is desirable to alert Threat Visualizer users to the activity detected. Where a model is used
modulation curve will determine how the scoring of repeated breaches for a given device for identification purposes - for example to tag a device that exhibits specific, non-malicious
should be adjusted. behavior - producing a threat tray entry is not desirable and the breach action can be removed.

The model’s priority will affect the strength with which it breaches, so that if particular types of
behaviors are of greater interest to you, these behaviors will register as more strongly relevant
and will be more obvious in the threat tray than if the priority was lower. Breach priority can also
be used to control alerts to external systems where a model is also set to alert.

Alert External Systems (+ Alert)

The next step from generating a threat tray entry is the alert action. A model with this action
will trigger the system to send an alert to all configured alerting outputs. Only models with this
action will trigger external alerts.

122
Antigena (+ Antigena) Tag Device (+ Tag Device)

Darktrace RESPOND (formerly “Antigena”) is the framework that takes autonomous actions A model can add a tag to a device on breach. This can be particularly useful where models are
in response to potentially malicious activity. Default Darktrace RESPOND/Network actions are used to profile a device or to mark a device as high risk due to its behavior. Tags can be given
triggered with meta-models which look for the presence of one or more Darktrace RESPOND an optional expiry date; a device can therefore be added to a ‘risk pool’ for a set amount of time
(Antigena) tags on a model breaching device. Darktrace RESPOND capability can also be in response to a model breach, and automatically leave it after a set period such as two weeks.
added directly to a model by adding this ‘Antigena’ action section. Inhibitors - response
actions - can be selected for each Darktrace RESPOND type enabled on the deployment. Device Type (+ Device Type)
Inhibitors can be automatic, where Darktrace RESPOND selects the most appropriate action
at the time, or pre-defined from the list of options. By default, inhibitors will be active for one Darktrace detects device types automatically and assigns a most likely type based upon
hour (3600 seconds). device activity and traffic analysis. Device types can be overridden on the Device Admin page
or via the API. Models can also reassign device types as an action. Instead of setting device
Automatic Antigena controls when the action is taken without human confirmation. If set types manually to match asset registers, a model can be configured to match a hostname
to “Force human confirmation”, the model will always ask for confirmation before taking an convention and assign device types accordingly. The additional benefit of a model is that
action - regardless of the global state. In “Take autonomous action” mode, a response will be new devices will be assigned automatically as they appear and trigger a breach, reducing the
taken automatically unless confirmation for actions is required globally. If “Force autonomous amount of repeated manual configuration required.
action” is chosen, the model will override the global schedule and always take action without
confirmation. Model

Optionally, a threshold can be defined which restricts Darktrace RESPOND response to The Model action is a default action applied to all models.
breaches of the model that exceed the limit. For models where the threat score reduces
over time, it can be desirable to take autonomous actions against the first one or two model
breaches but not after that point. The Darktrace RESPOND Threshold therefore sets the
lowest breach score above which Darktrace RESPOND will take the specified response.

Assign Priority Score (+ Priority Score)

Device priority is a scoring system which marks device importance - higher priority devices
will produce higher model breach scores. Device priority can be increased and decreased as
a model breach action. For example, a model which profiles devices may increase the priority
of a device if it displays activity consistent with a server. Similarly, a model breach can be used
to raise the priority of a device so that future alerts - which may indicate a developing security
event - are more prominent and higher scoring.

123
MODEL DEFEATS

What Are Defeats?

Defeats are different from negative filters. Filters in the model logic limit the connections, In this example, the model is prevented from breaching if the device that sends data
events or activity eligible to trigger a breach down to only those that are relevant. These are outbound has a hostname that matches the regular expression (u-infra-)[0-9]+.When
integral parts of the model logic. Defeats are specific conditions which prevent a model from the comparator is positive - e.g. “matches”, “is”, “contains” - the defeat essentially excludes a
breaching - they are distinct from the logic. Because of this distinction, defeats are specific subset of devices or activity from triggering a breach.
to each environment and do not prevent the main model logic from being updated. Adding
a defeat to a Darktrace-maintained model does not make it ineligible for model bundle Defeats can also be used to limit the scope of a model - this is a very powerful tool to tailor
updates. models to your environment but must be carefully executed to avoid over-limiting. For example,
adding the following defeat would restrict the model to only breach when the device has the
Defeat conditions offer more specificity than device-based exclusions or restrictions and can File Server tag:
also target a large range of devices by characteristics like device type or hostname. Defeats
can be a useful tool to tune existing models to suit your environment as your deployment [Tagged internal source] [does not have tag] [File Server]
develops, whilst also leveraging the expertise of the Darktrace analyst team as they update
default models to match the ever-changing threat landscape. If a defeat condition evaluates as true, it prevents the model from breaching entirely. In the
above case, the defeat will evaluate as true for all devices not tagged with “File Server” -
essentially limiting the model to only breach when the device is tagged.

Defeats with negative comparators can therefore constrain a model to very specific breach
criteria.

In contrast to components, no defeats can evaluate as true for the model to breach - each Bulk Editing Defeats
defeat should be considered as a series of “AND NOT” logic lines against the whole model.
Where the model is a checklist, the overall logic can be thought of like: Defeats can be downloaded and edited as a .csv file, then re-uploaded to the model. This can
be a quick way to add the same defeat conditions across multiple models.
[component 1] AND [component 2] AND NOT [defeat 1] AND NOT [defeat 2]

For example, an organization has an update infrastructure that regularly sends large files
to external locations - all internal devices in that infrastructure use a hostname convention
“u-infra-##”. These devices can be excluded from the scope of the model with the defeat:

[Internal source device hostname] [matches regular expression] [(u-infra-)[0-9]+]

124
MITRE ATT&CK Mappings
OTHER MODEL TABS

Models curated and maintained by the Darktrace analyst team are mapped to the MITRE Model Breaches
ATT&CK Framework where applicable. This mapping is a valuable tool to understand coverage
and for teams with internal playbooks for how to address each technique. For each model, the The Model Breaches tab displays a graph of breaches for the selected model over the given
MITRE ATT&CK Mapping tab displays the techniques the model covers. timeframe - by default, two weeks are displayed. The time window covered by the graph can
be adjusted in the bottom right and can return up one year of model breach data (where
available). Acknowledged breaches can be displayed or hidden with the “Show Acknowledged
Breaches” toggle.

For each technique, click ” View in MITRE” to open detailed information about the technique
on the MITRE website.

A JSON file of all mappings can be downloaded from any model. This mapping file can be
uploaded to the MITRE ATT&CK navigator to browse the mapped techniques. If you are
unsure how to use this file, refer to the instructions provided in “JSON Usage Instructions external-link”

The graph displays each model breach as a node. A tooltip with the device, breach score and
exact time of breach appears when hovering over a node. The average breach score across
the timeframe is displayed as a red line. Grey, vertical lines indicate a that the model was edited,
and the logic potentially altered.

125
Under the graph is a list of devices that breached the model in the given timeframe, where When the model is edited, devices can be added via the search bar and remove with the
each row corresponds to a specific device. The type of devices breaching the model are also “Remove” button.
summarized in the top left. Each device is identified by the hostname, IP and/or MAC address
where available. On the right, the number of breaches and the time of the last breach are
displayed. Clicking the number of breaches opens a new window or tab with a Breach Log for
each event.

The user-minus ignore device button is located beside the number of breaches - ignoring a device is in
addition to the defeats system. When a device is ignored, it will never trigger a model breach
for the model in question, even if it performs behavior that matches the model criteria in future.
If the icon is greyed-out, the device is already ignored and must be added to or removed from
the device list, depending on mode, to become eligible to create breaches again.

Device List

The device list displays the devices current eligible or ineligible to generate model breaches. A
model can either be applied to all relevant devices - those not already removed by defeats or
model logic conditions - or a select subset of devices.

• In the first mode, ignoring any device will place it on a list of devices ineligible for
breaches. This is an “Exclude” list.

• In the second mode, all devices apart from those explicitly listed will be treated as
ignored. This is an “Include” list.

Only one mode can be selected.

126
CREATING A NEW MODEL

Creating a Custom Model Active

To create a new model, click the “Add” button beside the search bar. Now set whether the model should be active when it is created - only active models can
breach. Toggling a model to inactive allows the user to turn a model off for a time (rather than
Models are sorted into folders to categorize their purpose or by the type of activity they are deleting it and having to recreate it at a later date).
looking for. If a model contained within a folder is open when the “Add” button is clicked, the
new model will be automatically placed within that folder. Models can also be dragged-and- Auto update
dropped into folders using the model list after creation.
This setting determines whether a model will be automatically updated or not when a new
version is available from Darktrace. This is not applicable for custom models.

Basic Information

Model Name

First, select a name for the model. The model name can also be used to control alerts to
external outputs so should be clear and concise.

Description

Adding a description will help other users of the Threat Visualizer understand the purpose of
the model when they observe it in the main Threat Tray. A description is optional but highly
recommended.

127
ADDING COMPONENTS TO A MODEL

Breach Logic At the right of the ‘>’ symbol, enter the number of times the filtered metric should be seen
before the component will trigger. A zero in this field means any number of times. The default
The breach logic is the most important part of the model. The components and filters that component identifies at least one connection in 60 minutes.
make up the breach logic define the activity the model is looking for. Each model has one or
more components - types of activity to detect - which are controlled with filters to limit the The frequency and the time period can be altered to identify activity over a shorter or longer
eligible connections or activity that could trigger a model breach. period. Other metrics can be selected for evaluation - click “Connections” to open a dropdown
of metrics categorized by their type or by the models they are relevant to.
There are two types of model: checklist and weighted. These were discussed in more detail
in Looking at a Model. Simply, the type of model defines the relationship between those
components that is required to produce a model breach:

• Checklist = “All Components Are True”

• Weighted = “A Target Score is Reached”.

Select the type of model before proceeding.

Either select a new metric from the dropdown or proceed with the default “Connections”. The
Building Components relationship between components and metrics is covered in more detail in Components and
Filters.
Components are created from metrics - discrete events or activities that are observed by
the Threat Visualizer. To start building the model, click “+ Add Component” to add the first
component.

Select the Metric the Model should include. The available Metrics are listed in Model Editor
Metrics but may differ depending on your environment and any additional Darktrace modules
and integrations providing data.

128
 ADDING FILTERS

Filters Model Filters

It is not desirable to alert on every connection that occurs, just some interesting connections; Each metric has a list of applicable filters that can be used to limit its scope. For example,
filters therefore limit the number of events that can trigger the component. Some metrics are connection metrics can be filtered by hostname rarity, ports and connection details such as
very precise and do not need qualifying with filters. We will now proceed to add filters to the length and data transfer. SaaS activity, representing discrete events, can be filtered by the
new model. user involved, the SaaS platform, the geographic location of the action, etc.

Filters are combined with comparators and values to create breach conditions.

129
Filter Comparators

Matches / does not match Matches regular expression / does not match regular expression

Attempts to match the string provided against the value in the field. If * is used, performs a Attempts to match a value in the field against a regular expression. Does not support lookups.
simple wildcard match of any length. If ? is used, performs a wildcard match against a single
character. The comparator is case-sensitive but can be made insensitive by surrounding the expression
with forward-slash and appending an ‘i’.
Example Breach Condition
Example Breach Condition
[Connection Hostname] [contains] [*oogle.co.uk]
[Message] [matches regular expression]
Example Match: [(Anomalous|Compromise|Device|Unusual Activity|User|Infrastructure).*]

mail.google.co.uk Example Match:

google.co.uk
Device / New Failed External Connections
Example Breach Condition

[Connection Hostname] [contains] [?oogle.co.uk]

Is longer than / is shorter than
Example Match:
This comparator accepts a number, representing the number of bytes.
google.co.uk
Example Breach Condition

[DNS Hostname Lookup] [is longer than] [0]

Contains / does not contain

Tries to locate the exact string provided anywhere within the filtered field.
Is / Is not
Example Breach Condition
Allows for values to be selected from a list of predefined values. Also includes booleans.
[Connection Hostname] [contains] [`darktrace`]
Example Breach Conditions
Example Match:
[Day of the Week] [is] [Sunday]
darktrace.com [Proxied Connection] [is] [False]
130
Has tag / does not have tag Other Filters

For tagged internal sources or destinations, allows the tag to be selected from a list. Some very specific filters do not have comparators or values. For example, the “Direction” filter
offers the values “Incoming only” and “Outgoing only” instead of defining a comparator. The
Example Breach Conditions “Same IP” and “Unique IPs” filters do not have any comparators or values at all. The majority of
filters behave exactly as described above. Where filters differ, the logic should still be clear.
[Tagged Internal Source] [does not have tag] [Admin]

Numeric Comparators

The following numeric comparators are supported. Depending on the filter, not all comparators
may be available.

• < (Less than)

• <= (Less than or equal to)

• = (Equal to)

• != (Not equal to)

• >= (Greater than or equal to)

• > (Greater than)

Example Breach Conditions

[Rare external IP] [>=] [90]

131
DEFINING MODEL COMPONENT BREACH CONDITIONS

Filter Logic Worked Example

When more than one filter is defined for a component, the Breach Conditions section will
appear - this is where the relationship between filters is defined.

Metric: [External Data Transfer] [>] [100 MB] in [60 Minutes]

Breach conditions connect filters together in logical sequences. Each filter has an alphabetical Filters:
reference which corresponds to a ‘bubble’ in the conditions. When a bubble is clicked on, it
becomes highlighted and is now a required condition for the component to breach. A - [Day of the Week] [is] [Sunday]

Multiple required components should be thought of in an ‘AND’ relationship. B - [Proxied Connection] [is] [False]

C - [Tagged Internal Source] [does not have tag] [Admin]

Breach Conditions: A & B & C

This limits the component to only breach when all filters - A and B and C are satisfied. In this
case, the component would only breach when a non-admin device transfer more than 100mb
externally within an hour on a Sunday without using a proxy.

There is often more than one set of criteria we wish to apply to a component, for example
when an event can be identified differently over UDP or TCP. Components are therefore not
limited to one set of breach conditions - multiple sets can be built in an OR relationship with
one another.

132
Worked Example “Always Required”

Some filters are very restrictive, such as connection direction or restrictions on IPs, and
therefore must be applied across all breach condition lines regardless. These filters have blue
‘bubbles’ and will display “Always Required” in the tooltip on hover.

Adding Display Fields

The final step of defining a component is selecting display fields. Display fields control the at-
a-glance information displayed to the user when a breach is triggered by the component, they
do not impact the logic of the model itself. Display fields should include the most important
information an analyst would need to triage a model breach.

For example, in a connection-based model an analyst would need to know the IP, protocol and
Metric: [External Data Transfer] [>] [100 MB] in [60 Minutes] port involved in the breach event. In a SaaS model, it would be useful to know the resource
(like file or cloud infrastructure element) involved in the activity or the ASN of the source IP to
Filters: identify the geographic location.

A - [Day of the Week] [is] [Sunday] In the component you are working on, expand the Display Fields header and click ‘+ Add Field’.
The default display field for the main component metric will be added. For example, for the
B - [Proxied Connection] [is] [False] “Connections” metric, the default display field is “Connection Hostname”. To choose a different
field, click on the name and a selection of relevant filters will appear in the dropdown.
C - [Tagged Internal Source] [does not have tag] [Admin]

Breach Conditions:

A&B

B&C

Here, the same filters are in use, but component can breach in two different scenarios - either
A and B are satisfied, or B and C are satisfied. In this case, the component would breach when
any device transfers more than 100mb externally within an hour on a Sunday without using a
proxy, OR if a non-admin device transfers more than 100mb externally within an hour on any
day without using a proxy.

At the end of each breach condition, the logic is summarized for review. These conditions can
be chained together to create complex and carefully targeted model components.
133
TUNING MODEL SCORING ADDING ACTIONS TO A MODEL

Score Modulation The purpose of each model action was covered in further detail in Model Actions. A model can
trigger more than one action in response to a breach. Here, it is important to consider the most
Score modulation controls how the model score should change as the model breaches over relevant set of actions for the behavior targeted by the model.
time for a given device. There are four configuration options.
If the model is looking for malicious activity that requires analyst intervention - triggering an
• Decreasing: As a device keeps triggering the same model, the threat score of the alert output is a reasonable response. However, for a model identifying all Office 365 admin
breach will lower over time. users, it is not the most appropriate action to trigger. Instead, an increase in device priority is a
logical response to ensure any potential compromise of an admin account has a suitably high
• Increasing: The more a model fires, the higher the threat score for the device. threat score.

• Stable: The Threat score will remain the same no matter how often a device triggers a The Model action is default for all models. This creates an event in the device’s event log
breach of this model. without creating an alert or model breach in the threat tray.

• Increase then Decrease: Initially the threat score will increase but will reduce over time
if the model keeps firing.

Some activity becomes less anomalous over time. For example, connections to a new internal
server become less concerning as they become part of the ‘pattern of life’.

Contrastingly, some activity becomes more anomalous over time. For example, the more
failed connections a device makes to internal devices in a short space of time, the higher the
likelihood of a malicious network scanning incident.

Other activity remains concerning regardless of frequency. This is particularly true of

compliance issues where an activity is always in contravention of a policy regardless of how
often it occurs.

Finally, some activity is potentially malicious when it happens frequently in quick succession
but can be less concerning if remains frequent over a long period. For example, the scanning
activity above is concerning at first but if repeatedly occurring may indicate a network
configuration error or a DNS issue rather than a malicious incident.

Selecting a score modulation is important for controlling how your new model behaves over
a longer period and ensures the alerts it produces stay relevant and useful to other Threat
Visualizer users.

134
The Generate Model Breach action causes the system to generate a model breach that will Other Actions
appear in the threat tray. Within this action, a priority can be set for the overall model breach:
The other available actions are:
Breach priority
• Alert External Systems: models with alert turned on will be pushed out to external
Assign this model a priority score of 0-5. The model’s priority will affect the strength with systems if conditions for such alerting are met.
which it breaches, so that if particular types of behaviors are of greater interest to you, these
behaviors will register as more strongly relevant and will be more obvious in the threat tray • Antigena: take a Darktrace RESPOND action. See Darktrace RESPOND Models and
than if the priority was lower. Actions for more information.

• 0 System Event • Tag Device: automatically tag the device or user that meets the conditions.

• 1 Low Impact • Assign Priority Score: assign a priority score to this device or user to increase or
decrease the scoring of model breaches associated with it.
• 2 Interesting Behavior
• Device Type: change the device type to one of the preset values (e.g., server, IP phone).
• 3 Medium Impact Only valid for network devices, not users.

• 4 Significant Behavior Select the most appropriate actions for the model purpose and proceed.

• 5 High Impact

135
 TIPS FOR NEW MODEL MAKERS

Defeats List The Darktrace model development team create and maintain the extensive Darktrace model
deck to detect a wide range of potentially malicious indicators, unusual activity and unwanted
The final element to configure before saving the new model is the defeats list. Defeats are network behavior. These experts have provided some top tips and points to consider for new
conditions which prevent the model from breaching but are separated from the model logic. model makers.
How defeats can help tune the models in your environment was covered in Model Defeats.
Top Tips from Darktrace Experts
For new models, there may not be any defeats you wish to add at this time. Once the model
is live, exclusions may become obvious as specific devices trigger false-positive breaches or • Think about the connection direction for the model you are creating. Are you only
you wish to exclude certain subnets from the criteria due to the devices within them. interested in inbound or outbound data transfer?

Tuning a model with defeats keeps it relevant and producing valuable alerts without requiring • When creating a tagging model - a model that adds a tag to a device based on given
changes to the underlying logic. behavior - make sure to add a condition to exclude devices that already have the tag
you want to apply. This will keep your model breaches controlled and relevant.

• Don’t neglect low-level indicators - it can be useful to set your unusual activity
thresholds lower at first and tune them later to catch all the events you are interested in.

• If you are worried that a model may fire too often, check in on it after 15 minutes, then
an hour - are you happy with how often it is breaching? If it seems too busy, increase the
Finalizing the Model minimum seconds between model breaches or increase thresholds in your anomaly
scores.
Once all the above steps are completed - save the model using the save save icon in the top right
of the workspace.

Enter a commit message that describes the purpose of the model creation, or of any changes
made to the model, and click Save once again.

136
CHAPTER 9 - ADMIN INTERFACES

DEVICE & SUBNET ADMIN

DEVICE ADMIN 138
SUBNET ADMIN 139

PERMISSIONS ADMIN
PERMISSIONS ADMIN 140
GROUPS IN PERMISSIONS ADMIN 141

SYSTEM STATUS
THE SYSTEM STATUS PAGE 143
ALERTS ON THE STATUS PAGE 144
SYSTEM TOPOLOGY 145
DEVICE ADMIN

Viewing Device Admin Users can search for Hostname: SEP and press + to add that query, and then add additional
queries to narrow the results down based on any criteria including: Labels, Tags, Device
The device admin is an up-to-date and historical catalog of all devices ever seen on your Priority, Device Types, Hostnames, IPs, Mac Addresses, Vendor (based on OUI of Mac Address),
network. The devices are by default sorted by when they were last seen. The device admin Operating System, First Seen, and Last Seen.
allows for both the bulk application of tags and the ability to change device types. Some
examples of these include adding the tag “Microsoft Windows” to any device that meets To apply tags, simply click “Apply Tag” which will display all available Tags (for more information
certain conditions, or changing all devices with hostnames starting with SEP to IP Phones. on how to create tags, see Adding and Reviewing Tags) as well as a checkbox next to each
device.

To apply the tag to all devices on the page, you can check the top checkbox; otherwise, you
can simply check the checkboxes one by one. To remove tags, you can click the tag you would
like and uncheck the box next to a box that is tagged.

Click the link icon to open the Threat Visualizer centered on the specific device.

Device Admin can be accessed from the Main Menu under Admin.

Filtering and Modifying Devices

The search bar allows users to narrow down the listing of devices and can be used in
conjunction with previous searches.

138
SUBNET ADMIN

Viewing Subnet Admin

Subnet Admin can be accessed from the main menu under Admin.

The subnet admin provides a catalog of the current subnets being modeled on your
environment. Every field is customizable, which allows for enrichment of investigations and
usage of the tool.

Modifying Subnets

• The label of a subnet can be used to provide a nickname to a device, this will show up
throughout Darktrace’s Threat Visualizer. For more information about labelling subnets,
please see Labelling Subnets and Devices or the System Administration guide.

• The network is where a user can change the subnet size, for example from a /24 to a
/25. This may change if DHCP traffic sees a more accurate subnet mask or if there is a
successful TCP connection to the broadcast IP of the subnet.

• The location of the subnet can be changed by providing the latitude and longitude,
altering where the subnet is displayed on the home screen of the Threat Visualizer.

• The DHCP field is used to specify if the Darktrace system should expect to see DHCP.

• Hostname and Credentials control the type of device tracking assigned to that subnet.
Please see Hostname Tracking and Credentials Tracking or the System Administration
guide for more details.

139
PERMISSIONS ADMIN

Permissions Admin is the primary location for managing user permissions and visibility for the Click on a row to expand and show more details about the user.
Darktrace Threat Visualizer, SaaS Console and Darktrace/Email Console. it is accessible from
the main menu of the Threat Visualizer (Admin > Permissions Admin), from the sidebar of the Users are granted permissions directly, or through group membership. The Permissions
SaaS Console (users User Admin or users-cog User Groups), and from Darktrace/Email (users User Admin column shows the effective permissions the user has.
or users-cog User Groups).
• If the user is a member of one or more groups, these are the permissions granted by
group membership.

• If the user is not a member of the group, these are the permissions directly applied to
the user. Permissions can be added and removed from the column view.

The state of flags - simple settings associated with the user - can be modified from the column
view. Users can also be added to and removed from groups. For more complex edits, click
the pen pen icon in the first column. This will open a step-by-step process to edit the users’
permissions, group membership and flags.

Values in the Visibility and Restriction columns (for example, “Topology Restrictions”, “cSensor
By default, the page will open on “My account” which summarizes the settings, group Visibility”) are controlled through group membership. By default, all users will have full visibility
membership, permissions and visibility of the current user. This data is read-only. unless “Manual Data Visibility” is set on the “Groups” tab. For more information, please refer to
Controlling Data Visibility and How Data Visibility is Defined.
Created Accounts
Some users may appear with a warning icon. This indicates the user has been modified by a
Permissions in the Darktrace Threat Visualizer, SaaS Console and Darktrace/Email interfaces higher-permission user and granted permissions the current user does not possess - whether
are handled in a hierarchical structure. The “Created Accounts” tab lets the user review users through group membership or direct grant - and the current user is no longer able to modify it.
they have created (and therefore “own”), or that have been created by users they have created.

140
GROUPS IN PERMISSIONS ADMIN

The “Groups” tab of Permissions admin is used to manage groups of local, LDAP and SSO The data visibility setting chosen (“Manual data visibility” or “Full data visibility”) controls
users. Threat Visualizer users can be added to groups to manage permissions in bulk. Once a whether users are able to see all data, or whether restrictions should be placed at a group
user is added to at least one group, the permissions of that group take precedence. level. The default value is “Full data visibility”. For more information, please refer to Controlling
Data Visibility.

The networks setting chosen (“Include networks” or “Exclude Networks”) is only relevant
if “Manual data visibility” is set above and is applicable to network visibility restrictions only.
“Include Networks” is the default state. In this mode, users will only see data for network
ranges they have been specifically granted access to by group membership. If set to “Exclude
Networks”, users will see all network data except for those ranges specified for groups they
are members of.

Please refer to How Data Visibility is Defined for more information on controlling network
visibility.

Groups

Users will only be shown groups in the “Groups” tab that have equivalent or lower permissions
SAML SSO and LDAP users are part of groups in external AD or IdP environments - information than they possess. Group members will also only be displayed if they are part of the user’s
about these groups are sent as part of the authentication process. The permissions of these hierarchy. LDAP and SSO users are not included in the membership information.
users is controlled by modifying the groups in Darktrace that correspond to those in the AD/
IDP environment. Click on a row to expand and show more details about the group.

The Threat Visualizer also allows data visibility to controlled at a group level. To create manual Groups can grant permissions to their members; the Permissions column shows the
data restrictions, users must be placed in groups. permissions the group grants. Group permissions are additive - if a user is a member of more
than on group, the permissions of all groups are aggregated together.

Visibility Options The permissions assigned to a group can be modified from the column view. Users can also be
added to and removed from the group from this view. For more complex edits, click the pen pen
The “Groups” tab has two additional options which are related to data visibility: “Manual data icon in the first column. This will open a step-by-step process to edit the group permissions,
visibility / Full data visibility” and “Include networks / Exclude Networks”. These settings impact members and visibility.
the visibility of all groups and therefore can only be modified by a Darktrace representative or
the default admin user.

141
Visibility

By default, visibility is set to “Full Data Visibility”. Users and groups are able to see all data
monitored by Darktrace that their permission set allows. Users who are not part of a group are
also able to see all data.

When a deployment is moved from “Full Data Visibility” to “Manual Data Visibility”, the system
applies the effective equivalent of full data visibility to all current groups in the form of visibility
expressions. Users not within a group (excludes default users) will lose data visibility unless
added to a group. New groups will also possess no visibility unless granted during creation.

The visibility granted by each group is displayed in the Visibility and Restriction columns (for
example, “Topology Restrictions”, “cSensor Visibility”).

For more information on controlling data visibility, please refer to Controlling Data Visibility and
How Data Visibility is Defined.

142
THE SYSTEM STATUS PAGE

The System Status page contains detailed information about the health and scope of your System Alerts
Darktrace deployment. Here, metrics on hardware utilization, throughput, software bundle
versions, component health, and modeled devices can be monitored. System alerts keep operators informed of the health of the Darktrace instance and any
changes in modeling, data or the health of connected integrations and modules.
It is important to ensure every part of your deployment is running successfully and within
specification, particularly when a deployment is new, or the scope has been increased When changes or errors occur, a “System Alerts” notification will also appear in the bottom
significantly. Unhealthy deployments, such as those which are overloaded, observing far too right of the Threat Visualizer workspace, above the Threat Tray. This notification will open the
many connections for their specification or with unreachable probes or components, will not System Alerts tab directly.
experience the full benefits of network visibility and consistent monitoring.

In the Threat Visualizer interface, the Status page is accessible from the main menu under
Admin > System Status.

From the SaaS Console interface, the Status page is available from the sidebar (tachometer-fast “System
Status”).

143
ALERTS ON THE STATUS PAGE

System alerts are notifications about changes to the scope or health of the overall Darktrace Notifications of the same kind or on the same instance are grouped together - to expand
deployment. For example, system alerts inform operators when new subnets are detected, nested alerts, click the instance or alert name. For nested alerts, the highest severity level of
when a probe or component loses traffic or becomes unreachable, or when a SaaS Module is all nested alerts will be shown by the exclamation-circle icon color .
experiencing issues.
The details section contains information about the event such as the subnet detected, the
Historic system alerts were created from model breaches from the System model folder; error experienced by the component or the time that packet loss was detected. Where relevant,
previously these models would appear in the Threat Tray and generate repeated alerts whilst details will also include further investigation or remediation steps. Each event includes a link to
active. Threat Visualizer v5.1 introduces smart, high fidelity alerting with NOC-level capabilities. the Customer Portal to raise a support ticket if further assistance is needed.
Alerts will maintain an “active” state whilst relevant, becoming “resolved” once the issue is
rectified.

These new system status alerts are available for issuing to external systems - alerts will only
be issued when a system event becomes active or resolved. Each alert will also maintain a
consistent unique identifier, allowing recurring issues to be identified.

Active Alerts

The Active Alerts tab contains current system alerts that are occurring on the Darktrace
instance or any child instances and probes associated with it. Alerts are categorized into
severity levels - low, medium, high and critical - and can be filtered by severity or by creation
time. The level is indicated by the color of the left-hand bar and the exclamation-circle alert icon.

Active alerts can be acknowledged to hide them whilst they remain active, or suppressed for a
specific duration. Both actions can be performed for the current user, or for all users. Alerts in
this state are still viewable by enabling the Show Acknowledged/Suppressed toggle and can
be unacknowledged or unsuppressed at any time.

144
 SYSTEM TOPOLOGY

Resolved Alerts Deployment Health

The Resolved Alerts tab contains system alerts that have been resolved, such as where a SaaS This tab displays an overview of all masters, hardware probes and virtual probes connected to
module is no longer experiencing errors, where a drop in traffic has been corrected, or an the deployment. There are two views - project-diagram topology view and list list view - which can be toggled
informational subnet alert has reached expiry. Alerts on this page can be dismissed for the in the top left of the workspace. By default, the workspace will open in topology view unless
current user or for all users, removing the resolved alert permanently. there are a large number of probes and master instances associated with the deployment.

Topology View

The master appliance accessed is always displayed at the head on the left with any subordinate
masters or probes to the right. Where an instance such as a sub master has multiple probes,
these can be hidden minus-circle or expanded again plus-circle with the relevant icon.

If a resolved system event recurs, it will become active again.

Legacy Alerts

Legacy system model breaches can still be reviewed on the Legacy Alerts tab.

145
The color of the instance label represents the overall health. For example, a vSensor with a Health Metrics
green label is operating well within its scope, and a master with a red label may be overloaded
on one or more key metrics. Hovering over the label will provide more information. In either view, clicking the name of a master instance will open a “System Status” overview with
detailed graphs covering deployment health. For probes, a simple deployment overview is
Please note, this view may not be available in deployments with a substantial number of displayed. The instance identifier, the IP and the type of instance are displayed in the top left.
instances. Below this, the time the information was retrieved at is shown.

List View

Each graph can show 1, 7 or 30 days to identify trends or a specific date/time where something
changed significantly. Hovering over a point on the graph will give details on the specific
values at that time.

• The Summary tab contains graphs for all key metrics and details of the current Threat
Visualizer and Model Bundle versions.

• The Hardware tab covers disk utilization with greater granularity alongside other key
metrics.
In list view, instance health is shown by the colored line on the left of each row. Current
utilization of key metrics - CPU, Load, Memory, Disk and Darkflow Queue - are displayed on the • The Network Traffic tab includes last seen dates for major protocols, greater detail on
right. Where an instance such as a sub master has multiple probes, these can be hidden minus-circle or modeled devices, processed bandwidth and network interface load.
expanded again plus-circle with the relevant icon.

146
• The Advanced tab contains deployment version information, license expiry, and details
of internal domains and servers observed by the appliance.

• The Probes tab lists all virtual and hardware probes associated with the instance under
review.

• The SaaS tab lists the current status of Darktrace/Apps, Darktrace/Cloud and
Darktrace/Zero Trust Modules.

• The Subnets tab lists all subnets currently modeled and their overall tracking quality.
Where DHCP warnings are displayed, a link to Subnet Admin is provided to modify the
tracking settings.

147
CHAPTER 10 - DARKTRACE RESPOND

UNIVERSAL DARKTRACE RESPOND ELEMENTS

WHAT IS DARKTRACE RESPOND? 149
REVIEWING DARKTRACE RESPOND ACTIONS 151
UNDERSTANDING THE DARKTRACE ANTIGENA ACTIONS PAGE 152
DARKTRACE RESPOND MODELS AND ACTIONS 154
DARKTRACE RESPOND DEPLOYMENT MODES 156

DARKTRACE RESPOND FOR THIRD-PARTY PLATFORMS

ENABLING DARKTRACE RESPOND FOR DARKTRACE/APPS, DARKTRACE/ZERO
TRUST AND DARKTRACE/CLOUD 159
MAKING USERS IMMUNE TO DARKTRACE RESPOND SAAS ACTIONS 163

DARKTRACE RESPOND/NETWORK
DARKTRACE RESPOND/NETWORK MODELS 164
DARKTRACE RESPOND/NETWORK TAGS 165
DARKTRACE RESPOND/NETWORK INHIBITORS 167
WORKFLOW FOR REVIEWING DARKTRACE RESPOND ACTIONS 168
DARKTRACE RESPOND/NETWORK DEPLOYMENT SCENARIOS 169
DARKTRACE RESPOND/NETWORK AND SERVER DEVICES 171
WHAT IS DARKTRACE RESPOND?

Darktrace RESPOND Framework

The Darktrace RESPOND framework leverages the power of the ‘pattern of life’ developed Darktrace RESPOND/Network
across the platform to respond, contain and neutralize emerging threats across the entire
digital estate. With its unique understanding of “normal” for each user, device, and component, Formerly Antigena Network
each autonomous action is targeted and proportionate - disruption to user workflow is minimal.
The Darktrace RESPOND/Network component applies Darktrace RESPOND capabilities
Darktrace RESPOND is available across multiple coverage areas including Network, Email, to physical and cloud network devices by controlling connectivity. This control ranges from
Endpoint, Zero Trust and SaaS, extending autonomous response across the enterprise. Where interrupting communications between distinct endpoint/port combinations up to complete
Darktrace DETECT provides the ‘pattern of life’ to intelligently identify threats, the Darktrace quarantine - actions are proportional to threat and may be escalated if granular blocks are not
RESPOND framework places the tools in your hands to action and remediate those threats - sufficient. Response can be performed through integration with a number of popular firewalls
autonomously, or with human oversight. or by Darktrace virtual sensors such as vSensors and osSensors (both agent and dockerized),
ensuring it extends to the farthest reaches of the cloud environment.
Each component offers a combination of autonomous, semi-autonomous, manual and
triggered actions. The Darktrace RESPOND framework works with models – when a model Darktrace RESPOND/Apps
breach occurs, the system can be configured to take a range of automatic actions in response
or recommend actions for human confirmation or later review. A range of options exist within Darktrace RESPOND/Apps extends autonomous response to enterprise software
the platform to configure the operation of Darktrace RESPOND and tailor it to individual environments. Where anomalous behavior in a third-party SaaS platform begins to escalate,
requirements. Darktrace RESPOND/Apps can step in and utilize access policies and administrative tools to
control the account and sever the malicious actor’s access. Eligible modules and the range of
SaaS actions available are continually expanded over future software updates.
149
Darktrace RESPOND/Zero Trust Advanced Integrations

Darktrace RESPOND/Zero Trust offers two approaches to securing Zero Trust environments Darktrace RESPOND/Cloud for AWS Lambda (Custom)
with Darktrace autonomous response; per-user SaaS actions at the ID-provider level and
connection (traffic) actions for Zero Trust VPN solutions. By integrating with Zero Trust Where Darktrace RESPOND/Network and Darktrace RESPOND/Apps offer carefully curated
solutions including Okta, Duo and Zscaler, Darktrace can ensure machine-speed response inhibitors selected by Darktrace, Darktrace RESPOND/Cloud for AWS Lambda (Custom)
at the critical pivot-point of many digital businesses. Eligible modules and the range of SaaS instead opens the RESPOND framework to allow the creation of custom actions through
actions available are continually expanded over future software updates. invoked AWS Lambda functions. Through this powerful, flexible tool, Darktrace anomaly
detection can be used to drive any action and response desired.
Darktrace DETECT & RESPOND/Email (Darktrace/Email)

Formerly Antigena Email

Darktrace/Email represents a powerful expansion of Darktrace DETECT and RESPOND

autonomous, responsive capabilities into the email domain. Complex patterns of life for
individual senders, recipients, groups and correspondents are developed and used to detect
even the subtlest threats entering via the inbox. The Darktrace/Email component is available
for Gmail, Microsoft 365, Hybrid and On-Premises Microsoft Exchange environments. It can
be deployed standalone, with one or more Darktrace/Apps modules or integrated with an
existing Darktrace DETECT deployment.

A fully comprehensive user guide for the Darktrace/Email system is made available separately.

Darktrace DETECT & RESPOND/Endpoint (Darktrace/Endpoint)

Formerly Darktrace for Endpoint and Antigena Endpoint

Darktrace RESPOND/Endpoint brings award-winning autonomous response capability to

the endpoint, enabling AI to take targeted, autonomous actions through Darktrace cSensor
agents. Darktrace RESPOND can control network traffic to restrict anomalous connectivity
at the system-level, even on remote devices. Devices monitored by cSensors are eligible for
Darktrace RESPOND/Endpoint actions if they are licensed, in a Darktrace RESPOND/Endpoint-
enabled group (5.2+), and possess one or more of the Darktrace RESPOND tags.

As Darktrace RESPOND/Endpoint takes action at the network level on remote endpoint devices,
it shares many detection frameworks, inhibitors, settings and configuration processes with
Darktrace RESPOND/Network.

150
REVIEWING DARKTRACE RESPOND ACTIONS

The Antigena (Darktrace RESPOND) Actions Page Overview

The Antigena (Darktrace RESPOND) Actions window lists all current and expired Darktrace Actions on the Network and SaaS tabs are split into pending, active, cleared and expired.
RESPOND Actions. Actions from Darktrace RESPOND components such as Darktrace Active is the default view.
RESPOND/Network, Darktrace RESPOND/Apps and Darktrace RESPOND/Endpoint will appear
in this window. Darktrace RESPOND/Network (including firewall integrations) and Darktrace Pending Actions
RESPOND/Endpoint devices appear under the “Network” tab as they impact network devices.
Actions against users or entities in third-party platforms will appear under the “SaaS” tab. Indicates Darktrace RESPOND Actions that have not yet been approved by a human operator.

The types of action shown will differ depending on where the Antigena (Darktrace RESPOND) When there are pending Darktrace RESPOND actions, a notification will appear above the
Actions page was accessed from and which Darktrace RESPOND components are enabled in threat tray in the Threat Visualizer. A notification will also appear in the SaaS console threat tray
the environment. for pending SaaS actions only.

Please note, Darktrace DETECT & RESPOND/Email is displayed separately in the dedicated Active Actions
Darktrace/Email interface.
Displays current Darktrace RESPOND Actions which are in place and have not yet expired.
Threat Visualizer
All currently active actions can be cleared at once using the “minus-circle Clear Active Actions” button
In the Threat Visualizer interface, Darktrace RESPOND Actions are accessible from the main in the top right.
menu (Antigena Actions) or filtered on a specific device from the a Antigena Actions icon in
the Omnisearch bar. Cleared Actions

A new window will open on the dashboard. Lists all Darktrace RESPOND actions that were manually cleared by an operator. Clear will inform
Darktrace RESPOND to stop controlling the device or user and suppress the combination of
SaaS Console Darktrace RESPOND Action and model breach conditions for the time period that the clear
action was performed for.
From the SaaS Console interface, Antigena (Darktrace RESPOND) Actions is available from the
sidebar (“a Antigena Actions icon”). In this interface, only SaaS actions will be visible. Expired Actions

The Antigena (Darktrace RESPOND) Actions page will open in the main workspace. Includes all previous Darktrace RESPOND activity for devices and users in your environment.
Actions can be reactivated and manually extended if desired.

151
UNDERSTANDING THE ANTIGENA (DARKTRACE RESPOND) ACTIONS PAGE

Filtering the Actions Page Reviewing a Single Action

Filtering can be done by action type, by device, by model, or by status.

Each tab can be filtered with a free text search against the model that triggered the Darktrace
RESPOND action, or the device or user impacted by the Darktrace RESPOND action. This filter
is applied across all action states (active, cleared, etc.)

Filter Panel

Click the filter filter icon on the left to open the filter panel.
From left to right, each entry on the Antigena Actions page contains the following:
For Network actions, expired actions can be filtered by their expiry time using the time
selectors. By default, currently active actions, or those with an expiry in the last 7 days, are • A device or user under Darktrace RESPOND control
returned.
• A summary of the action taking place
Actions can also be filtered by the exact action Darktrace RESPOND applied, for example,
“Block Outgoing Connections” or “Disable User”. By default, all actions are returned. • The start and expiration time of the action.

SaaS actions can be further filtered by whether the action was successfully applied in the • The action status.
third-party platform. Where “Applied” : “Yes”, this means Darktrace RESPOND successfully
performed the action - such as a forced logout or an IP block. If the status is “No”, the Current • The model that triggered the action, if applicable.
Status column will give more information about why it was not possible to apply the action.
Actions may be prevented for many reasons, such as insufficient permissions for the module • Controls to extend, activate, reactive or clear the action.
or because the user is marked as immune at the configuration level. Setting the “Applied” filter
to “Yes” will only display actions where Darktrace RESPOND successfully actioned the user. Device

For Darktrace RESPOND/Network actions (not applicable for firewall integrations or Darktrace In the Threat Visualizer, hovering over the name of the device or user will show a summary.
RESPOND/Endpoint), the “blocked” status of the action can be optionally displayed. “Blocked” :
“Yes”, indicates Darktrace RESPOND/Network blocked one or more connections that matched
the criteria. Blocked can refer to the original connection that triggered the action if still
active when Darktrace RESPOND responded, or it can refer to subsequent connections that
matched the criteria for blocking. In some cases, Darktrace RESPOND/Network could identify
a suspicious connection, block any future connections, but no subsequent connections
actually occur - here, “Blocked” would be “No”.

152
 Where Darktrace RESPOND performs a one-off, discrete action such as revoking all current
logins on a platform, the action will be repeated for the duration of the action. The interval at
which it is repeated is defined in the configuration settings.

Action Status (SaaS/Platform-type actions only)

The status represents whether the action could be successfully applied in the third-party
platform and its last known state.

Clicking the name will center the visualizer on the device. Clicking the name of a user from the Model
SaaS Console will open their profile.
In the Threat Visualizer, clicking the name of the model that triggered the breach will open
Action Summary a Breach log for the model. In the SaaS Console, clicking the model will open the breach
investigation overlay centered on the model breach.
The summary states the type of action and the conditions, such as the IP or port involved. For
example, blocking outgoing connections to a specific external IP on port 443, invoking a block If the action was triggered manually, the user who triggered it will be reported here.
through a firewall or blocking a user from logging in from a specific IP.
Extend, Activate, Reactivate, Clear
In the Threat Visualizer, clicking on the action summary for Darktrace RESPOND/Network
actions will open an event log of blocked connections. These buttons allow an operator to change the state of current actions. Extending an action
causes the block to last longer. Activate starts a pending action and Reactivate restores an
expired one. To end the block, click the Clear button. Clear will inform Darktrace RESPOND to
stop controlling the device and suppress the combination of Darktrace RESPOND Action and
Breach Condition for 24hrs.

These states were also covered in Reviewing Darktrace RESPOND Actions.

Duration (Start/End)

The default action duration is set in the model that triggered the action. For manual SaaS
actions, the duration can also be set when performing a manual action. Actions can be
extended for the desired length of time with the Extend button.
153
DARKTRACE RESPOND MODELS AND ACTIONS

Darktrace models are a series of logical statements and conditions which, if met, trigger an Darktrace RESPOND in the Model Editor
alert or action; models are primarily used to identify and alert on anomalous and potentially
malicious behavior. The models framework leverages both the underlying ‘pattern of life’ Models can take a series of actions in response to breaching such as triggering an alert, raising
detection and outputs from Darktrace Deep Packet Inspection, telemetry inputs, Darktrace/ the priority of a device or adding a tag. When Darktrace RESPOND is enabled on a deployment,
Apps, Darktrace/Cloud and Darktrace/Zero Trust modules. the additional Antigena action becomes available. This Antigena action is already used by
the Darktrace RESPOND models described above but can also be added directly to custom
Darktrace RESPOND takes action by monitoring model breaches and connectivity for models.
indications of potentially malicious activity or significant anomalies that deviate from the
‘pattern of life’. When Darktrace RESPOND components (excludes Darktrace/Email) are Darktrace RESPOND responses are described as
enabled in your environment, the models used by Darktrace RESPOND (Antigena) will become ‘inhibitors’ as they inhibit anomalous behavior. Full
visible in the Model Editor. details of the inhibitors available are included in
the documentation for each Darktrace RESPOND
Darktrace RESPOND (Antigena) Models component.

Some Darktrace RESPOND models are what are known as meta-models - models which use Open a model with Darktrace RESPOND capabilities
other models breaching as part of their logic. For example, the model “Antigena Large Data or add the ‘Antigena’ action to an existing model to
Volume Outbound Block” (Antigena > Network > Insider Threat) looks for model breaches review the following settings. Some settings may not
with a score over 20% that refer to large outbound data transfers. When one of these be visible if the Darktrace RESPOND component is not
models breaches - such as the “Anomalous Connection / Data Sent to Rare Domain” model present in your environment.
- Darktrace RESPOND/Network will observe the breach, trigger the “Antigena Large Data
Volume Outbound Block” model and take an automatic action against the device transferring Network Inhibitors
the data.
This dropdown selects the response that Darktrace
Other Darktrace RESPOND models take action directly in response to specific criteria. For RESPOND/Network or Darktrace RESPOND/Endpoint
example, the model “Antigena FTP Block” (Antigena > Network > Compliance) looks for should take if this model breaches and the Darktrace
outbound FTP transfers over 1 MB. If a device is observed making these insecure transfers, RESPOND Threshold value is met.
Darktrace RESPOND/Network will block matching connections for 1 hour.
Full details of Darktrace RESPOND/Network inhibitors
If the “Generate Model Breach” action is set on a Darktrace RESPOND (Antigena) model then, are available in Darktrace RESPOND/Network Inhibitors.
like a standard model, it will create model breaches that can be seen in the Threat Tray of the
Threat Visualizer or the SaaS Console. SaaS Inhibitors

Sets one or more responses that Darktrace RESPOND

should take in third-party platforms if this model
breaches and the Darktrace RESPOND Threshold
value is met. Multiple dropdowns can be added.

154
SaaS inhibitors cover Darktrace RESPOND/Apps, Darktrace RESPOND/Zero Trust and
Darktrace RESPOND/Cloud modules. As each SaaS and enterprise platform is different; the
same capabilities may not be available from one platform to the next. To ensure an action
is taken on every applicable platform, more than one can be specified. Once selected, the
inhibitor will display the platforms it is applicable to.

Full details of Darktrace RESPOND inhibitors for third-party platforms are available in Darktrace
RESPOND Inhibitors for Third-Party SaaS Platforms.

Automatic Antigena

This setting controls whether the model can take autonomous actions.

If the model breaches when the Antigena Schedule (See Darktrace RESPOND Deployment
Modes) is in the “Use Model Setting” state and “Take autonomous action” is selected, an action
will be taken. If “Force human confirmation” is chosen, or the Antigena (Darktrace RESPOND)
Schedule is in the “Require Confirmation” state, human approval will be required for the action
to proceed. The final option - “Force autonomous action” - will override the global schedule
and always take action without confirmation.

Antigena Threshold

This field sets the model breach score that must be achieved to trigger the action.

Antigena Duration

This setting specifies how long in seconds the action should last for. The default is 3600 (1
hour).

155
DARKTRACE RESPOND DEPLOYMENT MODES

Deployment Modes Configuration is set on one, shared master layout. The schedule replaces ‘Always Require
Confirmation’, previously set on the System Config page.
Please note, the following does not apply to Darktrace DETECT & RESPOND/Email.

Darktrace RESPOND components be deployed in two distinct ways; Human Confirmation

Mode and Active Mode. In Human Confirmation Mode, Darktrace RESPOND will request
approval from a human operator before taking any action. In Active Mode, autonomous actions
are taken without human intervention. For many organizations, the end goal of a Darktrace
RESPOND deployment is some level of Active Mode, whether applied to select models, select
times of the day, or across all devices and use cases.

Exceptions

• Manually created actions, such as Darktrace RESPOND/Apps actions, are not subject
to the schedule as they have been deliberately taken by a human operator. These
actions will not require confirmation and will occur even during periods of ‘Antigena
Actions Disabled’.

• Actions reactivated or extended manually will also not be subject to the schedule as
they have been deliberately taken by a human operator.
Darktrace RESPOND actions can be configured to fit a weekly/hourly schedule. Human
Confirmation Mode can be activated during business hours and deactivated when personnel • Models which use the Automatic Darktrace RESPOND option “Force autonomous
are no longer in the office, ensuring autonomous actions can be taken when an operator is action” will override the global schedule and always take action without confirmation.
not available to approve them. Response mode can be tailored by hour and day so weekend
periods are protected. Similarly, Darktrace RESPOND actions can be disabled entirely during • Actions created by Darktrace RESPOND-enabled endpoints on the Watched Domains
business hours if desired. will be automatically taken regardless of mode or device tags.

The Antigena Actions weekly schedule is located on the Antigena Actions page in the
Settings tab. The grid represents seven days, comprised of 24 hours. Each block defines
when Darktrace RESPOND will seek operator approval for actions, when it will take them
automatically (unless the individual model indicates otherwise) and when it will take no action
at all. There are three settings: exclamation-triangle Use Model Setting, user Require Confirmation and Antigena
Actions Disabled.

156
Human Confirmation Mode Per-Model

On initial deployment, it is recommended that Darktrace RESPOND be configured in Human Human Confirmation can be configured on a model-by-model basis, where Darktrace
Confirmation Mode. In this mode, Darktrace RESPOND will recommend actions but will not RESPOND takes some actions autonomously but seeks operator confirmation for specific
perform them unless a human operator gives confirmation. Reviewing the actions Darktrace cases. Models intended for human oversight must be modified in the Model Editor to ensure
RESPOND recommends in Human Confirmation Mode will build familiarity and confidence confirmation will be requested.
in the kind of autonomous responses Darktrace RESPOND will take and when they are
appropriate. Actions may be ‘activated’ in the Antigena Actions page in the Darktrace Threat To enable Human Confirmation Mode on select models, access the model editor and locate
Visualizer or the SaaS Console, and on the Darktrace RESPOND (Antigena) tab in the Darktrace the models you wish to edit. Click on the left of the model name in the list to select it, or select
mobile app. all desired models within a folder. At the top of the list, click the ‘# Selected’ dropdown and
choose Automatic Antigena > Force human confirmation. This will place all selected models
Human Confirmation mode can be deployed in two different ways. into confirmation mode.

Global After editing this setting for all required models, navigate to the Antigena Actions page. In the
Settings tab, add periods of ‘Use Model Setting’ mode to the Antigena weekly schedule. Click
In this mode, Darktrace RESPOND will require an operator to confirm before taking any actions, in one of the hourly blocks and select the Use Model Setting option. Repeat for all desired
regardless of whether the individual model breaching has autonomous actions enabled. hours. Alternatively select the Model Setting preset from the dropdown or click the icon
beside each day to fill all boxes with the setting, then refine as desired.
To enable global Human Confirmation Mode, navigate to the Antigena Actions page. In
the Settings tab, add periods of Require Human Confirmation to the Antigena (Darktrace If you wish Darktrace RESPOND to be disabled outside of these hours, select Antigena
RESPOND) weekly schedule. Click in one of the hourly blocks and select Human Confirmation. Actions Disabled for these time periods. If Darktrace RESPOND is in passive mode, grid
Repeat for all desired hours. Alternatively, select the Require Confirmation preset from the settings will have no impact on Darktrace RESPOND behavior.
dropdown or click the icon beside each day to fill all boxes with the setting, then refine as
desired.

If you wish Darktrace RESPOND to be disabled outside of these hours, select Antigena
Actions Disabled for these time periods. If Darktrace RESPOND is in passive mode, grid
settings will have no impact on Darktrace RESPOND behavior.

157
Active Mode Per-Model

When you are happy with the actions that Darktrace RESPOND recommends, enabling Active For each model you wish to remain in Human Confirmation Mode, open the Model Editor and
Mode for at least a select number of models should be considered. Darktrace RESPOND ensure that Darktrace RESPOND actions are set to “Force human confirmation”. Repeat this
deployments are fully customizable; a combination of Human Confirmation mode and Active for each model intended for Human Confirmation Mode. Additionally, check that no models
mode responses can be implemented with fully autonomous response slowly expanded as intended for Active Mode have “Force human confirmation” selected; the correct setting is
the relevant Darktrace RESPOND component is tuned to the environment. “Take autonomous action” to be in active mode.

The default setting for new deployments is all hourly blocks in active mode. Navigate to the Antigena Actions page. In the Settings tab, add periods of ‘Use Model
Setting’ mode to the Antigena weekly schedule. Click in one of the hourly blocks and select
Global ‘Use Model Setting’. Repeat for all desired hours. Alternatively select the Require Confirmation
preset from the dropdown or click the icon beside each day to fill all boxes with the setting,
To enable global Active Mode, navigate to the Antigena Actions page. In the Settings tab, add then refine as desired.
periods of ‘Use Model Setting’ mode to the Antigena weekly schedule. Click in one of the
hourly blocks and select ‘Use Model Setting’. Repeat for all desired hours. Alternatively select If you wish Darktrace RESPOND to be disabled outside of these hours, select ‘Antigena
the Model Setting preset from the dropdown or click the icon beside each day to fill all boxes Actions Disabled’ for these time periods. If Darktrace RESPOND is in passive mode, grid
with the setting, then refine as desired. settings will have no impact on Darktrace RESPOND behavior.

If one or more models are set to “Force human confirmation”, Darktrace RESPOND will still ask
for confirmation before taking the action. These models must be set to “Take autonomous
action” to be in active mode.

If you wish Darktrace RESPOND to be disabled outside of these hours, select ‘Antigena
Actions Disabled’ for these time periods. If Darktrace RESPOND is in passive mode, grid
settings will have no impact on Darktrace RESPOND behavior.

158
ENABLING DARKTRACE RESPOND For Darktrace/Apps, Darktrace/Zero Trust and Darktrace/Cloud

Darktrace RESPOND can take a range of proactive, measured, automated actions in the face Enable RESPOND capabilities for a Darktrace/Apps or Darktrace/
of confirmed cyber-threats detected in real time. Where anomalous behavior in a third-party Zero Trust module
SaaS platform begins to escalate, Darktrace/Apps, Darktrace/Cloud and Darktrace/Zero Trust
modules can step in and utilize access policies and administrative tools to control the account The following steps are required to enable Darktrace RESPOND actions in Darktrace/Apps or
and sever the malicious actor’s access. Darktrace/Zero Trust modules:

In contrast to network actions - taken against connectivity between endpoint, cloud 1. Ensure that a Darktrace RESPOND license has been added to your Threat Visualizer
and network devices - Darktrace RESPOND SaaS actions are those taken in third-party environment for the relevant module.
environments, primarily against user accounts. The suite of actions differs between each SaaS,
Zero Trust and Cloud platform - full details are available in Darktrace RESPOND Inhibitors for 2. Check the level of permissions granted to the Darktrace/Apps or Darktrace/Zero Trust
Third-Party SaaS Platforms. module that has been licensed for actions.

Platform-based autonomous response is currently available for the following modules: To do so, navigate to the System Config page and select the appropriate module. On
the “settings” tab, for each account, check the state of the “Account Permissions” field
• Darktrace RESPOND/Apps for Microsoft 365 (see below). This will show “Monitoring” (DETECT) or “Antigena” (RESPOND).

• Darktrace RESPOND/Apps for Zoom To progress, the account must display “Antigena” in this field. The permissions level
is granted when the app is authorized. Modules authorized before Darktrace v5 or
• Darktrace RESPOND/Apps for Google Workspace authorized solely for monitoring may require reauthorization to begin taking actions.

• Darktrace RESPOND/Zero Trust for Okta If you are not sure if reauthorization is necessary, consult the Darktrace RESPOND
section of the documentation for the module. More information is also available below
• Darktrace RESPOND/Zero Trust for Duo in “Account Permissions”.

This provision will be continually expanded over future software updates. 3. Optionally configure immunity from actions for certain users and IP addresses. more
information can be found in Making Users Immune to Darktrace RESPOND SaaS
actions.

4. Finally, Darktrace recommends that new users of Darktrace RESPOND enable

autonomous actions at a later date, when they are more comfortable with Darktrace
RESPOND functionality.

For this reason, we recommend navigating to the Antigena Actions page and
configuring the Schedule. See Darktrace RESPOND Deployment Modes for more
information.

159
 MANUAL RESPOND ACTIONS

Account Permissions Darktrace RESPOND SaaS actions for supported Darktrace/Apps, Darktrace/Cloud and
Darktrace/Zero Trust modules can be manually performed on a user from the SaaS console
Darktrace/Apps or Darktrace/Zero Trust modules can be authorized for monitoring (DETECT), or the Threat Visualizer.
or for monitoring and Darktrace RESPOND actions. For some modules, Darktrace RESPOND
capabilities require more permissions than initially granted for DETECT coverage in order to SaaS Console
take these actions.
To perform an action on a user from the SaaS Console, navigate to their Profile page from the
The type of authorization is listed for each account in the “Account Permissions” field. main menu, the omnisearch or from an event clickthrough. In the top right, the a Antigena
button should be available. Click on this button to open the manual action dialog.
Where the module needs to be reauthorized to add Darktrace RESPOND permissions, the
reauthorization process will include additional prompts for Darktrace RESPOND permissions Users currently being actioned by Darktrace RESPOND have a green bar beside their profile
or provide alternative authorization links. tile. More information can be found in User Profiles as part of the SaaS console guide.

Modules operating with monitoring (DETECT) permissions may need to be reauthorized with Threat Visualizer
Darktrace RESPOND permissions before actions can be taken.
To perform an action on a user from the Threat Visualizer, search for the user in the omnisearch
Whether this is applicable for a module will be described in the detailed documentation for bar and select them. From the device options in the omnisearch bar, click the a Darktrace
each module. RESPOND icon. The Antigena Actions page will open focused on the user. In the top right, click
the a Trigger Action button to open the manual action dialog.

160
Triggering an Action

There are three settings that must be set at a minimum - the module intended to take the
action, the desired action and the duration for that action.

The Actions available to take will differ between different third-party platforms - a list is available
in Darktrace RESPOND SaaS Inhibitors. The Duration is the initial time the action should be
applied for - one off actions will be repeated for the length of the duration.

• If the user has been seen on multiple platforms

where Darktrace RESPOND actions can be
taken, the Module field can be used to search
for the SaaS module intended to take the action.

• If the user has been seen on only one platform

where Darktrace RESPOND actions can be
taken, the Module field will be pre-populated
with the Darktrace/Apps, Darktrace/Cloud and
Darktrace/Zero Trust module that can take an
action.

• If the user has not been seen on a platform

where Darktrace RESPOND actions can be
taken, the button will not appear and manual
actions cannot be performed.

Some actions may have additional fields, such as

defining an IP to be blocked, which are also required.
Complete any additional fields, then click Apply to
trigger the action.

161
DARKTRACE RESPOND INHIBITORS FOR 3RD-PARTY SAAS PLATFORMS

Models can take a series of actions in response to breaching such as triggering an alert, raising SaaS Inhibitors
the priority of a device or adding a tag. When Darktrace RESPOND is enabled on a deployment,
the additional Antigena (Darktrace RESPOND) action becomes available.

INHIBITOR APPLICABLE MODULES DESCRIPTION

If a Darktrace/Apps, Darktrace/Zero Trust or Darktrace/Cloud module with RESPOND
capabilities is enabled within your Darktrace environment, it comes with a category of Block IP(s) Microsoft 365 Prevents access to the account from an IP or IP
Darktrace RESPOND models already using the Antigena (Darktrace RESPOND) action to range for the duration set.
perform responses. Disable User Microsoft 365, Zoom, Disables a user account for the duration set.
Okta, Duo, Google
This action allows an operator to set one or more ‘inhibitors’ - actions to inhibit the behavior Workspace
that matches the model criteria. Darktrace RESPOND SaaS actions are those taken in third- Force Logout Microsoft 365, Zoom, Forces the user to log out from the platform. This
party environments, primarily against user accounts. The suite of actions differs between each Google Workspace action is a one-off action, so will be repeated at
SaaS, Zero Trust and Cloud platform - models can therefore have multiple inhibitors set to the configured interval for the duration set. The
ensure they can take an action in every possible environment. default interval is 15 seconds and can be altered
by a member of Darktrace support if required.
Darktrace RESPOND SaaS inhibitors can also be triggered manually. For each module, any considerations for Darktrace RESPOND actions are covered in more
detail in the module documentation:
Users and IP addresses can be made ‘immune’ from specific inhibitors or from all inhibitors on
a per-module basis. By default, all users known to a module licensed for Darktrace RESPOND • Darktrace RESPOND/Apps for Microsoft 365
are eligible for actions. Immunity from actions is controlled on the System Config page.
• Darktrace RESPOND/Apps for Zoom
Please see Making Users Immune to Darktrace RESPOND SaaS actions for more detail.
• Darktrace RESPOND/Apps for Google Workspace

• Darktrace RESPOND/Zero Trust for Okta

162
MAKING USERS IMMUNE TO DARKTRACE RESPOND SAAS ACTIONS

All users are eligible for Darktrace RESPOND actions by default if the Darktrace/Apps, Example Configuration
Darktrace/Cloud or Darktrace/Zero Trust module they were observed by has licensed
RESPOND capabilities. Immunity from actions is controlled on the System Config page. Immunity and Account Permissions are set for each account within a Darktrace/Apps,
Darktrace/Cloud or Darktrace/Zero Trust module.
To make changes, access the System Config page from the main menu and select Modules
from the left-hand side. Under Cloud and SaaS Security, select the module you wish to change For example, an organization may have two Office 365 tenancies - Business and Development.
and click on it to open the configuration window. For the Darktrace/Apps Microsoft 365 module, they have two accounts which correspond to
these two tenancies. These accounts have the Account Permissions level of Monitoring.
Action Eligibility
For actions to be taken in both tenancies, both of these accounts need to be reauthorized
When a module has Account Permissions - Darktrace RESPOND, new settings will appear to add Darktrace RESPOND Permissions and upgrade to the Account Permissions level to
which control whether a user or an IP can be actioned by Darktrace RESPOND SaaS actions. Antigena. Once this is complete, immunity settings will appear against each account.
These are Immune Users and Immune IP Addresses.
The organization would like to ensure the IP 35.176.59.98 is not actioned in either tenancy.
• Immune Users are users which will not be actioned by Darktrace RESPOND, whether To do this, it must be added to Immune IP Addresses for both accounts.
by models or by manual actions. Actions blocked due to immunity will report this status
in the Antigena Actions page. The field takes a comma-separated list.

To make a user immune, enter their username as it appears in the Darktrace Threat
Visualizer or SaaS console. Do not include the prefix. For example, SaaS::Office365:
[email protected] would be entered as just [email protected].

• Immune IPs Addresses are IP addresses that will not be blocked by actions that control
access to the relevant third-party platform, such as “Block IP”. This field will only appear
if the module can take IP-based actions.

The field takes a comma-separated list of IPs or valid CIDR IP ranges.

When “Per Inhibitor Antigena” is enabled, immunity can also be set for specific actions. For
example, a user could be eligible for lower severity actions like “Force Logout”, but immune
from more stringent actions like “Disable User”. These settings are in addition to the general
Immune Users and Immune IP Addresses settings.

Inhibitors will also differ between modules as capabilities and appropriate actions vary
between different platforms.

163
DARKTRACE RESPOND/NETWORK MODELS

Darktrace RESPOND/Network and Darktrace RESPOND/Endpoint expand Cyber AI response Reviewing the Darktrace RESPOND (Antigena Network) Models
to devices by severing network connections, restricting access and quarantining devices by
limiting their outbound connectivity. Open the Model Editor. In the Threat Visualizer interface, the Model Editor is accessible from
the main menu under Models > Model Editor or from any breach log with the “ Click to view
Actions can be taken when a device exhibits significantly anomalous behavior, when it model” button.
contravenes a compliance policy, when a device attempts to access a specific watched
endpoint, or any other custom criteria defined in a model. Unlike anomaly level, which is From the left-hand model list, select the Antigena >
determined on behavior, risk profiles will vary across an organization’s network according to Network folder.
business requirements.
In this folder, Darktrace RESPOND models for Network
You may wish some devices and users to be exempt from Darktrace RESPOND Actions, to and Endpoint are grouped into four categories:
restrict the actions to only match anomalies exhibiting certain behavior or apply actions Compliance, External Threat, Insider Threat and
automatically only at certain times of the day. Significant Anomaly.

Model Categories • Models inside the Compliance folder are

linked to potential compliance breaches like
Darktrace RESPOND/Network and Endpoint responses are triggered by model breaches within unauthorized file storage and TOR usage.
the Threat Visualizer - Darktrace RESPOND models look for specific behavior or for indicators
triggered by other model breaches. Darktrace models are a series of logical statements and • Models inside the External Threat folder
conditions which, if met, trigger an alert or action; models are primarily used to identify and contain behavioral elements suggestive of an
alert on anomalous and potentially malicious behavior. The models framework leverages both external threat.
the underlying ‘pattern of life’ detection and outputs from Darktrace Deep Packet Inspection
and security integrations and modules. • Models inside the Insider Threat folder contain
behavioral elements which suggest highly
When Darktrace RESPOND/Network or Darktrace RESPOND/Endpoint are enabled within your unusual internal or lateral behavior.
Darktrace environment, a new collection of models will become available: Antigena > Network.
This collection contains specific models for unusual device behavior which are set to trigger • The Significant Anomaly folder contains models
on specific types of connection or activity and perform different Darktrace RESPOND actions which are independent of attributable aspects,
depending on the incident identified. but are consider significantly anomalous.

When a model breaches that would trigger a Darktrace RESPOND/Network action, the device
is checked for the relevant tag before the action is performed. For example, a device performs
unauthorized file transfer activity which triggers a compliance breach. If the Antigena
Compliance models are active, they will check that the device has either the Antigena
Compliance or Antigena All tags before the action is performed.

164
DARKTRACE RESPOND/NETWORK TAGS

Darktrace RESPOND/Network can take a range of proactive, measured, automated actions in Automatic Tagging
the face of confirmed cyber-threats detected in real time. Darktrace understands the ‘pattern
of life’ of users, devices, and networks and so Darktrace RESPOND can take action in a highly The Model Editor contains a series of models which apply tags automatically based on criteria.
targeted manner, mitigating threats while avoiding over-reactions. Typically, a subset of all
devices will be deemed appropriate to place under Darktrace RESPOND control. Return to the model editor, but instead select the Tags > Antigena folder. Inside this folder
are models which correspond to each Darktrace RESPOND/Network (Antigena) tag. These
Whether a device is eligible to be autonomously actioned by Darktrace RESPOND/Network models are marked as “Requires Configuration”, meaning they are templates and must be
is defined by the tags applied to that device. There are five Darktrace RESPOND/Network modified to suit your environment before being enabled. The External Threat Tag model will
(Antigena) tags, corresponding to the model categories: now be used as an example.

• Antigena Compliance

• Antigena External Threat

• Antigena Insider Threat

• Antigena Significant Anomaly

• Antigena All

When a device is given the Antigena Compliance tag, for example, it becomes eligible to
receive Darktrace RESPOND/Network responses triggered by models in the Compliance
category. The final tag - Antigena All - makes the device eligible for responses from all
categories.

By default, no devices are tagged. Tags can be applied in three ways: individually, by bulk
tagging in Device Admin, or by enabling tagging models to provide automatic tagging. The
latter - automatic tagging through tagging models - is often the easiest method in large
environments. This model has one component which looks for connections - expand this component.

165
The component is comprised of three key filters and three example filters. The key filters Once the model is enabled, any client devices in these subnets will automatically be tagged
identify outgoing connections from client devices which do not already have the Antigena and the tag remain active for one week, at which point it will expire and either be immediately
External Threat tag. These filters are always required in the breach logic. re-added or not, if the device no longer meets the criteria. This approach can be used with any
Darktrace RESPOND/Network tagging model to slowly expand coverage across all subnets.

Threat Visualizer v5.1 introduced targeted blocking for server device types. The client devices
filter in this model can be altered or removed to widen the range of tagged device types.
Servers tagged with Darktrace RESPOND/Network (Antigena) tags will, however, only be
actioned if the relevant setting is enabled on the System Config page.

Please see Darktrace RESPOND/Network and Server Devices for more information.

Below are some subnet ranges - these filters are templates which demonstrate how subnet
ranges can be included for tagging. These should be substituted for the subnets you wish to
be automatically enrolled in Darktrace RESPOND/Network (Antigena) External Threat actions,
following the example given.

166
DARKTRACE RESPOND/NETWORK INHIBITORS

Models can take a series of actions in response to breaching such as triggering an alert, raising
INHIBITOR DESCRIPTION
the priority of a device or adding a tag. When Darktrace RESPOND is enabled on a deployment,
the additional Antigena model action becomes available. When Darktrace RESPOND/Network Group ‘pattern of life’ allows a device to make any connections and
Enforce group
or Darktrace RESPOND/Endpoint are enabled within your Darktrace environment, category of data transfers that it or any of its peer group typically make. This
pattern of life
Darktrace RESPOND (Antigena) models already using the Antigena action are exposed. action is less strict than the individual ‘pattern of life’ enforcement.

This action allows an operator to set an ‘inhibitor’ - an action to inhibit the behavior that matches Quarantine device All incoming and outgoing traffic from or to a device is blocked.
the model criteria. Darktrace RESPOND/Network and Darktrace RESPOND/Endpoint share a
set of inhibitors that can be selected. Block all outgoing
All outgoing traffic from a device is blocked.
traffic
In some cases, Darktrace RESPOND may be unable to perform the specific inhibitor as set on
the model - for example, where the target device is a server and the inhibitor is “quarantine”. Block all incoming
All incoming traffic to a device is blocked.
Similarly, an inhibitor may be upgraded under specific circumstances. For example, the “block traffic
matching connections” inhibitor may be upgraded by Darktrace RESPOND if the quantity of
outgoing matching connections to block becomes too large, indicating escalating malicious
activity that would be better targeted with “block outgoing connections”.

Inhibitors
INHIBITOR DESCRIPTION

This option allows Darktrace RESPOND/Network to automatically

choose the best option using information gathered from the alert. For
example, if the alert concerns suspicious behavior to an SMB share
Automatic
on port 445, it may block connections just to that port. If a range of
suspicious connections to various external endpoints was seen, it
may instead select to block all external connections.
Darktrace RESPOND/Network will block the specific connection and
Block Matching all future connections that match the same criteria. For example, the
connections FTP block prevents all future outbound connections to port 21 from
the target device.
Enforce ‘pattern of life’ allows a device to make the connections
that it usually makes. Therefore, it only allows connections and data
Enforce pattern
transfers which Darktrace considers normal for that device. Any
of life
unusual traffic (marked with an unusual message in Darktrace) is
blocked.

167
WORKFLOW FOR REVIEWING DARKTRACE RESPOND ACTIONS

Reviewing and Tuning Darktrace RESPOND/Network

When Darktrace RESPOND/Network is first enabled, reviewing each Darktrace RESPOND Working down the event log, find Darktrace Alerts that may have prompted the Darktrace
action can be a useful way of gaining confidence in the autonomous actions and locating any RESPOND Action to occur.
models which may require further tuning. It is recommended an operator should review any
currently active actions first. 6. Understand the conditions of the model that caused the Darktrace Model Breaches

After reviewing a Darktrace RESPOND Action or after reviewing all Darktrace RESPOND Actions, If you are not familiar with the conditions of the Darktrace Model Breach, you can review the
you may wish to adjust the parameters of the Darktrace RESPOND Models or tag membership. model logic by returning to the Model Editor from the main menu.

7. Identify which connections caused the Darktrace Model Breach to occur

Suggested Workflow
Return to the Event Log to review any connections that may have contributed to the Darktrace
1. Identify an action Model Breach.

Open the Darktrace RESPOND Actions menu item and identify an action to investigate. 8. Consider the risk posed by removing the Darktrace RESPOND Action or by extending
the Darktrace RESPOND Action
2. Understand the effect of the Darktrace RESPOND Action on that device or user
Are the connections being blocked preventing any business activities?
Review the description under the Action column.
• If NO then you may wish to leave the Darktrace RESPOND Action in place.
To see specific connections that have been interfered with, click on the device name under
the device column. • If YES then consider the anomalous behavior that provoked the Darktrace RESPOND
Action.
3. Understand the conditions of the model that caused the Darktrace RESPOND action
Are you satisfied that the anomalous behavior reported by Darktrace is benign?
If you are not familiar with the Darktrace RESPOND Model that caused this Action, click on the
name of the model to launch the model editor entry. • If YES then you may wish to remove the Darktrace RESPOND Action on the device. You
can do this by clicking the Clear button from the Antigena Actions page.
4. Review the event log for the action
After reviewing the Event Log you may wish to extend the Action for a period of time. (Note that
To open the Event Log for the device from within the Antigena Actions page, click ‘true’ in the Darktrace RESPOND Actions will automatically extend if further anomalous activity is seen
blocked column. from the device).

5. Identify any Darktrace Model Breaches that prompted the Darktrace RESPOND action 9. Optionally consider whether the level of anomaly justified the specific Darktrace
RESPOND Action placed on that device in the context of your business logic for that
In the Event Viewer (opened in previous step) locate the Darktrace RESPOND Action. device

168
DARKTRACE RESPOND/NETWORK DEPLOYMENT SCENARIOS

Tailoring the Darktrace RESPOND/Network Deployment Key recommendations

Tailoring Darktrace RESPOND/Network responses to best fit the network environment can be • When moving from human confirmation mode to active mode, begin with active mode
approached from a number of different angles. Understanding how a Darktrace RESPOND/ out of business operating hours using the schedule. Gradually progress to active mode
Network action is triggered on a specified device will ensure that only desired devices will be during business operations until 24hr active mode is achieved.
targeted for autonomous responses. When a device breaches a model contained within one
of the Darktrace RESPOND/Network folders, Darktrace RESPOND/Network will look for the • Frequently review devices eligible for actions and ensure changes in network structure
corresponding tag on the device before responding. are covered by Darktrace RESPOND response.

The ‘Antigena All’ tag allows Darktrace RESPOND to take action when any default Darktrace • If specific models frequently produce low level alerts, consider tuning the model with
RESPOND model breaches, regardless of subfolder. For instance, a model residing within the one-click defeats or altering the logic to better reflect your organizational requirements.
Antigena > Network > Compliance folder will only prompt a Darktrace RESPOND response if it
is triggered by a device that either has the tag ‘Antigena Compliance’ or ‘Antigena All’. See the Each tag has a corresponding tag model which can be used to continually apply tags to new
Darktrace RESPOND/Network Models guide for more information. devices which meet the criteria. Editing these models to provide future coverage is explained
in Darktrace RESPOND/Network Tags. The scenarios below cover the recommended
Default Darktrace RESPOND/Network Models will only fire on devices with one of the Darktrace RESPOND tag to apply to the specified device types to produce different levels of
Darktrace RESPOND/Network (Antigena) tags applied. For custom models with Darktrace configuration. In all cases, substitute ‘Any Client Device’ for a specific IP range or device type(s)
RESPOND responses enabled, it is recommended that the model excludes devices without as desired.
the appropriate tags. This can be achieved with the following logic, modified as appropriate
for the model target: Please note, servers tagged with Darktrace RESPOND tags will only be actioned if the relevant
setting is enabled on the System Config page. This setting is enabled on deployments
Tagged [Internal Source/Internal Destination] Has Tag [Antigena All/ initialized from v5.1 and above. Please see Darktrace RESPOND/Network and Server Devices
Antigena Compliance/etc] for more information.

Deployment Scenarios

Darktrace RESPOND/Network offers granular controls and can be tailored in a number of

different ways. The exact methodology for deploying Darktrace RESPOND/Network will
depend on the composition of your network - the following provides an outline of simple
deployment options.

169
Scenario 1 - Minimum Requirement for Core Protection Scenario 4 - Full coverage
EXTERNAL SIGNIFICANT INSIDER EXTERNAL SIGNIFICANT INSIDER
DEVICES ALL COMPLIANCE DEVICES ALL COMPLIANCE
THREAT ANOMALY THREAT THREAT ANOMALY THREAT

Client Devices check Client Devices check

Server Devices check Server Devices check

External Threat includes targeted coverage for ransomware.

Scenario 2 - Expanded Coverage of Client Devices

EXTERNAL SIGNIFICANT INSIDER
DEVICES ALL COMPLIANCE
THREAT ANOMALY THREAT

Client Devices check

Server Devices check

Scenario 3 - Expanded Coverage of Client and Server Devices

EXTERNAL SIGNIFICANT INSIDER
DEVICES ALL COMPLIANCE
THREAT ANOMALY THREAT

Client Devices check

Server Devices check check tilde

Insider Threat: Review the model set and apply to appropriate servers only.

170
DARKTRACE RESPOND/NETWORK AND SERVER DEVICES

Autonomous Darktrace RESPOND/Network response is designed to control unusual activity Inhibitors

on devices by restricting connectivity, increasing severity from surgical endpoint-specific
blocks up to full quarantine. Many phased deployments of Darktrace RESPOND/Network This capability uses existing Darktrace RESPOND/Network inhibitors with some minor
capability have targeted autonomous response at client devices. Automatic eligibility models modifications. These modifications will be clear in the final action displayed on the Antigena
available for roll-out prioritized the tagging of device types such as laptops and desktop Actions (Darktrace RESPOND) page.
unless actively edited.
• In default configuration, a “quarantine” action applied by a model will be downgraded
The business-critical nature of servers creates ideal opportunities for lateral movement, to “block all outgoing traffic”.
persistence, or for threats such as ransomware to spread rapidly from a single key asset to
many client devices. Darktrace RESPOND autonomous response can provide AI-powered Configuration options are available to upgrade quarantine actions to full quarantine or
defense of these systems, halting unusual activity whilst ensuring normal operations are prevent quarantine actions (including downgraded actions) entirely.
maintained.
• Incoming connectivity to a server device will only be actioned in specific circumstances:
How it Works
• If a model applying the specific “Block matching connections” inhibitor breaches
From Threat Visualizer v5.1, Darktrace has tailored Darktrace RESPOND/Network actions to on incoming traffic to the server device.
surgically respond on devices identified as servers. Devices with a server device type such as
Proxy Server or DNS Server will experience targeted blocks - full quarantine actions will never • Where Darktrace RESPOND deems that a specific connection from a client to a
be applied. Incoming connectivity from clients deemed to be part of the ‘pattern of life’ will not server is most effectively blocked by targeting the incoming connection on the
be prevented, ensuring business continuity whilst unusual activity is blocked. server end. For example, where an action is desired against a client using a proxy,
but the client is unreachable, so the incoming connection from that specific client
Before v5.1, servers may have experienced Darktrace RESPOND/Network control under to the proxy is targeted. This use case is highly specific and occurs infrequently.
specific circumstances:

• Server devices observed by Darktrace for less than 24 hours are eligible for Darktrace
RESPOND/Network actions to allow for early device type changes.

• Server devices may be indirectly impacted by actions taken through Active Integrations
such as firewalls.

• The “Block Server Devices” option was manually enabled on the System Config page.

From v5.1, “Block Server Devices” will be enabled by default on new deployments or those
initialized on or above this release. Existing deployments will need to enable the setting on the
Darktrace System Config page. A warning will now appear in the Threat Visualizer interface if
server devices are tagged for Darktrace RESPOND but this setting is disabled.

171
Configuration

1. Access the Darktrace Threat Visualizer on the master instance and navigate to System
Config from the main menu.

2. Select “Modules” from the left-hand menu and confirm that the Antigena Network
entry is enabled and licensed before proceeding.

3. Return to “Settings” from the left-hand menu and locate the Antigena subsection.

If not already, ensure the Block Server Devices settings is enabled.

Save the changes.

Servers and Darktrace RESPOND/Network (Antigena) Tags

To experience Darktrace RESPOND/Network actions server devices must be tagged with

one of the Darktrace RESPOND/Network (Antigena) tags. Please see Darktrace RESPOND/
Network Tags for more information.

Default models which control Darktrace RESPOND/Network (Antigena) tags will continue to
target client devices by default; this can be altered by changing the “Client - Any” filter or by
following the recommended steps in Darktrace RESPOND/Network Deployment Scenarios.

172
CHAPTER 11 - THE MOBILE APP

GETTING STARTED
REGISTERING THE APP AS A USER 174

CYBER AI ANALYST
AI ANALYST VIEW 175

DEVICES AND MODELS

MODELS VIEW 177
DEVICES VIEW 178

OTHER VIEWS AND SETTINGS

ANTIGENA (DARKTRACE RESPOND) VIEW 180
SUMMARY VIEW 181
CONFIG VIEW 181
REGISTERING THE APP AS A USER

The Darktrace mobile app, an increasingly popular option that our customers are utilizing in 3. Open the Darktrace app.
order to get alerts whilst away from the office, can be registered from the Account Settings
page. A configured mobile app Service is presumed - if this is not configured, please see You will be prompted to authenticate with the
Configuring the Mobile App or Configuring the Mobile App for IMAP(legacy) for the setup Darktrace appliance. Press ‘Next’ to proceed.
process.
The app will request permission to use your
How to Register smartphone camera. Use the camera to scan
the QR code in the Threat Visualizer generated
1. Navigate to Account Settings from the main above.
menu of the Threat Visualizer or SaaS Console.
4. After the QR has been scanned, you must
The ‘Register Mobile App’ option should now provide a password to finalize authentication.
be available. Click ‘Register Mobile App’ to
reveal a QR code. For Threat Visualizer and LDAP users, enter the
password used to log into the Threat Visualizer.

For SAML SSO users, enter the passphrase

displayed in the same pop-up as the QR code
2. On your smartphone, open the appropriate app as the user password. This passphrase is only
store and search for Darktrace. valid for 90 seconds. Ensure that all characters
including hyphens are entered correctly.
The Darktrace iOS app is available on the App
Store, and the Android app is available on The app should now authenticate.
Google Play.
Move between the screens for a guide overlay
Download the Darktrace app. explaining the functionality. The guide can be
re-enabled at any point from the config page.

174
AI ANALYST VIEW

Cyber AI Analyst Incident Details

The Cyber AI Analyst screen displays recent incidents An incident is composed of one or more events; single-
created by Cyber AI Analyst, grouped by involved event incidents will open the specific event, multiple-
device(s). Device details such as device type, hostname event incidents will open an overview page.
and tags are displayed for each incident alongside a list
of the events that it comprises. • The blue line represents the time frame over
which the events occurred, each represented
• Swipe right to pin the incident. Pinned incidents as a white dot (unacknowledged) or a grey dot
will appear at the top of the list and will persist (acknowledged). Events that happened almost
until unpinned. concurrently will be clustered closely together.
Tap any dot to switch to the details of that event
• Swipe left to acknowledge the incident and all - a blue dot represents the event currently
underlying events. selected. Green segments indicate Darktrace
RESPOND activity.
• Tap on an incident to review.
• Where there are multiple events, swipe left or
• Drag down on the incident list to trigger a right to move between the event screens.
manual refresh. Cyber AI Analyst incidents
summarize a large amount of information into a • Tap the comment-alt icon to add a comment to the
simple write up; users may wish to spend longer incident. If another user has commented
reviewing these incidents and underlying already, the icon will appear with lines in the
events than they would breaches in the Models body. Submitted comments will appear in grey
or Devices tab. Consequently, Cyber AI Analyst when pending and in white once confirmed as
will not automatically refresh the list of incidents. received by the Darktrace appliance.

Incidents created by Cyber AI Analyst do not • Tap the pin icon to pin the incident to the top of the Cyber AI Analyst incident list; pinned
encompass all model breaches on the network, only events will display a filled icon thumbtack. Pinned incidents will always appear at the top of the
those deemed particularly unusual or in need of further list and will persist until unpinned.
investigation. Users who wish to review all alerts raised
by Darktrace should also consult the Model or Device • Tap ‘acknowledge’ or ‘acknowledge all’ to acknowledge the one or more underlying
tabs. events of the incident. Acknowledging a Cyber AI Analyst event does not acknowledge
the associated model breaches unless ‘acknowledge underlying model breaches’ is
selected.

• Tap the share-alt icon to create a short message with a link to the incident in the mobile app
and in the Darktrace Threat Visualizer. The share option can be used to make a note
for later follow-up or to email a colleague with the request that they investigate further.
175
Overview Events

• The Summary gives a brief overview of the key Each event is built from one or more associated
events involved in the incident. breaches collated by Cyber AI Analyst.

• The Attack Phases Involved associates those • The Summary gives a brief outline of the event
events with the stages of a cyber attack they and suggests possible actions to be performed
likely represent. in response.

• Tap on any bullet point to pivot to the event • Related Model Breaches lists the models
details. breaches involved within the event. Tapping
on a breach will open the breach details; here,
further connection and contextual information
is displayed and the model breach can be
commented upon or acknowledged.

• Breached Devices lists the devices involved

in the event and their respective tags. Tap on
device to review the recent breaches associated
with that device, acknowledge those breaches
or review active Darktrace RESPOND actions
against the device.

• Depending on the event type, multiple sections

containing contextual information will appear.
These may include connection information,
devices triggering connections, transferred file
information.

• Any Darktrace RESPOND actions triggered by

the event will also appear here.

176
MODELS VIEW

Model Overview Model Details

The models screen displays the list of models with Tapping on a model breach will open the model Details
recent breaches, one row for each unique model which screen. This shows all the recent breaches for the
may have multiple breach instances. At the top of the selected model (depending on filter options) and a
list are the current filtering preferences as defined in short description of the model itself. For each breach
the cog Config. Tap any filter to review or change your instance, the triggering device is listed. There is one
settings. row per breach, so a device may appear multiple times
if it triggered the breach repeatedly.
• The breach count shows the number of recent
breaches for that model (or the number of • Tap the envelope-open icon to mark all individual breaches
unacknowledged breaches depending on the as read.
breach filter selected).
• A long tap on an individual device row will open
• Unread breaches have a blue circle beside a list of all recent breaches seen for that device.
the model name. Swiping right on an unread
model will mark all underlying breaches as read. • Swipe right to mark the breach as read/unread.
Swiping right on a read model breach will mark
all as unread. • Swipe left to acknowledge the breach.

• Drag the screen down to reveal the search bar • Tap the share-alt icon to create a short message with
and trigger a manual update. a link to the breach in the mobile app and in the
Darktrace Threat Visualizer. The share option
can be used to make a note for later follow-up or
to email a colleague with the request that they
investigate further.

177
 DEVICES VIEW

Breach Details Devices

Tapping on a device within the Model Details screen The Devices Screen displays the list of devices with
opens a pop-up that allows you to ‘acknowledge’ the recent breaches, one row for each unique device which
breach. Acknowledging a breach signals the Darktrace may have multiple breach instances. At the top of the
server which marks the breach as acknowledged, the list are the current filtering preferences as defined in
same as using the tick control in the breach log. If the cog Config. Tap any filter to review or change your
acknowledged breaches are configured as hidden, it settings.
will be removed from the list. If they are configured as
shown, the breach will remain but be greyed out. • The breach count shows the number of recent
breaches for that device (or the number of
• The breach details reflects the contents of the unacknowledged breaches depending on the
Model Breach Event Log in the main Threat breach filter selected).
Visualizer. This gives details of the connections
involved in the breach and any contextual • Devices with unread breaches have a blue
information. circle beside the device name. Swiping right
on a device with unread breaches will mark all
• Tap on any of the breach details to produce underlying breaches as read. Swiping right on
a pop-up with further information about the a device breach that is already read will mark all
connection or event. For external locations as unread.
such as IP addresses or hostnames, Darktrace
will attempt to derive a geolocation; the globe icon • Drag the screen down to reveal the search bar
indicates a geolocation is available. Tapping and trigger a manual update.
this icon will open a Maps application at the
derived coordinates.

• Any Darktrace RESPOND Actions related to the breach will appear in this list.

• Tap the comment-alt icon to add a comment to the breach. If another user has commented already,
the icon will appear with lines in the body. Submitted comments will appear in grey
when pending and in white once confirmed as received by the Darktrace appliance.

• Tap the acknowledge button to acknowledge the breach.

• Tap the share-alt icon to create a short message with a link to the breach in the mobile app
and in the Darktrace Threat Visualizer.

178
Device Activity Graph Device Details

Tapping the graph icon above the number of breaches Tapping on a device breach will open the Device Details
will open the Device Activity graph. This displays all screen. This shows all the recent breaches for the
breaches for the given device within the time frame selected device (depending on filter options). For each
defined in the cog Config. breach instance, the triggering Model is listed. There
is one row per breach, so a Model may appear multiple
• The y axis represents the time frame selected times if it triggered the breach repeatedly.
in the config.
• Tap the envelope-open icon to mark all individual model
• The x axis represents the severity of each breaches as read.
breach.
• A long tap on an individual model breach row
• Tapping on a breach dot will produce a summary will open a list of all devices that have recently
pop-up. breached that model.

• Drag with two fingers to zoom. Return to the • Swipe right to mark the breach as read/unread.
original view with the undo-alt arrow.
• Swipe left to acknowledge the breach.

• Tap the share-alt icon to create a short message with

a link to the breach in the mobile app and in the
Darktrace Threat Visualizer. The share option
can be used to make a note for later follow-up or
to email a colleague with the request that they
investigate further.

All tags applied to the device at the time of the breach

appear here. Any applied after the breach time will only
update if a further breach is triggered for the device.

179
 ANTIGENA VIEW

Breach Details Antigena (Darktrace RESPOND)

Tapping on a device within the Device Details screen The Antigena screen displays recent Darktrace
opens a pop-up that allows you to ‘acknowledge’ the RESPOND actions listed by category; Active, Pending,
breach. Acknowledging a breach signals the Darktrace Cleared and Expired.
server which marks the breach as acknowledged, the
same as using the tick control in the breach log. If Active devices are currently being controlled by
acknowledged breaches are configured as hidden, it Darktrace RESPOND.
will be removed from the list. If they are configured as
shown, the breach will remain but be greyed out. Inactive devices are not yet being controlled by
Darktrace RESPOND.
• The breach details reflects the contents of the
Model Breach Event Log in the main Threat Tap on an individual Darktrace RESPOND action to
Visualizer. This gives details of the connections review details of the device, the model that prompted
involved in the breach and any contextual the action and the timing of the Darktrace RESPOND
information. action.

• Tap on any of the breach details to produce Any decisions you make will be mirrored in the Threat
a pop-up with further information about the Visualizer.
connection or event.
Swipe left on a Darktrace RESPOND Action to make
• Any Darktrace RESPOND Actions related to the changes. Two options will appear:
breach will appear in this list.
• Extend will lengthen the Darktrace RESPOND
• Tap the comment-alt icon to add a comment to the breach. If another user has commented already, action on the device for the specified time.
the icon will appear with lines in the body. Submitted comments will appear in grey
when pending and in white once confirmed as received by the Darktrace appliance. • Activate will inform Darktrace RESPOND to start
controlling the device with the action specified.
• Tap the Darktrace RESPOND icon to review any current Darktrace RESPOND actions
active against the device. • Clear will inform Darktrace RESPOND to
stop controlling the device and suppress the
• Long pressing on the device name will show a pop-up with all recent model breaches combination of Darktrace RESPOND Action and
by that device. Breach Condition for 24hrs.

• Tap the acknowledge button to acknowledge the breach. Tapping the desired option will provide time options for how long the Darktrace RESPOND
Action should be Extended, Activated for.
• Tap the share-alt icon to create a short message with a link to the breach in the mobile app
and in the Darktrace Threat Visualizer. Swipe left again to activate the right-hand option.
180
SUMMARY VIEW CONFIG VIEW

Summary Config

The Summary screen mirrors the high-level summary The Config screen offers multiple filtering options
information available on the home screen of the Threat that allow you to customize how data is displayed and
Visualizer. It displays metrics about all the devices and stored within the app.
traffic Darktrace can see across your enterprise.
Filter Settings
It also indicates the number of Darktrace RESPOND
actions taken and currently controlled devices. Cyber AI Analyst Language

The summary page will refresh periodically. Pull down Changes the default language for the AI Analyst
on the summary area to trigger a manual refresh. view. Tap the language to move through all available
languages or long press to select from a list.

Sort Models/Devices

Sorts the tab in order of highest threat score, latest

breach or highest number.

Sort Breaches

Sorts the list of breaches that appears in Device or

Model details by most recent breach or highest threat.

Sort Unread

Sorts the list of breaches by unread first, then by the

order specified by the previous two filters.

Model Filters

Like the Threat Tray, model breaches can be filtered

by the model folder. Tap the button to see a list of
available filters.

181
View Threat Threshold Troubleshooting Mode

Controls the minimum threat score that a breach must reach before it appears in the Models/ Produces detailed errors when enabled - generally recommended for troubleshooting IMAP
Devices tabs. This filter is only applied locally and will not affect other users or any other forms configurations only.
of alerting. If the filter is modified, the app does not need to refresh before breaches within the
new conditions are shown. Reset Tips

Filter Read Re-enables the feature descriptions that appear when the app is first opened.

Defines whether breaches marked as read will be visible in the Models/Devices tabs. Authenticate

Filter Acknowledged Re-scan the QR code in the main Threat Visualizer Account Admin page.

Defines whether breaches acknowledged in the app or in the main Threat Visualizer will be Set Pin Code
visible in the Models/Devices tabs.
Set a (minimum four digit) code for an alternative log-in method.
Filter Within
Stay Signed in For
The time frame over which breaches will be shown, graphs will be plotted and recent device
breaches will be returned in further information pop-ups. Set the time required between logins to 5 minutes (default), 15 minutes or 1 hour.

Help and Configuration Settings

Notification Threat Threshold

Controls the minimum threat score that a breach must reach before it creates an app
notification - visible in the Notification Centre (iOS) and on the lock screen. This filter is only
applied locally and will not affect other users or any other forms of alerting.

Fetch Notifications

This setting only controls refresh times for new breaches when the mobile device is in an area
of low signal and is only intermittently receiving internet access.

Store Data

Controls how long data is stored within the application on the mobile device.

182
ABOUT DARKTRACE

Darktrace is the world’s leading cyber AI company and

the creator of Autonomous Response technology.

Its self-learning AI is modeled on the human immune

system and used by over 4,000 organizations to
protect against threats to the cloud, email, IoT,
networks and industrial systems. This includes insider
threat, industrial espionage, IoT compromises, zero-
day malware, data loss, supply chain risk and long-
term infrastructure vulnerabilities.

LAST UPDATED REISSUED

April 4 2022 August 1 2022

US: +1 415 229 9100 UK: +44 (0) 1223 394 100 LATAM: +55 11 4949 7696 APAC: +65 6804 5010 [email protected] darktrace.com