Darktrace Threat Visualizer

USER GUIDE v5
CONTENTS
Visual Threat Investigation 4 The Model Editor 86
LOOKING AROUND THE NETWORK USING THE MODEL EDITOR

FOCUSING THE VIEW UNDERSTANDING A MODEL

INVESTIGATING ALERTS MAKING A NEW MODEL

INVESTIGATING SAAS ALERTS

Darktrace Antigena 108
Advanced Features 42 UNIVERSAL ANTIGENA ELEMENTS

ALTERNATIVE APPROACHES ANTIGENA SAAS

ADVANCED SEARCH ANTIGENA NETWORK

THREAT INTELLIGENCE
The Mobile App 128
ADMINISTRATION
GETTING STARTED

The SaaS Console 70 CYBER AI ANALYST

GETTING STARTED DEVICES AND MODELS

THE DASHBOARD OTHER VIEWS AND SETTINGS

CYBER AI ANALYST
Appendix138
PROFILES
MODEL EDITOR
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 Threat
Darktrace’s threat detection capability uses a self-learning approach. Instead of trying to pre- 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.

3
CHAPTER 1 - VISUAL THREAT INVESTIGATION
Looking Around the Network
SUGGESTED WORKFLOWS FOR INVESTIGATING AN ALERT 5
LOGGING INTO THE THREAT VISUALIZER FOR THE FIRST TIME 7
GETTING STARTED WITH THE THREAT VISUALIZER 8
MAIN MENU GUIDE 9
VIEWING THE NETWORK 14
EXPANDING A SUBNET 15
VIEWING A DEVICE 17

Focusing the View

DEVICE OPTIONS 17
OMNISEARCH19
EXTERNAL SITES SUMMARY 20
WORKING WITH TIME 21
ADJUSTING THE TIME RANGE 22

Investigating Alerts
UNDERSTANDING THE THREAT TRAY 24
CYBER AI ANALYST 26
TRIGGERED AI ANALYST INVESTIGATIONS 27
CYBER AI ANALYST INCIDENTS 28
VIEWING A MODEL BREACH 31
EXPLORING THE MODEL BREACH EVENT LOG 33
UNDERSTANDING THE DEVICE EVENT LOG 34

Investigating SaaS Alerts

EXTERNAL SITES SUMMARY FOR SAAS AND CLOUD 37
DEVICE SUMMARY FOR SAAS AND CLOUD 39
DEVICE EVENT LOG FOR SAAS AND CLOUD 40
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 breaches performs the heavy-lifting of the analysis process.
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 one or more Darktrace Security Modules can utilize the SaaS Console for
triage and analysis. This specialized interface is focused on the investigation of incidents within 5. If the activity of interest relates directly to a model breach, investigate the breach log.
SaaS and Cloud environments. For more information, please see Getting Started with the
SaaS Console. 6. Check the Actions section to see if Antigena 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.

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

6
Logging into the Threat Visualizer for the First Time

The Threat Visualizer has been designed to accommodate many different ways of working
as organizations and individuals operate differently to each other. This section aims to give a
sense of a suggested workflow within the tool for customers who are encountering it for the
first time, and most individuals will find their naturally preferred way of working after using the
tool for a short time.

The interface is designed to allow analysts to explore the behavior that is going on within the
digital business, at both the current moment in time, and for weeks and months into the past. By
diving into networks, selecting devices, and navigating between them, the analyst can explore
what has been happening and narrow into activities of interest without any need to know in
advance what they are searching for.

Start the Threat Visualizer by typing the IP (https://<applianceIP>/) or hostname

(https://[region]-XXXX-01.cloud.darktrace.com) of the instance into the
browser’s address line. The login screen will be displayed.

Enter your username and password to login. The password can be reset at any time from the
User 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.

When logging in for the first time, a customer license agreement screen will be displayed. Read
the terms carefully and agree to proceed. 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.

Please note, the minimum supported browsers to access the Darktrace Threat Visualizer
application are Chrome 60, Firefox 55, Safari 11.1.

7
Getting Started with the Threat Visualizer

THREAT VISUALIZER HOME SCREEN

After logging in, the Threat visualizer home screen will be displayed. The summary of subnets 3. Search box
and devices is a quick way to understand your network and spot any trend changes. Notice the
Threat Visualizer automatically tries to detect the type of devices, such as servers and clients. 4. Special purpose networks: Link Local Traffic, Internal Multicast Traffic, External Multicast
Traffic, Broadcast Traffic, Internal Traffic, SaaS providers
“Patterns of Life” represents the number of unique connections between devices. Connections
include every separate pattern interaction with a device such as individual logins and access 5. Subnets identified and grouped by location where known
to network shares of file systems. Typically, there are approximately two hundred connections
for every device on a network. The graph, on the left-hand side of the UI, represents the 6. Time selector
bandwidth per hour for the entire network being captured by Darktrace.
7. Status including number of Devices, Credentials and Networks being modeled. Data
The UI elements drawn on the right-hand side of the page when viewing networks and devices and mathematical processing volumes. Antigena status.
provide summaries of the types of behavior occurring, and can be clicked to become filters
e.g. to show only RDP traffic or external traffic or unusual behavior. 8. Threat tray and filters

1. Home button (returns you to this screen) 9. Sensitivity slider

2. Main menu
8
Main Menu Guide

The Darktrace Main Menu offers an instant way to get to the main features within the UI. Clicking ENVELOPE EMAIL CONSOLE
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 Antigena Email interface for investigation and autonomous actions on your email
domains. Please see the documentation on Antigena Email for more information.
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 from
TAGS TAGS Darktrace Security 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

Presents currently active and expired actions taken by Antigena Network and Antigena SaaS
and allows the actions schedule to be configured. Current and historic actions can be exported
as a CSV. Refer to Reviewing Antigena Actions for more information.

9
EXCLAMATION-TRIANGLE MODELS View Reports

Model Editor Opens a tooltip showing the list of reports viewable by the current user, with the status, title,
and date. See Creating and Viewing Incidents for more information.
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. New Incident

list Model Summary Opens the Incident Builder tooltip where user can report an incident. See Creating and
Viewing Incidents for more information.
List of the models with analysis of how many times and how strongly each model has breached
since the appliance was installed. New Report

Model Updates Opens the Report Builder tooltip where user can build a report. See Creating and Viewing
Incidents for more information.
This page allows you to view recent updates to the models. Refer to Model Updates or the
Darktrace System Administration Guide for more information.

WRENCH ADMIN

BOOK REPORTING desktop Device Admin

Executive Threat Report 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
Quickly generate a report by clicking Executive Threat Report which will look over a specified device). Refer to Device Admin for more information.
time period and produce a PDF based on the statistics generated from Darktrace. Refer to
Generating an Executive Threat Report for more information. cubes Subnet Admin

download Download Reports Similar functionality but applies to subnets. The DHCP slider shows whether Darktrace should
be seeing DHCP for that specific subnet. Refer to Subnet Admin for more information.
All TIRs are retrievable via the interface by clicking Download Reports. A safe and reliable
way to transmit and receive sensitive data. Where automatic Executive Threat Reports are id-card Audit Log
configured in the Console, these weekly generated reports will appear here.
This page shows recent interactions with the platform completed by the various users (e.g.,
View Incident acknowledging breaches, logging in and out).

Opens a tooltip showing the list of incidents viewable by the current user, with the status, title,
and date. See Creating and Viewing Incidents for more information.

10
 System Status PLUG UTILITIES

System metrics such as ingested traffic quality, master/probe reachability, and protocols U Punycode Convertor
observed can be reviewed.
Enter text in the top window to convert to Punycode; enter Punycode in the bottom window to
cog System Config convert to text. Punycode is used in DNS to encode Unicode international domain names (IDN)
into ASCII. Can be identified as it always starts ‘xn—’".
Provides all configuration settings for the Darktrace Threat Visualizer application including
Antigena settings and authentication for SaaS security modules. Alerting options can be (.*) RegEx Tester
configured here.
Enter a RegEx in the top bar and an example string to test it in bottom bar. If the string matches
user User Admin the RegEx the bottom box’s border turns green; otherwise it remains white/yellow.

User permissions can be set on a per-user basis. See the Guide to User Privileges or Darktrace 64 Base64 Convertor
System Administration guide for a full list of User Permissions.
Enter text to be decoded or encoded using Base64.
users Group Admin
js JS Beautifier
Users can be sorted into groups to assign network visibility and permissions. For groups
created via LDAP or SAML SSO, permissions can be controlled here. Tool for ‘beautifying’ JavaScript to increase readability

unlock-alt Permissions clock Epoch Converter

Users who have created other users (and therefore ‘own’ them) can review their permissions Converts epoch time in seconds since 1st Jan 1970 (as seen in advanced search) to normal time.
here in a read-only format. The “admin” user can also review permissions for users created via
LDAP and SAML SSO on this page.

11
RANDOM INTEL MAP EXPLORE

check Trusted Domains cube Explore Subnets

‘Trusted’ domains are domains which Darktrace will consider as 0% rare; this feature ensures Explore Mode for subnets gives an overview of all connection events between subnets at
that models relying on domain rarity will not fire for activities involving common domains such a given time interval, filterable by connection size and transfer ratio. Drill-down to a device-
as adobe.com or google.com. There is a default list which can be added to on this page. to-device level is also possible. A master layout can be defined to reflect existing network
topology diagrams.
eye Watched Domains
tag Explore Tags
‘Watched’ domains are any domains added by Darktrace users on this page (there is no default
list). If any watched domain is seen (e.g., as part of a DNS request or HTTP activity), the Watched Explore Mode for tags gives an overview of all connection events between Tags at a given
Domains model will fire. See Watched Domains for more details. 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
cog TAXII Config diagrams.

Permits the ingestion of internal or third-party TAXII feeds and STIX files. The last 10,000
observables ingested can be reviewed, whether derived from stand-alone files, subscribed
TAXII collections or Darktrace Inoculation. See TAXII Config for more details. QUESTION HELP

BOLT DYNAMIC THREAT DASHBOARD Ask the Expert

The Discovery View provides an easy left-to-right dashboard to investigate an incident down Ask the Expert allows for the creation of incidents which can be submitted to Darktrace analysts
to the connections that caused the alert to fire. Refer to Dynamic Threat Dashboard for more for feedback. Refer to Ask the Expert for more information.
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.

API Help

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

12
COGS ACCOUNT SETTINGS

Change settings for your own account including default color-coding in the event log, log details
font size, orientation of the threat tray controls, changing password, enabling Accessibility
Mode, ability to move the camera, AI Analyst language settings and whether or not the world
map display zooms into a subnet on load.

CUSTOMER PORTAL

Opens the Darktrace Customer Portal in a new browser window or tab. The Customer Portal
provides access to all product documentation, support tickets, analyst insights and Darktrace
Education materials.

LOGOUT

Log out the current user account.

13
Viewing the Network

VIEWING ALL SUBNETS The subnets shown in shades of blue do not have any devices with anomalies present, and
the subnets in shades of yellow do have devices with anomalies present. Any green subnets
Hovering over the cube icon of subnets shown will show a summary of subnets identified at contain a device on which Antigena has recently acted.
that global location.
By hovering the mouse over the cubes in the expanded subnet, the following additional details
will be shown:

ο Subnet name

ο The IP address range and its associated subnet mask extension

ο The number of devices identified as part of that subnet

Click on a subnet cube icon to explore it in more detail with the real-time visualization.

To view more detail for a location, click on the subnet cube icon and the expanded view of
subnets will be displayed.

The same details are displayed when typing the subnet’s IP address in the search box at the
top left of the screen.

14
Expanding a Subnet

VIEWING A SPECIFIC SUBNET

Click and hold the left mouse button to turn the subnet around 360°. Click and hold the right
mouse button to slide the subnet across the screen. Whilst viewing the subnet the analyst can
click on the external devices shown on the right of the screen to see all internet resources
that are being accessed by the subnet overlaid around the globe. Conversely clicking on the
internal subnets on the left-hand side allows the analyst to navigate to those subnets.

The image above shows an example of an expanded subnet. It shows all of the subnet’s active
connections and the traffic flows between subnets and devices, both internal and external. The
‘brick wall’ image visualizes the boundary between internal and external devices.

By hovering with the mouse over a device, the following details for that device will be shown:
When viewing a subnet, an overview of useful statistics appears at the right, regarding the
ο Hostname most-used protocols and the largest data flows to other internal subnets and the wider internet.
This allows you to filter what’s shown in the subnet view to display, for example, only UDP
ο IP Address activity on the subnet, or only communications to another specific subnet. Multiple filters can
be applied by clicking on the subset of data you want, and removed by clicking the applied
ο MAC Address filter that appears at the top or bottom of the screen.

ο Vendor

ο Operating System

ο Device type

ο Allocated Subnet

15
USING THE SUBNET VIEW

The subnet view can be used to gain an initial overview of how the network is set up and identify,
for a given subnet, broad trends in the subnet’s activities including potentially unexpected or
risky communications and configuration issues.

You can use this view, for example, to identify at a high level:

ο Which common protocols this subnet’s devices typically use?

ο How much traffic is attributed to each protocol?

ο Are critical asset servers grouped in the same subnet used for browsing?

ο Which are the most-used devices?

ο Are any non-authorized protocols used? (For example Telnet instead of SSH, where this
is not permitted)?

ο Are devices using DNS servers outside the network instead of internal DNS servers?

ο Are any other normally internal protocols (e.g., SMB, SNMP) leaking outside the network?

ο Is SSH common in a subnet that doesn’t include the IT team whose devices are in a
specific subnet?

16
Viewing a Device Device Options

VIEWING A DEVICE

The next step in familiarizing oneself with the Threat Visualizer is narrowing in on an individual When a specific device is selected, a series of buttons will appear to the right of the selected
device to understand the information immediately visible and what actions can be performed device name. These buttons can be used to investigate device behavior or change configuration
at this level. Once a device has been clicked on or located using search, new options appear settings. If an icon is not visible, you may not have the corresponding user permission.
that allow you to quickly visualize and understand what type of device you are looking at and
how it typically behaves. c AI ANALYST INVESTIGATION

1. The device currently in focus Launches an AI Analyst investigation on this device.

2. Internal servers in communication with the device a ANTIGENA ACTIONS

3. Internal clients in communication with the device Shows the actions Antigena is currently taking or has taken in the past that involve this device.

4. A green lasso indicates an Antigena action is applied to this device

5. A yellow-red coloring indicates alerts for this device

6. Additional Device Options

17
 DEVICE SUMMARY OPEN GRAPH

Displays basic information about the device and its behaviors, including recent model breaches, View graphs showing the trends of certain types of activity associated with this device over a
other devices with similar behavioral patterns, and typical ports it connects on (and serves) and given time range. You can select from a list of metrics (e.g., types of connection or event).
devices it connects to (and is connected to by). For SaaS and Cloud users, please see Device
Summary for SaaS and Cloud. The time range defaults to the time of the event in the main Threat Visualizer, but can be
changed by clicking the horizontal axis, or by clicking and dragging across the main plot area
ALIGN-JUSTIFY DEVICE EVENT LOG of the graph.

More detailed discussion of this feature can be found in Understanding the Device Event Log Clicking the out/in/total buttons allows you to display whether you are seeing all connections,
or Device Event Log for SaaS and Cloud. those initiated by this device or those connections received.

EXCLAMATION-TRIANGLE MODEL BREACH LOG By clicking the ‘+’ sign you can also add the plot of another metric to the graph.

Shows any model breaches associated with this device in the time period selected in the threat VIEW CONNECTIONS DATA
tray, in the same format as the standard model breach log. See Viewing a Model Breach.
This brings up 3D graphs of the typical connection history for the selected device. The graphs
EDIT INFO show this device’s behavior over an adjustable time period, and compared to its peer devices
that Darktrace has modeled as similar (of decreasing similarity from front to back). You can also
Click on the ‘Edit Info…’ button to add additional information for this device: see graphs of incoming and outgoing data volume from the device and its peers.

ο Set a nickname for this device which will be displayed and can also be used as a search You can filter to see a graph of connections to/from a given port by clicking the port shown in
term the smaller donuts.

ο Set a type from a list, values are: Camera, DNS Server, Desktop, File Server, IP Phone, The two donut pie charts show the proportions of ports the device uses (or serves) and devices
IoT, Key Asset, Laptop, Log Server, Mobile, Printer, Proxy Server, Router, Server, TV, it connects to (or is connected to by).
Tablet, Unknown, Virtual Desktop, Wifi
VIEW SIMILAR DEVICE MAP AND VIEW SIMILAR DEVICES
ο Set a priority for the device from -5 to 0 to +5; changes in priorities will affect how highly
prioritized any alerts from this device are when shown on dashboards/threat tray Additional to the ability to investigate the detailed behaviors of any one device or user is the
ability to see the comparative behavior of entities that the platform has observed are peers or
‘near neighbors’ in terms of their behavior. The devices modeled as similar to any given device
can be found through the Device Summary, Similar Device Map, or View Similar Devices
(which shows a list of similar devices). In the map view, similar devices can further be visualized
according to exactly how similar or dissimilar their behaviors are.

SQUARE-FULL JUMPS BACK TO THE SUBNET VIEW.

18
Omnisearch

The omnisearch bar can be found at all times while on the Threat Visualizer on the top left of A device search will yield all servers or clients detected on the network. To search for a device,
the screen. you can search by:

The search autocompletes and suggests the most relevant search results. There is no need to ο Hostname
be press enter to submit.
ο Mac Address
While searching, there are many different search types of data points to look for and utilizing
the autocomplete you can work to maximize the search by searching for only a portion of the ο Username of user logged into that device
query. Utilizing omnisearch can help locate further information about a particular user or device,
or to gather information about a specific event. ο IP Address

For example, if you have only a partial hostname that you are trying to use to locate a device, the ο Nickname
omnisearch bar will perform a “contains” search and suggest devices based on the substring.

A user search will return multiple clickable options, the first is the user credential which will
show when the user logged in.
TYPES OF OBJECTS AND SEARCH LAYOUT
A subnet search will return all subnets and provide options to click through to the below action
Search results are laid out so that the left most element will display the relevant object type items.
(laptop, desktop, user, subnet, model, SaaS user etc.). Followed by the search result that will
contain the search query. And furthest to the right will contain object-specific action items for To search for a subnet, begin typing the subnet address. Each result will yield the hostname
quick access. with the action items below. Clicking on each item will yield subnet- specific results.

Darktrace can search for different object types including: devices, users, subnets, and models. To view all devices in a subnet, press the magnifying glass icon. This will change the query to
“subnet:[input]”.

A model search will return models with the ability to quickly access the breaches and the
model editor.

19
External Sites Summary

LAUNCHING EXTERNAL SITES SUMMARY

When characters are entered into the omnisearch bar, Darktrace will autocomplete with
suggested searches. These suggestions can reveal further information on the interaction of
internal devices with external sites through a four-part data visualization.

Clicking on a suggested hostname or IP will perform two actions. The selection will auto-fill for
an event log window that opens and populates with the activity to the external location from
the time on the top right timeframe. Clicking on any IP here will launch another External Sites Summary window with that IP
as the area of focus, populating related hostnames rather than IP addresses into the top
The translucent globe towards the right of the search bar will launch the External Sites Summary. left quadrant.

If the External Sites summary is launched from an event performed by a SaaS user, or for an IP ο The top right quadrant will show any model breaches associated with the hostname. On
address only seen performing SaaS actions, a specialized version of the External Sites Summary click, a breach log will appear with all related breaches for that hostname and model
will open. Please see External Sites Summary for SaaS and Cloud for more information. combination.

UNDERSTANDING THE SUMMARY ο The bottom left quadrant will display all devices that have connected to the external site.
On click, the bottom right quadrant will open.
Darktrace associates every hostname with the IP address returned from passive DNS. As
Darktrace observes a device making a DNS query it will associate the query (e.g., hostname) ο The bottom right quadrant will show the ports that the selected device used to connect
with the answer (e.g., IP Address). Future connections to that IP address will be associated with to the external site.
the most recent hostname observed.

The External Sites Summary provides a 4 quadrant window to provide detailed information on
the external locations and how the internal devices being modeled have interacted with them.
The summary respects the Threat Tray time window and will filter the information accordingly.

ο The top left quadrant will show all IPs that Darktrace has seen since it was connected to
the network, with the date it was first observed and the most recent connection seen. 20
 Working with Time

chart-line Rarity TIME SELECTOR

The rarity icon will open a chart showing the rarity of the site over the last month. The time selector at the top right of the interface allows the analyst to move back/forward
through historical data and to broaden the shown periods of view e.g. show the behavior of 1
globe-americas Geolocation hour vs 24 hours. By default, the Time selector is set to your device’s time zone.

The geolocation icon will open the geolocation tab. Using an internal database for geolocations, CHANGING THE TIME ZONE
Darktrace will plot the hostnames/ IPs locations for a general idea of where the IP lives in the
world. Click on the date and within the Search bar for time
zone, enter your desired time zone or city, such as GMT
or Los Angeles.

Click the Set Time button at the bottom to save your

settings.

MOVE TIME SELECTOR TO A SPECIFIC DATE

AND TIME

To set a specific date and time:

Click on the current date and time, this will open a

window where the date and time can be set manually.

Select the date and time to monitor and click on the ‘Set
Time’ button below the calendar to save.

Please Note: Any logs open will not show the new
time zone until closed and reopened.

21
 Adjusting the Time Range

RETURN DISPLAY TO CURRENT TIME CHANGING THE TIME RANGE

To return the displayed activity to the current time, Selecting this option expands the Time Selector
select the double arrow button on the far right of the window to show a 5-minute time span with the start
Time Selector window indicated. and end times indicated at the left and right of the time
span indication. (The arrow then becomes a ‘x’ button
This will provide a view of the device or devices that collapses the window and removes the time frame
previously selected, but at the current system time. In expansion arrows).
addition, it will return the Time Selector window back to
its default settings (no time range selected). It is possible to adjust the time range displayed by
clicking the arrows indicated.

By clicking on the left ‘1h’ arrow indicated, the span

displayed can be increased to 1 hour.

By clicking on the right ‘15m’ arrow indicated, the span

displayed can be decreased to 15 minutes.

Clicking on either of the arrows will increase or decrease the span of time displayed in the
Time Selector. The newly selected display range is shown at the top of the Time Selector
window with the new start and end times indicated to the left and right of the span indication.

The selected time is always in the middle of the span, so that half of the span is before the
selected time and half is after the selected time.

22
MOVING THE TIME RANGE DISPLAYED

It is possible to move the time range selected forwards

or backwards by clicking on the corresponding buttons
indicated.

The pre-defined values are as follows:

ο m = 1 minute

ο 10 = 10 minutes

ο h = 1 hour

ο d = 1 day

REPLAY OF THE ACTIVITY IN THE SELECTED

TIME RANGE

To replay the activity for the selected time range, press

the ‘Replay/Pause’ button as shown below.

A cursor will be displayed which shows the progress of

the replay in relation to the time range selected:

It is possible to move the cursor back and forwards

within the window using the mouse. The replay can
be halted at any time by pressing the ‘Replay/Pause’
button again.

23
Understanding the Threat Tray

THREAT TRAY

Any model breaches generated through Darktrace’s mathematical modeling or other models The severity slider will filter models by breach score when filtering is set to ‘Models’ or ‘Users’,
defined by the customer are displayed in a tray at the bottom of the main screen. and device score when set to ‘Devices’.

There are two ways to view the tray of model breaches; in both views the tray can be Note that the sensitivity slider does not affect any underlying processing, it just affects what
customized to be sorted by devices, users, types of breach, or devices that are or have been is currently displayed in the tray.
under Antigena control. They can also be customized to show particular time ranges, to include
or exclude previously acknowledged breaches, specific subnets or the breaches that relate to CHANGING THE VIEW
compliance (belonging in the Compliance folder).
On the bottom left of the Threat Visualizer there are two buttons to switch between the default
Selecting different ways of viewing model breaches allows you to focus on either the most and cluster view (a secondary view for displaying model breaches)
problematic users and devices, or the most problematic types of behavior, depending on your
preferred approach. All sorting options can be seen on the bottom portion of the tray. ο th-large displays the alerts as blocks, where the left-hand border correlates to the strength
of the anomaly and the quantity of breaches for the model-type is displayed next to the
FILTERING THE MODEL BREACHES small triangular alert icon.

A severity slider is displayed to the right of these sorting options. This slider allows you to filter ο chart-area displays an area chart of the model breaches; from left to right you will find the
out less strongly anomalous or less relevant model breaches, enabling you to prioritize your model breaches placed on the timeline, scored from bottom to top in increasing
time effectively. severity. This view allows for the quick detection of clusters of model breaches. The
color-scheme correlates to the sorting mechanism used (e.g., Devices, overall score).
A typical approach to triaging model breaches might be to set the sensitivity between two high Hovering over the various types of alerts on the right- hand side will display the relevant
values e.g. 90% - 100% and triage the alerts that appear, then lower the score iteratively (e.g., model breaches, clicking in will open the breach log of all relevant model breaches for
50% - 90%) until the model breaches that appear are no longer of interest. investigation.
24
Within the cluster view, you can hover over any of the dots that represent a model breach to
gather quick intel including the device, the score, and the time of the alert. Clicking a dot will
open the breach log for investigation. To open multiple model breaches at once, click and drag
your mouse which will generate a rectangle in which you can encapsulate the model breaches
you would like to investigate.

Beside the view icons are two further icons:

ο thumbtack shows a number to indicate the number of pinned breaches. Click the number to
review the pinned breaches and click an individual breach to launch the Breach Log.

ο c opens the Cyber AI Analyst Incident view.

For more information, please see Cyber AI Analyst.

TRAY ICONS

A colored icon (ranges from blue through yellow to red) indicates that breaches are available
for the model named below the icon. The number in the circle on the upper right indicates the
number of breaches detected. If displayed, the number on the lower right in the white speech
bubble indicates the number of comments for this alert.

A grey icon with an exclamation mark inside indicates that the model has been edited since
the alert was generated.

A grey icon with an ‘X’ inside indicates that the model has been deleted since the alert was
generated.

25
Cyber AI Analyst

WHAT IS CYBER AI ANALYST? CYBER AI ANALYST INCIDENT TRAY

The Darktrace Cyber AI Analyst investigates, analyzes and triages threats seen within your The Cyber AI Analyst is accessible from the c icon in the bottom left of the threat tray - the
Darktrace environment. From a global position within the network, the Cyber AI Analyst Cyber AI Analyst incident tray will open.
accelerates the analysis process, continuously conducting investigations behind the scenes
and operating at a speed and scale beyond human capabilities. By learning from the millions of Incidents are categorized from blue to white, where white indicates the highest level of threat.
interactions between Darktrace’s expert analysts and the Enterprise Immune System, the Cyber Each incident will list the associated device, the derived device type and a short summary of
AI Analyst combines human expertise with the consistency, speed, and scalability of AI. The the events involved. If an event or incident was created from an investigation triggered by a
ability of AI to investigate every possibility, make connections between seemingly disparate manual investigation or a third-party alert, this will be indicated on the tile.
events, and quickly illuminate the full scope of a security incident dramatically reduces ‘time to
meaning’ and buys back time for human teams. Cyber AI Analyst will always prioritize the most severe incidents in the tray for the specified
time period. As it refines an understanding of each incident (or no further activity is seen on
Cyber AI Analyst will review and investigate all Model Breaches that occur on the system the device), incidents may reduce in severity or be replaced by emerging threats. The ‘show
as a starting point for its analysis process. It will then form Incidents - a collection of one or more’ button can be used to retrieve incidents that you were previously investigating or wish
more related events - centered around a device. Incidents involving multiple devices will be to revisit, but are no longer highest in severity.
classified as ‘cross-network’.
The Acknowledged/Unacknowledged filter shows or hides Acknowledged incidents. Incidents
Incidents created by Cyber AI Analyst do not encompass all model breaches on the network, can be acknowledged on an event-by-event basis or in their entirety on the Threat Visualizer
only those deemed particularly unusual or in need of further investigation. Users who wish to or in the mobile app. Acknowledging a Cyber AI Analyst incident does not acknowledge the
review all alerts raised by Darktrace should also consult the Model Breach Threat Tray. underlying model breaches.

Please note, the Cyber AI Analyst will only investigate model breaches of default Darktrace Any pinned Cyber AI Analyst incidents will always appear in the left-hand-side of the incident
models. Custom models are not currently supported. From Threat Visualizer v5 and above, tray. Click the Download Incidents button to download a PDF report containing all current
AI Analyst investigations can be triggered by third-party alerts using a dedicated meta-model. incidents in the tray.
26
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.

27
Cyber AI Analyst Incidents

CYBER AI ANALYST INCIDENTS

An incident is composed of one or more events; events are a group of anomalies or network that were not the original trigger point for the model breach but are worthy of investigation.
actions investigated by Cyber AI Analyst that pose a likely cyber threat. Click on an incident in Consequently, the event period may not correspond with the breach time. Additionally, some
the tray to launch the Cyber AI Analyst pane. model breaches require sustained behaviors such as repeated connections before breaching,
so the final breach trigger may be later than the connection of interest.
The clicked incident will launch a Cyber AI Analyst pane with the results of the analysis and
triage. It will open on the first event to occur as part of that incident. INCIDENT EVENTS

At the top of the panel is a representation of the incident time period. Model breaches which Each event will appear as a tab. The right panels will breakdown key elements of the event and
may be associated with each event will appear as dots, where color indicates severity. The the involved devices; the data is specific to each event type.
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. Antigena activity is The left panel gives a summary of the event outline. Model breaches that triggered Cyber
also shown in green on this timeline. 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
Like a human, the Cyber AI Analyst uses a model breach as a starting point to investigate device activity around the anomaly time.
the device. The behavioral analysis it performs may discover anomalies or patterns of activity

28
 INCIDENT ICONS

Further investigation by an operator should prioritize the anomalous activity signposted by

Cyber AI Analyst first and the model breach conditions second if the two do not directly align.

c Breaches Processing

A flashing Cyber AI Analyst icon indicates that it is currently analyzing other model breaches
caused by the device that may be relevant. If this analysis deems the breaches related to the
ο Click to to
center
center
thethe
Threat
Threat
Visualizer
Visualizer
onon
thethe
breach.
breach incident, Cyber AI Analyst will create additional events. Click the icon to expand the list of
processing breaches.
ο Click align-justify for the Model Breach Event Log.
angle-double-down Attack Stages
ο Click exclamation-triangle for the Breach Log.
Open a visualization of the events alongside the stages of a cyber attack they may represent.
Currently active or expired Antigena responses will be listed below the related breaches and
are also represented chronologically as green blocks on the graph. comment Comment on the Incident

Opens the comment pane where users can discuss the incident. Users may comment from the
Threat Visualizer interface as well as the mobile app.

download Create a Report

Opens a reporting pane where a downloadable PDF report can be created from the Incident.
ο Click a to open Antigena Actions. Any text entered into the Report Name field will be used as the filename and appear as a title
in the generated PDF.
ο Click align-justify for the Model Breach Event Log.

ο Click exclamation-triangle for the Breach Log.

The action section allows for the individual event to be pinned, acknowledged or acknowledged
alongside all related model breaches.

29
thumbtack Pin the Incident

Keeps the Incident at the left-hand-side of the Incident tray regardless of severity score. When
the incident is pinned, the tab will 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.

check Acknowledge Incident

Will acknowledge all underlying events for the incident. If all events are acknowledged, the
incident will be shown/hidden from the incident tray depending on the user settings. Events
can also be acknowledged individually as part of an incident investigation workflow.

For example, an operator may acknowledge an incident with a single device and a single
event. Cyber AI Analyst continues the investigation and discovers a cross-network attack
where multiple devices are displaying the same behavior from that event. It moves the event
into a new cross-network incident, but the acknowledged status of this single event does not
stop the overall incident being brought to the operator’s attention.

copy Copy to Clipboard

Copies a link to the incident to the clipboard.

30
Viewing a Model Breach

VIEW A MODEL BREACH

Acknowledge all Model Breaches in the list and Comment
Starting from the Threat Tray, click on one of the breaches to open the Breach Log. The breach
log can be opened from any location - including from a Cyber AI Analyst incident - where the In addition to acknowledging and hiding all the listed breaches, adds a comment to all the
exclamation-triangle icon appears. underlying breaches.

filter Text Filter

Filter the current model breaches listed by a textual search term or Regex. Once filtered, the
term will appear beside the text entry box. Click to remove the filter. Click the icon to show or
hide the text entry box.

A list with all detected model breaches for that device, user or type will be shown. All breaches
will be shown with some summary information that the system has extracted as potentially
relevant (or that you have defined as relevant in the Model Editor) for a first glance.

View breaches graphically

Shows a graph plotting the timing of the Model Breaches in the list against their percentage
score. When this graph is shown, a further button appears next to each Model Breach allowing
you to filter what’s on the graph (for example filter by device).

exclamation-triangle View model

Jump to this model’s entry in the Model Editor.

Acknowledge all Model Breaches in the list

This acknowledges and hides all the listed breaches.

31
The types of information shown can vary depending on the nature of the model breach, but
typically include: align-justify View this Model Breach in an event log

ο The time of the breach; This will open a Model Breach Event Log, showing a summary of only the key events the
underlying model believes to be connected with this breach.
ο Associated hostnames, IP addresses or usernames;
Analyze this Model Breach
ο The status of the model that was breached (it may be that the model has been
subsequently edited or deleted); Brings up a window showing the Model Breach Event Log and a graph of relevant metrics for
this breach.
ο The model’s metric and its corresponding filters for which anomalous values have
contributed to the breach; check Acknowledge this Model Breach

ο Potentially other summary and scoring information; This hides the Model Breach from view (it can be unhidden by clicking ‘Show acknowledged’).
Acknowledging the breach gives you a visual cue that you have already investigated it.
ο The breach ID.
Ignore Future Breaches for this Device
MODEL BREACH ICONS
This will prevent any future breaches of this model being triggered for this device.
Beside each individual model breach are a series of icons:
clipboard Copy to Clipboard
thumbtack Pin this Model Breach
Copies all the breach details to the clipboard including the breached device, the model breach
Pinning a breach will add a (1) to the Pin icon in the bottom left of the Threat Tray. Pinned display fields and a link to the breach.
breaches can be retrieved without having to keep the Breach Log open. Click again to unpin
the breach. Pinned breaches will persist between sessions.

View this Model Breach in the Threat Visualizer

This selects the breaching device and time in the main Threat Visualizer.

comment-alt Discuss breach with other users

This will open a text window where comments for other analysts (or your future self!) can be
added.

32
Exploring the Model Breach Event Log

OPENING THE MODEL BREACH EVENT LOG ο Any tags that the machine has

When you have selected to view a Model Breach in the Threat Visualizer, the device and ο If the device has recently been the subject of any Antigena actions
associated details at the time of the alert will be displayed:
To view additional details of this device’s activities that relate to the Model Breach, navigate
to the Model Breach Event Log by clicking the ‘list’ icon in the Breach Log. The Model Breach
Event Log displays the device events that are relevant to the selected Model Breach.

For example, for a model breach relating to unusual SSH connectivity, the Model Breach
Event Log might display a single anomalous SSH connection (or possibly more than one). By
contrast, for a Model Breach relating to excessive HTTP errors or port scanning, the Model
Breach Event Log will display far more events, because for these types of behavior it is a
number of events in combination that all contribute to the detection of an anomaly.

The Model Breach Event Log also opens up additional UI features that can be used to explore
the detailed behaviors of the devices and users. These features also occur in the Device
Event Log. The next layer of detail occurs within this Device Event log, another source of data
regarding the behavior of individual devices on the network that contributed to a breach.

Hovering the mouse over the icon for the device in question, a list of the following details will
be displayed:

ο Hostname

ο IP address

ο MAC Address

ο OS type (if known)

ο Vendor (if known)

ο Machine type (if known)

The Device Event log and Model Breach event log share a series of filters and controls, located
ο The subnet the device belongs to at the top of the pane.

33
Understanding the Device Event Log

OPENING THE DEVICE EVENT LOG

The Device Event Log is a powerful interactive view of all of the behavior of a device. When
investigating an anomaly using the Model Breach Event Log, you may want to get additional
information about the behaviors of the device at the time of the Model Breach, including those
that do not relate to the anomaly. For this you can use the Device Event Log.

When you have selected a device in the Threat Visualizer, its event log can be viewed by
clicking the relevant button to the right of the device name at the top of the screen.

A series of buttons at the top of the log allow you to customize the view to filter out only certain
types of information or to change the color-coding for faster skim reading.

For SaaS or Cloud devices, see Device Event Log for SaaS and Cloud for any altered
functionality.

UNDERSTANDING THE LOG ο The dropdown menu next to the time for the connection enables further investigation
of that connection
The log is made up of the following types of information:
ο Clicking on the destination device pops up a separate event log for the destination
Connection events: these are displayed with a colored arrow and a short description. device around the time of the event this was linked from

ο Events are listed with the endpoints, type and port number Model Breaches: shown with blue/white text. Click the text to show this breach in a new breach
log window
ο A blue arrow signifies an outgoing connection, an orange arrow signifies an incoming
connection Commentary from Darktrace processing (that may or may not contribute to an anomaly
score) will also be shown e.g. “A small increase in number of internal IPs connected to” or “An
ο The arrow will flash if the connection was still ongoing at that point in time. unexpected time for login of user”

ο Arrows with a cross indicate a failed connection Trend analysis graph: If there is a small “graph” icon next to the comment, it can be clicked to
show historic trends of behavior for this type of event (e.g., connections to a specific device on
ο Hover over the arrow to see details for the connection including source and destination a specific port) day by day
IPs, data transferred and protocol

ο Hover over source hostnames, IPs or usernames to see summary information for that
device or user

34
LOG ICONS
Unsync log from the Threat Visualizer filters
At the top of the event log several device-related options are available:
If you are viewing a device in the main Threat Visualizer and have applied filters to show
only certain types of activity from the right-hand side list (e.g., show only connections to port
443), the event log will by default apply these filters to the logs shown. Click this to remove or
Add/remove custom filters reapply the same filters as shown in the main Threat Visualizer.

Filter the events you are seeing according to the following: Choose which type of events to show in the log / types of events that can be filtered out

ο Destination port ο Connections: indicated by a blue (outgoing) or red (incoming) arrow. A flashing arrow
means the connection is ongoing
ο Destination IP
ο Unusual connections: based on Darktrace mathematical modeling
ο External Hostname
ο New connections: these are signaled in the same way as unusual connections, with a
ο Source Port comment

ο Source Device ο Unusual activity: mathematically-based contextual information; not a model breach. The
activity may be slightly unusual but not enough to generate a model breach depending
ο Protocol on how ‘sensitive’ the model is. Indicated by an orange circle

ο Application Protocol ο Model Breaches: indicated by a blue triangle

Alternatively, select ‘Any Field’ to filter the current device event log by a textual search term or ο Notices: extra interesting contextual information about certain connections. Indicated
Regex. Once filtered, the term will appear beside the text entry box. by an ‘i’ sign

Unsync log from the Threat Visualizer time ο History: device history such as IP address or hostname changes, and different
usernames
You may have arrived at the device event log via investigating a device that previously breached
a model, so the device event log and main Threat Visualizer will show the same (past) time. Choose whether to show internal or external events in the log.
Unsyncing the log means that you can change the time shown in the Threat Visualizer while
still seeing the same data presented in the event log. When you click again to resync the log, it Show only internal network events, only external events or both.
reverts to the time shown in the Threat Visualizer, if you have changed it.
exchange-alt Toggle incoming/outgoing events.

Show only incoming connections, outgoing connections or both.

35
 Hide duplicate connections. Click on the caret-down triangle icon for a log entry to see a menu showing these event-related options.

Shows/Hides repeated connections.

Show connections to common hostnames

Common hostnames are determined based on what this network’s devices typically connect to.

Color-code events by their properties.

Color-code the event log lines by the specific filter. The SaaS Device Event Log has special
filter options - see Device Event Log for SaaS and Cloud.

Highlight connections that transferred more than a certain amount of data.

Filter on the amount of data transferred.

Hide/show connection descriptions

Hides/shows the interesting contextual descriptions.

View advanced search for this device ο View Advanced Search for this event: this launches the Advanced Search in a separate
browser tab and shows you only the logs relating to this specific connection
Opens a new browser tab to Darktrace advanced search (see below) Defaults to showing all
the selected device’s activities for the hour preceding the time of the Threat Visualizer. ο Create a packet capture file for this event: this creates a packet capture (PCAP) file for
the event over a configurable time period
View packet capture file for this device.
ο Get connection summary: opens a textbox that allows connection details to be cut and
See Creating Packet Captures. pasted into other incident management systems or the Darktrace reporting option

ENTRY-SPECIFIC ACTIONS ο Visualize connection history: opens a new ‘Connections Data’ 3D graphing window

ο Filter Event Log by the event’s protocol, application protocol, source port, destination
port or destination IP. Clicking any of these buttons filters the events shown in this view
according to the specified criteria

ο Copy to Clipboard: copies the event line to the clipboard.

36
External Sites Summary for SaaS and Cloud

LAUNCHING EXTERNAL SITES SUMMARY UNDERSTANDING THE SUMMARY

For SaaS and Cloud events, a specialized version of the External Sites Summary can be The External Sites Summary provides a 4 quadrant window to provide detailed information
launched which includes additional information about the user relationship with the external on the IP address performing the SaaS activities. The summary respects the Threat Tray time
location. This summary is accessible from the Device Event log for SaaS or Cloud users, the window and will filter the information accordingly.
Event Log for an IP address seen performing SaaS activity and the Model Breach event log for
SaaS Model Breaches. ο The top left quadrant will show further information about the IP such as the derived
location, ASN, geographic region and the overall rarity.
This summary is not accessible from the omnisearch function - the standard External Sites
Summary will be opened in this case. Instead, it may be accessed from one of the following ο The top right quadrant will show any model breaches associated with the IP Address.
locations: On click, a breach log will appear with all related breaches for that IP and model
combination.
ο From the Device Event Log for a SaaS or Cloud user, click the external-link-alt icon beside the IP
address the action was performed from. ο The bottom left quadrant will display all SaaS accounts that have connected from the
external IP. By default, the SaaS External Sites Summary is centered around the SaaS
ο From the Model Breach Event Log for a SaaS or Cloud breach, click the external-link-alt icon beside user who performed the action it was launched from. Click the exclamation-triangle model icon to view
the IP address the breaching action was performed from. Model Breaches for that user, or click to center the Threat Visualizer on the selected
user. This will not change the focus of the External Sites Summary.
ο From an IP Address Event Log, click the external-link-alt icon for a line where a SaaS or Cloud activity
was performed. ο The bottom right quadrant will show the SaaS activities performed by the selected user
from that IP address. Clicking through different devices on the left will modify the graph,
but will not change the overall External Sites Summary which is focused on the original
action-performing user.

37
chart-line Rarity

This icon will open a chart showing the rarity of the IP over the last month. This rarity is global,
not specific to the selected user.

globe-americas Geolocation

This icon will open the geolocation tab and zoom on the current IP address; Darktrace will plot
the approximate location of the IP address based upon geolocation information from the ASN.

The approximate geolocation for all IP addresses that have performed SaaS or Cloud activities
for this user are plotted on the map. Blue locations indicate sustained activity and red locations
are those which were only seen on one unique day in the last month. 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 itself to open the Event
Log.

38
Device Summary for SaaS and Cloud

SAAS DEVICE SUMMARY

globe-americas Geolocation
When the Threat Visualizer is focused on a SaaS or Cloud user - indicated by the user device
icon - the available device options and device summary are slightly altered. This icon will open the geolocation tab; the approximate geolocation for all IP addresses that
have performed SaaS or Cloud activities for this user in the last month are plotted on the map.
Click the icon to launch the Device Summary. Blue locations indicate sustained activity and red locations are those which were only seen on
one unique day in the last month.

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 itself
to open the Event Log.

One quadrant displays a summary of the user and any tags currently applied.

Two more quadrants list all currently unacknowledged and acknowledged model breaches in
the last seven days for that user. The time frame can be altered using the button in the top right
of the quadrant. Hover over the model name for a description tooltip. Click the exclamation-triangle model icon
to view the Breach Log for the model and the selected user.

A final quadrant lists the ASNs for IP Addresses seen connecting to the SaaS account over
the last month. 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.

39
Device Event Log for SaaS and Cloud

DEVICE EVENT LOG FOR SAAS AND CLOUD Hover over the info-circle for detailed information about the event performed. Depending on the
activity type (such as a login, a file share, a deletion), different information will be displayed in
The Device Event Log for SaaS and Cloud is made up of the following elements: the Action Breakdown, Info and Additional Information sections.

Model Breaches: shown with blue/white text. Click the text to show this breach in a new breach Hover over the IP address for a tooltip with approximate location information and network rarity.
log window
Click the external-link-alt icon to launch the SaaS-specific External Sites Summary for that IP.
Commentary from Darktrace processing (that may or may not contribute to an anomaly score)
will also be shown e.g. “A slightly unusual time for this activity”. Click on the caret-down icon to see the following event-related options:

SaaS and Cloud activities are structured slightly differently to standard network connection ο View Advanced Search for this event: this launches the Advanced Search in a separate
events. The log lines take the structure browser tab and shows you only the logs relating to this specific connection

ο the activity performed ο Copy to Clipboard: copies the event line to the clipboard.

ο the user performing the action

ο if applicable, the resource on which it was performed (for example a file, a virtual
machine, another user)

ο the IP it was performed from

40
SAAS AND CLOUD FILTERING

SaaS and Cloud events can be color-coded by three additional characteristics: Resource Type,
Event and Event Type.

ο Resource Type will color all log lines by the type of resource (such as Folder, User,
File) the action was performed upon. This is particularly useful to distinguish actions
performed on an object such as a Virtual Machine from general administrative actions.
The type will be added to the end of the log entry in square brackets.

ο Event will color all log lines by the activity performed, using the action as defined by the
third-party SaaS environment. Anomalous, one-off events are easier to spot in this color
mode. The event is added to the end of the log entry in square brackets.

ο Event Type will color all log lines by the type of event performed as defined by
Darktrace analysis. As the phrasing used to describe different actions varies between
SaaS vendors, this grouping method can be used to quickly understand and analyze a
chain of events without prior knowledge of the platform-specific terminology. The type
is added to the end of the log entry in square brackets.

41
CHAPTER 2 - ADVANCED FEATURES
Alternative Approaches
DYNAMIC THREAT DASHBOARD 43
EXPLORE MODE 45
FILTERING THE EXPLORE WORKSPACE 46
CREATING AND VIEWING INCIDENTS 49
GENERATING AN EXECUTIVE THREAT REPORT 50

Advanced Search
DARKTRACE ADVANCED SEARCH 51
NAVIGATING ADVANCED SEARCH 52
SEARCHING ADVANCED SEARCH 53
CHANGING THE LAYOUT AND FILTERING ADVANCED SEARCH RESULTS 55
BUILDING A COMPLEX ADVANCED SEARCH QUERY 57

Threat Intelligence
CREATING PACKET CAPTURES 58
ASK THE EXPERT 59
TAXII CONFIG 60
ADDING TAXII FEEDS AND STIX FILES 61
WATCHED DOMAINS 62
ADDING AND REVIEWING TAGS 63
COMMONLY APPLIED TAGS 64

Administration
DEVICE ADMIN 65
SUBNET ADMIN 66
ALERTS ON THE STATUS PAGE 67
SYSTEM TOPOLOGY 68
Dynamic Threat Dashboard

ACCESSING THE DASHBOARD SEARCH BAR

The Dynamic Threat Dashboard view dashboard can be accessed from the main menu, The search bar allows for powerful filtering by multiple search terms.
or 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 filter
View to view further information. Selections flow from left to right across the dashboard, and 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.

43
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 frame, bar. The filter can be removed by clicking the x beside
sorted by total score for that device. Each entry includes the filter term in the search bar.
either the time of the breach (for devices with only one
breach) and the count of the number of breaches for DETAILS PANEL
the device. Selecting an entry populates the Breaches
panel with the breaches for that model or device. The right-hand side panel displays summary information
for the selected breach. This information is designed
In users grouping, the panel lists user credentials to allow for quick decision making about the events in
that were associated with model breaches within question.
the specified time frame. Not all model breaches will
have an associated user credential; this panel will not The top section displays overall threat score and
encompass all model breaches, only those where a information about the device in question. The sections
credential can be associated. Each entry includes either below contain dynamically populated content showing
the time of the breach (for users with only one breach) connections and visualizations that contributed to the
and the count of the number of breaches for the user. breach.
Selecting an entry populates the Breaches panel with
the breaches for that user. The most relevant information will be automatically
displayed.

If the displayed information is inconclusive, clicking the

“Investigate” button will navigate to the 3D View with
the device, time, and breach event log for the current
breach selected.
44
Explore Mode

OPENING EXPLORE USING EXPLORE

The Explore feature can be accessed from the Main Menu item Explore, where the user may Communication between subnets or tags is indicated by a dashed line, where dash length
select from tag Explore Tags or cube Explore Subnets. Alternating between Tags and Subnets is correlates with the amount of data transferred. Each line indicates a group of connection
also easily performed within Explore itself. The pivot icon is also available in the main Threat events, but the direction of each event is not represented visually as concurrent connections
Visualizer when investigating a specific Subnet, or from the Tag Manager. in both directions may be observed at the same moment between numerous devices in the
particular subnet or represented by the specific tag.

The severity of any alerts generated by devices in a subnet during the time frame is indicated
by the color of the icon, where white indicates no breaches and a gradient from yellow to red
indicating severity.

INVESTIGATING A DEVICE

Clicking on a particular line representing at least one connection event will reveal the devices
within that tag or subnet observed communicating within the specified time frame.

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.

For each device, the label and broad device type are represented. Hovering over a device will
display more information about it.

45
 Filtering the Explore Workspace

Drilling down further still, clicking on a specific communication between two devices will FILTERING THE EXPLORE PAGE
open the Event Log for any connection events between the two devices within the specified
timeframe. The Event Log displays time, date and connection direction; hovering over the Clicking the pencil icon or FILTER in the top left will open the filter pane. Filtering will focus the
directional arrow provides further details such as protocol and data transfer volume observed. workspace by removing connections that do not match the given conditions; the current filter
Click the expand icon external-link-alt to pivot to the specific connection in advanced search. Clicking conditions will persist beside FILTER in the top left of the screen. The available filters:
on the source or destination will open the main Threat Visualizer focused on that device at
specified time.

Text Search

To return to the highest level, click the level-up-alt icon in the top right. Removes subnets or tags from the workspace that do not contain the search term. Items that
do not match the filter but are connected to/from by those that contain the search term will
appear faded.

Avg. rate (KiB/s) / Total size (MiB)

The rate of transfer in per second can be customized by shifting the slider from low rates of
transfer to high. The total amount of data that can be transferred in the time window is governed
by the rate - this total amount is displayed below the rate sliders. Where subnets or tags have
connected to/been connected to by other elements that do not fulfill the filter conditions, these
elements will remain but will be greyed out. Any grouped connections between subnets or
tags that do not meet the filter criteria will be removed.

46
Transfer ratio The Fixed Positions toggle locks Tag and Subnet nodes in place, preserving their location on
the workspace when deep-diving into particular connection events and returning to the main
The transfer ratio filters subnets or tags on the workspace by the ratio of data uploaded versus overview. When ‘Allow editing’ is enabled, the nodes can be individually dragged and dropped
the data downloaded during the time frame. The left slider controls the downloaded amount to alter their persistent position. Each user maintains their own local layout, but can also view
and the right slider controls the uploaded amount. At the highest level, this controls the total or copy the central master layout at any time.
amount of uploaded:downloaded between the two subnets. At a lower level, this ratio is on a
device to device level. When fixed positions is enabled, the user can enable the master layout defined by the admin
user. To edit the layout locally, click the ‘copy to account’ button, disable the master layout
Where subnets or tags have connected to/been connected to by other elements that do not toggle and then enable editing. Any changes will persist but will not affect the master layout.
fulfill 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. Master Layout

EXPLORE LAYOUT A global master layout can be defined to place subnets and tags in a specific location every
time; this is particularly useful for organizations with clear network topology diagrams who
The distribution of Subnets and Tags in the Explore screen dynamically updates to wish to reconstruct these diagrams for their subnets or tagged devices in the Darktrace user
position connection events in the clearest format; initial locations are derived only from the interface. User layouts are initialized with positions from the master copy at the time of account
communications observed during the time window. creation, and can copy the current master layout at any time.

Fixed Positions The single master layout which can be viewed by every user but only edited by those with the
relevant Admin permission. To modify the master layout, a user must have the Device Admin
permission to edit Tags and Subnet Admin permission to edit the Subnets view. To change the
layout, modify it locally using the Enable editing button and use the Copy to Master button to
share it with all users.

Exclusive Tags

The 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 will not render a connection between the tags that are shared between the devices.

47
For example, if two devices (a & b) are tagged with iOS device and iPhone and Exclusive
Tags was disabled, the behavior of Explore would draw a connection between iOS device
and 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 New Device, exclusive tags would render the connection between iOS Device and New
Device and the connection between iPhone and New Device, but not the connection between
the shared tags.

48
Creating and Viewing Incidents

The Threat Visualizer contains tools to produce write-ups of security incidents and investigations. Clicking “Preview” will open a new popup displaying the current state of the incident, and
These allow for collaboration and sharing with other users and the wider company through “Submit” will submit the question via Ask the Expert.
exportable reports. Write ups are produced in two stages – through the creation of individual
“incidents”, and then the collation of incidents into a report. These are created and viewed from Incidents can exist in the following states:
the main menu under “Reporting”.
ο Draft – viewable only by the current user
CREATING AN INCIDENT
ο Shared Draft – viewable by all users with the required permissions
Creating a new incident opens a pop-up window with required fields of “Incident Name” and
“Incident Date”. Incidents are intended to be localized to a specific time and related series of ο Reportable – available for inclusion in reports
network events. The construction of an incident is based around distinct sections that can
be added and reordered – a new blank incident contains one free text section for entering These states are progressed through linearly, and the next available state will be displayed as
relevant information. Clicking the “plus” button adds a new free text section, and dragging UI an action button in the current incident window.
elements in adds them as a new section. The selected section has a “handle” on the left-hand
side that can be clicked and dragged to change the ordering.

Multiple UI elements can be dragged into an incident, from metric graphs to device log entries.
Draggable elements will change the cursor state to a “hand” upon hover. Clicking and dragging
over the incident creation popup will create a new section. Elements with a time stamp can be
dragged by clicking on the time stamp portion of the element, e.g. model breaches in model
breach logs.

49
Generating an Executive Threat Report

GENERATING A REPORT REPORT OPTIONS

Executive Threat reports offer an overview of network activity and key events for a non- The popup window accepts a reporting period, either from the dropdown preset time ranges,
specialist audience. The first section provides a wide perspective overview and then the or with the date pickers for custom ranges. The following configuration options are available.
report focuses in on specific activity. Automatically generated Executive Threat Reports can be
generated from the Main Menu, under Reporting.

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.

Minimal

When ticked, the report will only generate the visual summary pages.

Include Acknowledged

When ticked, includes acknowledged breaches in the report.

Executive Threat Reports can also be automatically generated on a weekly basis (configurable Timezone
in the appliance console) and retrieved from the Download Reports section.
Type in the time zone box to select a time zone offset for model breaches in the report.
ο Selecting “Generate Report” will generate a report covering that time range,
summarizing breach stats and box status information.

ο These reports will be displayed within the popup window, and are available for printing
or download as a PDF from the menu bar that appears on hover.

50
 Darktrace Advanced Search

Include Comments WHAT IS ADVANCED SEARCH?

Includes any comments made by analysts on the featured breach. Darktrace analyzes network traffic through Deep Packet Inspection; each connection is
processed and logs containing key metadata about the connection are produced. Similarly,
Email Report Darktrace Security Modules and other integrations analyze activity data from third-party
platforms and create log entries for each event. The Threat Visualizer interface displays a
Emails the report to the users specified on the System Config “Executive Report Recipients” relevant subset of this metadata in device event logs and breach logs, however as an
field. This can be found under configuration for Email alerting. investigation progresses, the need can arise to review connections and events in more detail.

The Advanced Search interface provides searchable access to the detailed metadata logs
produced by network traffic and event analysis. For advanced users, complex query syntax
and data aggregation analysis are available. For those just getting started, simple queries can
be built up slowly and saved for future use.

LAUNCHING ADVANCED SEARCH

There are two ways to access Advanced Search: from an event of interest or from the main
menu.

Main Menu

Select “ Advanced Search” from the main menu of the Threat Visualizer, or “search Advanced
Search” from the SaaS Console sidebar.

Event of Interest

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
all log types, including the model breach log, device event log, and event log. This option may
not be available for all connections or events.

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
as actor or IP address. Selecting “Search Advanced Search for [this value]” from the options will
open a simple search for that characteristic.

51
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
time will be focused on the event time and only relevant log lines will be shown. or 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
The Darktrace icon in the top left will reset the page to the current time with no search and the in on 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.

52
 Searching Advanced Search

DEFAULT LAYOUT MAKING A BASIC QUERY

By default, the columns displayed are (from left to right): 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
ο Time: Date and time that the log entry was created, in the time zone of the device used well as wildcards (*) are also supported.
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 Multiple fields and multiple values can be connected together with comparators, for example:
inspected and @type:Office365 indicates the entry was analyzed by the Office 365 @type:"dns" AND @fields.source_ip=10.1.23.2. These additional conditions can
Security Module. be added manually, or by using the following buttons:

ο @message: A tab-separated summary of the fields contained within the log entry. ο The equals equals button adds a new AND condition to the current search.
Some fields are included in the detailed log entry but not in the message field. For @
type:notice, a list of possible messages is available. ο The not-equal does not equal button adds a new AND NOT condition to the current search.

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.

53
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 analysis. search is created with the Source IP and Destination IP of the entry, as well as the field
Each log contains universal fields such as the time the entry was created (@timestamp), a and value in the row where it was selected. For example, the row @fields.dest_port
unique identifier (@fields.uid) and type specific fields which are only produced for that would create a new query: @fields.source_ip:"10.0.18.224" AND @fields.
protocol or log type (@fields.saas_actor, @fields.query_class). Some fields, such dest_ip:"192.168.72.4" AND @fields.dest_port:"53".
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.

54
Changing the Layout and Filtering Advanced Search Results

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 easy options to perform data aggregation queries.
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”.

55
The Values tab shows a summary of the values across DATA QUERIES
the 50 results currently shown on the page, sorted
by frequency of occurrence. The summary allows an At the bottom of each field summary are four buttons: “Score”, “Trend”, “Terms” and “Stats”.
operator to get a sense of the logs returned and spot These buttons perform specific operations on the data returned by the search query and can
outlier results which may be unusual. Beside each be very useful to summarize large numbers of results.
result is the percentage of log entries that include that
value in the specified field - clicking a value highlights ο The Score action ranks values by frequency across the most recent 10,000 log entries
the log entries it appears in. 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 equals equals button beside each value adds
the field and its value as a new AND condition, ο The Trend action provides an estimation of the change in frequency for values across
narrowing the query to only those entries which the time period. A segment of matching entries at the start and end of the time period
match that value. Where the value is ‘Blank’, a are analyzed and the change in value occurrence calculated.
AND NOT _exists_:"@fields.example"
condition will be added instead. ο 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 not-equal does not equal button adds the field the Score analysis, however it provides a less precise count. The number of entries
and its value as a new AND NOT condition to analyzed where the field was missing will appear as a blank row above all other values.
the current search, effectively results which
have that value in the specific field. Where the ο The Stats action is only available for fields with numeric values. This analysis produces
value is ‘Blank’, a AND _exists_:"@fields. statistical information about the field value across the timeframe including the average
example" condition will be added instead. 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.
The Related Fields tab shows other fields that frequently
appear in the same log entries as the selected field.
Related fields are ordered by the percentage frequency
that they occur alongside the selected field out of all
currently displayed log entries where the selected field
appears.

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

57
 Creating Packet Captures

COMBINING SEARCH CONDITIONS PACKET CAPTURES

Conditions can be combined using the standard Boolean operators AND, NOT, OR. Most Packet Captures can be generated from connections seen in the Darktrace Threat Visualizer
conditions added using the equals equals and not-equal does not equal buttons will take this format. for further investigation. There are two ways of viewing raw packets (in PCAP format): firstly, by
Parentheses are also supported to group search conditions together creating the PCAP from the dropdown next to any connection in the device event log, secondly
by creating it from the device event log when a device is selected.
The default operator (if no operator is specified) between space-separated values is AND.
If you have a distributed deployment, raw traffic is stored on the probes, which can cause a
Examples: time delay in retrieving PCAPs. Any PCAPs created are then saved on the master appliance.

@type:conn AND @fields.proto:"tcp" Be aware that PCAPs are truncated due to storage requirements so you may not see the
@type:"azuread" AND (@fields.saas_metric:"Saas::Login" OR @fields.saas_ entirety of the data flow between the devices in question especially where large amounts of
metric:"Saas::FailedLogin") data (e.g., files) are transferred. However, the PCAP typically gives you enough information to
get an idea of what is happening.
Boolean operators can also be used within parentheses to create shorter queries - the
following two examples provide the same outcome. CREATING PACKET CAPTURES

Examples: 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.
@fields.source_ip:10.10.4.3 OR @fields.source_ip:10.10.4.4 OR @fields.
source_ip:10.10.4.7 Tip: If creating a packet capture file for a single device from the device event log, the Source
@fields.source_ip:(10.10.4.3 OR 10.10.4.4 OR 10.10.4.7) and Target fields are not shown. The field shown
instead is ‘IP’ (referring to the IP address of the device)
REGULAR EXPRESSIONS – no destination is specified.

Basic Regular Expressions (regex) can also be used for very specific searches. Source: This shows the source IP address pre-
populated with the value from the event which has
A regex must be preceded and followed by a forward-slash character (/) been selected.

Example: Target: This shows the target IP address pre-populated

with the value from the event which has been selected.
@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

58
 Ask the Expert

From: The start time of the packet capture. This is pre-populated from the event which has WHAT IS ASK THE EXPERT
been selected. The start time can be altered by clicking on the gray ‘From’ box.
Ask the Expert allows for the creation of incidents which can be submitted to Darktrace analysts
To: The end time of the packet capture. The end time can be altered by clicking on the gray for feedback. Creation of an incident is done within the Threat Visualizer by entering text and
‘To’ box. The time range defaults to Darktrace’s best guess as to which range will capture the dragging relevant data into the creation window. Submitted incidents become open questions
connection of interest (for example if it knows that the connection ended at a certain time). 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 closed
Create: This option starts the packet capture. when resolved.

Cancel: This option closes the window. Ask the Expert is available from the Main Menu, under Help – the “Ask the Expert” menu item
allows for the creation of new questions, and the “View Questions” menu item allows for the
Use Connection: This option is only available when creating a packet capture for an event. viewing of existing questions and their statuses.
Clicking this will further filter the selected packets by the connection. The time fields default to
the start and end second of the connection selected and the source and destination ports are VIEWING QUESTIONS
as specified in the connection.
The “View Questions” pop up lists all previously submitted questions with their timestamp,
VIEWING THE PCAP FILE owner, and status. Possible question statuses are:

The file can be viewed by clicking the PCAP option from the main menu. PCAPs can be viewed ο New
in the Threat Visualizer interface or downloaded for use in external tools.
ο 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.

59
TAXII Config

ACCESSING TAXII CONFIG STIX INBOUND SOURCES

Darktrace can connect to TAXII servers and also import STIX XML files, these are used to The STIX inbound sources page displays details of the last 10,000 observables received by
provide threat intelligence. The Threat Indicator model will create model breaches when an Darktrace. Each entry will describe the time of the last seen observable, the confidence and
observable derived from TAXII intelligence is seen. the processed observables from the feed. To view all ingested IoCs from each source, click the
expand icon beside the source name.
To access the TAXII Config page, navigate to the main menu and select the Intel category and
then TAXII Config. The TAXII Config page is also accessible from the “Modules” section of the
System Config page.

Sources are derived from information contained within each STIX package (XML) - typically
the Information Source field defined in the STIX specification (STIX 1.2). Information derived
from STIX uploads and TAXII feeds can be viewed on the STIX Inbound Sources tab. For STIX
SUMMARY packages uploaded without a 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
The summary page gives an overview of the TAXII servers and feeds subscribed to and the default to the collection. STIX files produced by Darktrace Inoculation will have the source
IoCs derived from those sources. ‘Darktrace’, or rarely ‘Inoculation’ in the case of older IoCs.

Observables Confidence

The value corresponds to the number of IoCs that have been collected from the TAXII feed. Each source will be assigned a default confidence of 50%. The source confidence can be
Observables should equate to total IoCs from that source. modified by clicking the pencil icon beside the source name.

% Processed

IoCs that have been checked against the network and successfully added to the watchlist are
considered “processed”. If the Valid Until field is a date before the Source Time (the time when
the IoC was received by Darktrace) the IoC will not be processed.

60
Adding TAXII Feeds and STIX Files

TAXII SERVICES ADDING A TAXII FEED

TAXII threat intelligence feeds can be added on the Configure TAXII Servers tab. 1. Navigate to the Configure TAXII Servers tab and click “Add New TAXII Service”.

2. Complete the details, using the following example as a guide. 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. Add the service by clicking Submit.

5. Ensure that TAXII polling is enabled or the feed will not be refreshed.

UPLOADING A STIX FILE

On the Upload tab, STIX XML files can be uploaded. Darktrace supports the following
ο When a feed is initially added, Darktrace will request STIX packages that are a maximum indicators: Domains, Hostnames and IPv4 addresses. URIs are not supported. Each indicator
of 2 weeks old. Subsequent queries will ask for STIX packages which have arrived on will be searched for historically and added to the watchlist in case it appears in the near future.
the TAXII server since the last known threat indicator received from that service.
Navigate to the Upload tab and select the XML file for upload. STIX versions 1.1.1 and 1.2 are
ο When polling is turned on, Darktrace will poll the TAXII server for new IoCs at the stated supported. On successful upload, the number of observables and metadata fields derived
interval. from the file will be displayed. These can be reviewed on the Inbound Sources tab.

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

61
Watched Domains

‘Watched’ domains are any domains added by Darktrace users, Inoculation, or Darktrace itself ADDING DOMAINS TO THE WATCHLIST
on this page. If any watched domain is seen (e.g., as part of a DNS request or HTTP activity), a
model will fire. Watched Domains page accepts the following formats when added manually: ο To add a single domain, enter it in the one line box above the file select and click Add.
IP Addresses (192.168.0.1), domains (example.com) and domains with a single subdomain The domain should now appear in the list accompanied by a Remove button.
(example.example.com).
ο To add multiple domains, enter a list of comma-separated domains into the larger box
and click Add.

ο Alternatively, upload a text file by clicking the Click to select file field and selecting the
desired list. Click Add File once selected.

Users can add watched domains to the default source list; when only one source has added to
the domains list, no source selector will be shown. To distinguish between domains added by
TAXII or STIX files, those added by Darktrace inoculation and those added by the user, each
list can be separately reviewed using the source dropdown. Domains added to the Watched
Domains list can be assigned an expiry, a confidence strength, specified as an exact hostname
(only identical strings will trigger a match) and trigger automatic Antigena Network actions
when seen. Domains added via the /intelfeed API endpoint may also contain an optional
description.

Entries with an asterisk indicate an exact hostname, “Antigena” indicates an action will be
triggered automatically and a percentage score beside a domain indicates the assigned
confidence.

62
Adding and Reviewing Tags

VIEWING AND EDITING TAGS ADD A NEW TAG

The Threat Visualizer supports a flexible label system called Tags to allow operator to rapidly To add a new tag, click ‘Add Tag’ tagplus from the Tags
label and refer to groups of devices within the platform. One use case for this feature is to Manager.
enable monitoring of high-risk users or devices such as departing employees or key assets.
When creating a new tag, a description can be added
Select Tags from the Main Menu. A tags manager dialog window will open displaying all current to help identify the reason for the tag. Selecting a color
tags for your network. To pivot to Explore Tags, click the link icon. assists identify the tag when assigned to a device. Click
Save.

The new Tag will appear on the Tags Manager dialog

window.

To review a tag, click on it within Tags Manager. 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. See Commonly Applied Tags for an explanation
of commonly applied tags and their purpose.

To add an individual device to a tag, select the device in the main Threat Visualizer, pull up the
Tags menu again and new buttons appear allowing you to add the device to the tag. In some
cases you can also add a user to the tag.

All existing tagged devices can be jumped to by clicking upon them; the list of tags can be
edited by the buttons at the top of the UI canvas.

63
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
The following tags are commonly used within the Darktrace platform: ‘similar devices’. This tag is applied by the system and not controlled
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 an Antigena model (excludes Compliance

Active Threat External DNS Device has performed an external DNS connection.
models) with a breach score greater than 25% in the past two hours.

Device has authenticated using a key user account (requires Devices within IP ranges that have no tracking will be tagged
Key User No Device Tracking (requires configuration of the corresponding model). Devices with this
configuration of key users in the corresponding model).
tag will 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 has been identified to relay local DHCP requests to a DHCP Device was seen sending or receiving lots of email. Devices with this
DHCP Relay Mail Server tag will be excluded from models which look for unusual volumes of
server.
emails sent.

64
 Device Admin

TAG DESCRIPTION
VIEWING DEVICE ADMIN

A device is operating as a Windows Server Update Service (WSUS) / The device admin is an up-to-date and historical catalog of all devices ever seen on your
System Centre Configuration Manager (SCCM). A device with this tag network. The devices are by default sorted by when they were last seen. The device admin
is excluded from breaching on some common activity patterns such allows for both the bulk application of tags and the ability to change device types. Some
WSUS / SCCM as unusual internal data transfers to new devices. This tag should be examples of these include adding the tag “Microsoft Windows” to any device that meets certain
added automatically by the WSUS or SCCM Tag model but in some conditions, or changing all devices with hostnames starting with SEP to IP Phones.
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.

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.

65
 Subnet Admin

Users can search for Hostname: SEP and press + to add that query, and then add additional VIEWING SUBNET ADMIN
queries to narrow the results down based on any criteria including: Labels, Tags, Device Priority,
Device Types, Hostnames, IPs, Mac Addresses, Vendor (based on OUI of Mac Address), Subnet Admin can be accessed from the main menu under Admin.
Operating System, First Seen, and Last Seen.
The subnet admin provides a catalog of the current subnets being modeled on your environment.
To apply tags, simply click “Apply Tag” which will display all available Tags (for more information Every field is customizable, which allows for enrichment of investigations and usage of the tool.
on how to create tags, see Adding and Reviewing Tags) as well as a checkbox next to each
device. 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.

To apply the tag to all devices on the page, you can check the top checkbox; otherwise, you ο The location of the subnet can be changed by providing the latitude and longitude,
can simply check the checkboxes one by one. To remove tags, you can click the tag you would altering where the subnet is displayed on the home screen of the Threat Visualizer.
like and uncheck the box next to a box that is tagged.
ο The DHCP field is used to specify if the Darktrace system should expect to see DHCP.
Click the link icon to open the Threat Visualizer centered on the specific device.
ο 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.

66
Alerts on the Status Page

The System Status page contains detailed information about the health and scope of your Notifications of the same kind are grouped together - the list of associated alerts can be
Darktrace Enterprise Immune System deployment. Here, metrics on hardware utilization, expanded with the caret-right arrow icon.
throughput, software bundle versions, component health, and modeled devices can be
monitored.

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
significantly. Unhealthy deployments, such as those which are overloaded, observing far too
many connections for their specification or with unreachable probes or components, will not
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.
Alerts are listed from newest to oldest - the times shown can be toggled between UTC and
When changes or errors occur, a “System Alerts” notification will also appear in the bottom local time using the clock clock icon in the top left corner. Each alert has a severity associated,
left of the Threat Visualizer workspace, above the Threat Tray. This notification will open the indicated by the color of the left-hand bar and the exclamation-circle exclamation icon. Finally, the details section
System Alerts tab of directly. contains information about the event such as the subnet detected, the error experienced by
the component or the time that packet loss was detected. Hovering over the details will display
From the SaaS Console interface, the Status page is available from the sidebar (“ System the full text if not visible. Each system alert can be copied in full using the clipboard clipboard icon on
Status”). the left of the entry.

SYSTEM ALERTS

System alerts are notifications about changes to the scope or health of the overall Darktrace
deployment. For example, system alerts inform operators when new subnets are detected,
when a probe or component loses traffic or becomes unreachable, or when an SSL certificate
or internal domain are seen frequently enough to no longer be considered rare. Some alerts
are prompted by model breaches from the System model folder, so previously these models
would appear in the Threat Tray. ο The eye View button opens the Threat Visualizer on the system alert so further
investigation can be performed.

ο The check Acknowledge button acknowledges the alert and removes it from the list.

ο The check Acknowledge All button acknowledges all grouped alerts at once.

67
System Topology

DEPLOYMENT HEALTH LIST VIEW

This tab displays an overview of all masters, hardware probes and virtual probes connected In list view, instance health is shown by the colored line on the left of each row. Current
to the deployment. There are two views - project-diagram topology view and list list view - which can be utilization of key metrics - CPU, Load, Memory, Disk and Darkflow Queue - are displayed on the
toggled in the top left of the workspace. By default, the workspace will open in topology view. 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.
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.

The color of the instance label represents the overall health. For example, a vSensor with a
green label is operating well within its scope, and a master with a red label may be overloaded
on one or more key metrics.

68
HEALTH METRICS
In either view, clicking the name of a EIS master will open a “System Status” overview with ο The Advanced tab contains deployment version information, license expiry, and details
detailed graphs covering deployment health. For probes, a simple deployment overview is of internal domains and servers observed by the appliance.
displayed. The instance identifier, the IP and the type of instance are displayed in the top left.
Below this, the time the information was retrieved at is shown. ο The Probes tab lists all virtual and hardware probes associated with the instance under
review.

ο The SaaS tab lists the current status of all associated Cloud/SaaS Security 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.

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.

ο The Network Traffic tab includes last seen dates for major protocols, greater detail on
modeled devices, processed bandwidth and network interface load.

69
CHAPTER 3 - THE SAAS CONSOLE
Getting Started
THE SAAS CONSOLE 71
GETTING STARTED WITH THE SAAS CONSOLE 72
MAIN MENU 74
UNIVERSAL ELEMENTS 75

The Dashboard
THE DASHBOARD 75
USING THE THREAT TRAY 77
EVENTS TAB AND LOGS 78
OTHER MODEL BREACH TABS 79

Cyber AI Analyst
CYBER AI ANALYST FOR SAAS CLOUD 80
TRIGGERED AI ANALYST INVESTIGATIONS IN THE SAAS CONSOLE 82
SAAS AND CLOUD INCIDENTS 83

Profiles
USER PROFILES 84
The SaaS Console

INTRODUCTION ACCESS

Many organizations use SaaS (Software-as-a-Service) solutions as part of their everyday Where Darktrace is monitoring SaaS and Cloud environments and Antigena Email is monitoring
workflow for file storage, collaboration, and centralized access control, or Cloud solutions for your organizational email domains, the SaaS Console can be selected from the main menu
their virtualized infrastructure and R&D. In many of these solutions, user interactions take place of the Email Console. Pivot points to Antigena Email are also provided throughout the user
and organizational data is hosted in a third-party managed environment with a separate audit interface and the Email Console is available from the SaaS console menu for easy movement
log and security interface; keeping track of alerts and activity across multiple SaaS and Cloud between the interfaces.
environments can be a challenge for many security teams.
Organizations that use the Darktrace Enterprise Immune System for monitoring both network
traffic and SaaS and Cloud user activity 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 Security 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.

71
Getting Started with the SaaS Console

There are multiple entry points in the Darktrace SaaS Console through which analyst teams can PROFILES
begin seeing and reacting to identified alerts or incidents produced by Darktrace.
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 will only
be added to the profiles when activity is observed by the relevant Security Module. Profiles are
also grouped cross-platform where possible to give the fullest picture of user activity.
EXCLAMATION-TRIANGLE MODEL BREACHES
Operators are more likely to interact with individual profiles as part of an investigation workflow
A model is used to define a set of conditions which, when met, will alert the system to the or when seeking further information on a specific user or platform.
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’ anomaly The Profiles page can be accessed from the main menu or from the Number of Active Users
or multiple combinations of the two. The severity of a breach is calculated from the priority of statistic.
the device, the level of anomaly associated with the breach, the priority of the model and the
frequency of similar breaches.

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.

c AI ANALYST

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.

72
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 graph
acknowledge the model breaches. - 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.

73
Main Menu

HOME USER USER ADMIN

The dashboard provides a global map of all SaaS logins, important statistics about SaaS and User permissions can set access and view on a per-user basis. See Guide to User Privileges or
Cloud environments, and access to model breaches for triage and investigation. the Darktrace System Administration Guide for a full list of User Permissions.

c AI ANALYST USERS USER GROUPS

Cyber AI Analyst will review and investigate all Darktrace Model Breaches that occur on the Allows permissions to be controlled in groups which are then assigned to multiple users,
system as a starting point for its analysis process. It will then form Incidents - a collection of one instead of on a per-user basis.
or more related events - centered around a device or SaaS user.
COG SYSTEM CONFIG
ENVELOPE EMAIL CONSOLE
Provides all configuration settings for the Darktrace Threat Visualizer application including
Pivots to the Antigena Email interface for investigation and autonomous actions on your email Antigena settings and authentication for SaaS modules. Alerting options can be configured
domains. Please see the documentation on Antigena Email for more information. here.

PROFILES SYSTEM STATUS

The profiles page provides an overview of all SaaS and Cloud users detected by Darktrace, as System metrics such as ingested traffic quality, master/probe reachability, and protocols
well as real-time feeds of actions performed and source locations for activity. observed can be reviewed. The visible statistics on the Status page will depend on your
environment.
a ANTIGENA ACTIONS
COGS ACCOUNT SETTINGS
Presents currently active and expired actions taken by Antigena SaaS and allows the actions
schedule to be configured. Current and historic actions can be exported as a CSV. Refer to Change settings for the current account including changing password, enabling Accessibility
Reviewing Antigena Actions for more information. Mode or registering the Darktrace Mobile App.

SEARCH ADVANCED SEARCH

Opens the Advanced Search interface. Refer to the Darktrace Advanced Search introduction
for more information.

EXCLAMATION-TRIANGLE MODEL EDITOR

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.

74
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.
Three 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
ο The filter icon filter will filter all data by the platform or user specified. Filters can be 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 Actions (Antigena SaaS only) opens the Antigena Actions
can be applied at the user level (e.g., [email protected]) which will filter for their page.
accounts across multiple platforms, or platform-specific (e.g., “[email protected]
(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.
75
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.

76
Using the Threat Tray

On the left-hand side of the dashboard is the threat tray, DETAILS PANE
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

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

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

78
 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 Antigena Email is also monitoring the email environment, the email envelope icon
pivots to Antigena Email 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.

Please note, some buttons may not be visible due to user permissions.

The pane at the right of the log will always show further information about the action, breach,
IP or ASN selected:
The locations tab displays a global map of SaaS and Cloud activity for the user under
ο When a model breach is selected, the right pane can be toggled between the breach investigation from the start of the selected timeframe, grouped by the ASN that the activity is
summary and discussion, where comments on the breach can be made or reviewed. performed from. Lighter locations indicate sustained activity and darker locations are those
which are rare for the organization.
ο When an action (log entry) is selected, the right pane will display further metrics about
the activity. A small arrow beside a metric (sort-down) provides additional options such as The map can be toggled to show login events only using the slider in the top left.
filtering the logs by the selected metric (for example, by a source IP) or reviewing more
detailed information in Advanced Search. Clicking on any location marker will produce a pop-up with the associated IP addresses, the
ASN and the frequency at which the activities were performed. Within this information pop-up,
Any filters added via this method can be removed through the filter filter icon above the click the IP address or ASN to open an additional event log with events seen from that location
logs. within the timeframe selected. These events are restricted by user.

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

79
 Cyber AI Analyst for SaaS & Cloud

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.

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

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

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

83
 User Profiles

Finally, the right-hand panels will breakdown key elements of the event and the involved SaaS The profiles page lists all SaaS and Cloud users detected by Darktrace; only users that have
users; the data is specific to each event type. performed an action whilst Darktrace monitoring was enabled 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 Security 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.

ANTIGENA SAAS

Users currently being actioned by Antigena SaaS have a green bar beside their profile tile.

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

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

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 Antigena SaaS actions on
the user.

85
CHAPTER 4 - THE MODEL EDITOR
Using the Model Editor
THE MODEL EDITOR 87
MODEL EDITOR OVERVIEW 88

Understanding a Model
LOOKING AT A MODEL 90
COMPONENTS AND FILTERS 91
MODEL BREACH LOGIC 92
MODEL CONDITIONS AND SCORING 93
MODEL ACTIONS 94
MODEL DEFEATS 96
OTHER MODEL TABS 97

Making a New Model

CREATING A NEW MODEL 98
ADDING COMPONENTS TO A MODEL 99
ADDING FILTERS TO A MODEL COMPONENT 100
DEFINING MODEL COMPONENT BREACH CONDITIONS 103
TUNING MODEL SCORING 105
ADDING ACTIONS TO A NEW MODEL 105
TIPS FOR NEW MODEL MAKERS 107
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 and Security 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 Antigena framework. Creating custom models
can be a straightforward and powerful way to integrate Darktrace into your existing security
processes or replicate a SOC playbook.

87
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 priority,

by creation date or by last edited date. Searching for a
The editor is comprised of a list of current models (left) and a main workspace where model keyword or model title will filter the list of models and
logic can be reviewed and edited. If the editor is opened from an event log - such as a model folders to only those with a title that matches the search
breach log - the main workspace will be focused on the model. terms.

The home home button can be used to return to the main Threat Visualizer interface and the Clicking the name of a folder or the line beside a folder
log out button to exit the Threat Visualizer platform. The ellipsis-h more options button in the top will expand to show the models and subfolders it
right provides access to the legacy model editor, bulk model import and bulk model export contains. Clicking again will collapse the folder. The folder-tree
functionality. 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.

88
 BULK ACTIONS INDIVIDUAL MODELS

Certain settings can be changed across multiple models Beside each model in the list is an question-circle info icon. Clicking this icon will open a summary tooltip
at the same time using bulk actions. When one or more containing:
model is selected, a dropdown will appear where the
sort option was previously. ο The Folder(s) the model is in.

ο Clicking the check-circle tick icon that appears to the left ο The model title.
of the model name will select that model.
ο Tags applied to the model, if applicable.
ο Clicking the check-circle tick icon that appears to the left
of a folder name will select all models contained ο The model priority.
within.
ο Actions in response to a breach.
ο Clicking the circle circle icon at the top left of the
list below ‘Folders’ will select all models. ο A Model description, where available.

The following options are available for bulk edit: ο Last edited date.

ο Model Priority The tooltip can be useful to quickly review a list of models in a folder before selecting one to
duplicate for editing purposes.
ο Active status

ο Auto Updates

ο Auto Suppression

ο Automatic Antigena

The purpose of these settings will be covered in more detail as we proceed through the model
editor overview.

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

89
Looking at a Model

For this example, we will look at a version of the “Anomalous Connection / 1 GiB Outbound” ο Auto Suppress: Determines whether this model will be automatically suppressed if it
model. Clicking on the name of any model will open the model overview on the right. 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
Please note, as Darktrace models are tuned and updated with high frequency by a specialized onward it will generate at most one breach per week for any given device and the same
analyst team, the versions of the model here may not correspond with the versions in your breach conditions. Recommended for most models.
environment. These models are only used for example purposes and the concepts apply to
any model - custom or default - which you may encounter. BREACH LOGIC TAB

MAIN OVERVIEW The first tab of the model overview contains a summary of the model logic. Models are
constructed from components - a series of logical statements evaluated against a connection,
At the top of the overview is the folder, the model name and any tags applied. Underneath this event or device.
is a description of the behavior the model is targeting and a potential action to take in response
to a model breach. A model may have more than one component. The dropdown indicates the relationship
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.

A Target Score is Reached

In this mode, components are assigned a positive or negative weighting and a target score
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
There are three toggles: 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
ο Active: Determines whether the model is active or not. Allows the user to turn a model components.
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.

90
Components and Filters

COMPONENTS FILTERS

Components are made up of metrics and filters. Each component looks at exactly one metric, The number of filters applied to the metric is also listed - click the component line to expand
filtered with zero or more filters. The metric is the main behavior, event, or condition that defines the filters.
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 actions that have taken place.
Here, there are three filters applied to the External Data Transfer: the data transfer must be
outbound, it must be to the same IP and it must not be to an address in the Multicast network
range.

In this example, the metric is “External Data Transfer (Client)” and the activity must meet the
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
summarized in this way to give a quick understanding of the type of activity that it is looking for.

91
Model Breach Logic

BREACH CONDITIONS

Each filter is assigned an alphabetical reference which is used to define the breach conditions.
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
three filter conditions must be met for the component to evaluate as true - and therefore the
breach conditions are represented as “A & D & E”.

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

For example, the “Active Remote Desktop Tunnel” model has “Active Connections” components Display fields are extra filters which do not have an impact on the component logic. Instead,
where the filters correspond to a selection of ports. Each filter in this case reflects a slightly they are used to include additional information in the model breach alert or breach log entry
different connection scenario and consequently, multiple combinations of these filters can when a component breaches. For example, adding a display field of “Source Port” will result
trigger a breach. in the port number that the breaching connection originated from being included in the log.

Where a component has multiple lines in the breach conditions, these should be treated as
an ‘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 logic must be satisfied.

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.

92
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
When true, components must be triggered in order from top to bottom. Components can be to create a model breach.
rearranged by clicking and dragging.
Target Score must be reached within the following seconds
All components must be breached within the following seconds
A limit on the time within which enough components must trigger to reach the target score, so
A limit on the time within which all components must trigger for the model to breach overall. that the model may breach overall.

All components must share endpoints All components must share endpoints

Requires components to be triggered by the same destination endpoint for the overall model 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. to breach. This option will not be displayed if there is only one component in the model.

93
 Model Actions

SCORE MODULATION Model actions are system actions which can be triggered in response to a model breaching.

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.

For other behavior types repetition makes the activity potentially more serious. Selecting a GENERATE MODEL BREACH (+ BREACH)
modulation curve will determine how the scoring of repeated breaches for a given device
should be adjusted. 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
is desirable to alert Threat Visualizer users to the activity detected. Where a model is used
for identification purposes - for example to tag a device that exhibits specific, non-malicious
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.

94
ANTIGENA (+ ANTIGENA) DEVICE TYPE (+ DEVICE TYPE)

Antigena is the Cyber AI response framework that takes autonomous actions in response to Darktrace detects device types automatically and assigns a most likely type based upon device
potentially malicious activity. Default Antigena network actions are triggered with meta-models activity and traffic analysis. Device types can be overridden on the Device Admin page or via
which look for the presence of one or more Antigena tags on a model breaching device. the API. Models can also reassign device types as an action. Instead of setting device types
Antigena response can also be added directly to a model with the ‘Antigena’ action. Inhibitors manually to match asset registers, a model can be configured to match a hostname convention
- response actions - can be selected for each Antigena type enabled on the deployment. and assign device types accordingly. The additional benefit of a model is that new devices
Inhibitors can be automatic, where Antigena selects the most appropriate action at the time, will be assigned automatically as they appear and trigger a breach, reducing the amount of
or pre-defined from the list of options. By default, inhibitors will be active for one hour (3600 repeated manual configuration required.
seconds).
MODEL
Where Automatic Antigena is disabled, a breach of this model will always ask for confirmation
before taking an action - regardless of the global state. When enabled, a response will be The Model action is a default action applied to all models - it defines the wait time before the
taken automatically unless confirmation for actions is required globally. model can breach again.

Optionally, a threshold can be defined which restricts Antigena response to 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 Antigena Threshold therefore sets the lowest breach score above which
Antigena 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.

TAG DEVICE (+ TAG DEVICE)

A model can add a tag to a device on breach. This can be particularly useful where models are
used to profile a device or to mark a device as high risk due to its behavior. Tags can be given
an optional expiry date; a device can therefore be added to a ‘risk pool’ for a set amount of
time in response to a model breach, and automatically leave it after a set period such as two
weeks.

95
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 to subset of devices or activity from triggering a breach.
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 updates. Defeats can also be used to limit the scope of a model - this is a very powerful tool to tailor
models to your environment but must be carefully executed to avoid over-limiting. For example,
Defeat conditions offer more specificity than device-based exclusions or restrictions and can adding the following defeat would restrict the model to only breach when the device has the
also target a large range of devices by characteristics like device type or hostname. Defeats File Server tag:
can be a useful tool to tune existing models to suit your environment as your deployment
develops, whilst also leveraging the expertise of the Darktrace analyst team as they update [Tagged internal source] [does not have tag] [File Server]
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.

Bulk Editing Defeats

In contrast to components, no defeats can evaluate as true for the model to breach - each
defeat should be considered as a series of “AND NOT” logic lines against the whole model. Defeats can be downloaded and edited as a .csv file, then re-uploaded to the model. This can
Where the model is a checklist, the overall logic can be thought of like: 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 name] [matches regular expression] [(u-infra-)[0-9]+]

96
Other Model Tabs

MODEL BREACHES each row corresponds to a specific device. The type of devices breaching the model are also
summarized in the top left. Each device is identified by the hostname, IP and/or MAC address
The Model Breaches tab displays a graph of breaches for the selected model over the given where available. On the right, the number of breaches and the time of the last breach are
timeframe - by default, two weeks are displayed. The time window covered by the graph displayed. Clicking the number of breaches opens a new window or tab with a Breach Log for
can be adjusted in the bottom right and can return up one year of model breach data (where each event.
available). Acknowledged breaches can be displayed or hidden with the “Show Acknowledged
Breaches” toggle. 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 “Include” list.
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 ο In the second mode, all devices apart from those explicitly listed will be treated as
the timeframe is displayed as a red line. Grey, vertical lines indicate a that the model was ignored. This is an “Exclude” list.
edited, and the logic potentially altered.
Only one mode can be selected.
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
“Remove” button.

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

98
Adding Components to a Model

BREACH LOGIC before the component will trigger. A zero in this field means any number of times. The default
component identifies at least one connection in 60 minutes.
The breach logic is the most important part of the model. The components and filters that make
up the breach logic define the activity the model is looking for. Each model has one or more The frequency and the time period can be altered to identify activity over a shorter or longer
components - types of activity to detect - which are controlled with filters to limit the eligible period. Other metrics can be selected for evaluation - click “Connections” to open a dropdown
connections or activity that could trigger a model breach. 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 security
modules providing data.

At the right of the ‘>’ symbol, enter the number of times the filtered metric should be seen

99
 Adding Filters to a Model

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 user
new model. involved, the SaaS platform, the geographic location of the action, etc.

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

100
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]
101
 OTHER FILTERS

HAS TAG / DOES NOT HAVE TAG 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
For tagged internal sources or destinations, allows the tag to be selected from a list. “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.
Example Breach Conditions

[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]

102
Defining Model Component Breach Conditions

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

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.

Filters:
Breach conditions connect filters together in logical sequences. Each filter has an alphabetical
reference which corresponds to a ‘bubble’ in the conditions. When a bubble is clicked on, it A - [Day of the Week] [is] [Sunday]
becomes highlighted and is now a required condition for the component to breach.
B - [Proxied Connection] [is] [False]
Multiple required components should be thought of in an ‘AND’ relationship.
C - [Tagged Internal Source] [does not have tag] [Admin]
WORKED EXAMPLE
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.

103
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.
104
Tuning Model Scoring Adding Actions to a New Model

SCORE MODULATION MODEL ACTIONS

Score modulation controls how the model score should change as the model breaches over The purpose of each model action was covered in further detail in Model Actions. A model can
time for a given device. There are four configuration options. trigger more than one action in response to a breach. Here, it is important to consider the most
relevant set of actions for the behavior targeted by the model.
ο Decreasing: As a device keeps triggering the same model, the threat score of the
breach will lower over time. If the model is looking for malicious activity that requires analyst intervention - triggering an
alert output is a reasonable response. However, for a model identifying all Office 365 admin
ο Increasing: The more a model fires, the higher the threat score for the device. 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
ο Stable: The Threat score will remain the same no matter how often a device triggers a threat score.
breach of this model.
The Model action is default for all models. This creates an event in the device’s event log
ο Increase then Decrease: Initially the threat score will increase but will reduce over time without creating an alert or model breach in the threat tray.
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.

105
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 an Antigena action. See Antigena Models and Actions for more
than if the priority was lower. 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

106
 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 you ο Think about the connection direction for the model you are creating. Are you only
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.

107
CHAPTER 5 - DARKTRACE ANTIGENA
Universal Antigena Elements
WHAT IS DARKTRACE ANTIGENA? 109
REVIEWING ANTIGENA ACTIONS 110
UNDERSTANDING THE ANTIGENA ACTIONS PAGE 111
ANTIGENA MODELS AND ACTIONS 113
ANTIGENA DEPLOYMENT MODES 114

Antigena SaaS
ENABLING ANTIGENA SAAS 117
MANUAL ANTIGENA SAAS ACTIONS 118
ANTIGENA SAAS INHIBITORS 119
MAKING USERS IMMUNE TO ANTIGENA SAAS ACTIONS 120

Antigena Network
ANTIGENA NETWORK MODELS 121
ANTIGENA NETWORK TAGS 122
ANTIGENA NETWORK INHIBITORS 124
WORKFLOW FOR REVIEWING ANTIGENA ACTIONS 125
ANTIGENA NETWORK DEPLOYMENT SCENARIOS 126
What is Darktrace Antigena?

DARKTRACE CYBER AI AND THE ENTERPRISE IMMUNE SYSTEM ANTIGENA EMAIL

The Darktrace Antigena framework leverages the power of the ‘pattern of life’ developed Darktrace Antigena Email represents a powerful expansion of Darktrace Antigena’s autonomous,
across the platform to respond, contain and neutralize emerging threats across the entire responsive capabilities into the email domain. Complex patterns of life for individual senders,
digital estate. With its unique understanding of “normal” for each user, device, and component, recipients, groups and correspondents are developed and used to even the subtlest threats
each autonomous action is targeted and proportionate - disruption to user workflow is minimal. entering via the inbox. The Antigena Email component is available for Gmail, Microsoft 365,
The Cyber AI platform currently offers three Antigena components - Antigena Network, Hybrid and On-Premises Microsoft Exchange environments. It can be deployed standalone,
Antigena Email and Antigena SaaS - which extend autonomous response to different areas of with one or more Darktrace SaaS modules or integrated with an Enterprise Immune System
the enterprise. deployment.

Whilst the Enterprise Immune System and wider Cyber AI platform provide the ‘pattern of life’ A fully comprehensive user guide for the Antigena Email system is made available separately.
to intelligently identify threats, the Antigena framework places the tools in your hands to action
and remediate those threats - autonomously, or with human oversight. Each component offers ANTIGENA SAAS
a combination of autonomous, semi-autonomous, manual and triggered actions. The Antigena
framework works with models – when a model breach occurs, the system can be configured to Antigena SaaS is an exciting new extension to the Cyber AI framework. Where anomalous
take a range of automatic actions in response or recommend actions for human confirmation or behavior in a third-party SaaS platform begins to escalate, Darktrace SaaS and Cloud Security
later review. A range of options exist within the platform to configure the operation of Antigena Modules can step in and utilize access policies and administrative tools to control the account
and tailor it to individual requirements. and sever the malicious actor’s access. The suite of actions differs between each platform -
autonomous response is currently available for the Office 365 and Zoom modules and will be
ANTIGENA NETWORK continually expanded over future software updates.

The Antigena Network component applies the Cyber AI framework to physical and cloud network
devices by controlling connectivity. This control ranges from interrupting communications
between distinct endpoint/port combinations up to complete quarantine - actions are
proportional to threat and may be escalated if granular blocks are not sufficient. Response can
be performed through integration with a number of popular firewalls 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.

109
Reviewing Antigena Actions

THE ANTIGENA ACTIONS PAGE

The Antigena Actions window lists all current and expired Antigena Actions. Actions from
Antigena Network and Antigena SaaS will appear in this window with each Antigena component
in a new tab. The types of action shown will differ depending on where the Antigena Actions
page was accessed from and which Antigena components are installed on the system.

Antigena Actions is only available to users with the Antigena permission.

Threat Visualizer OVERVIEW

In the Threat Visualizer interface, Antigena Actions is accessible from the main menu (Antigena The page is broken down into sections reflecting the status of the action and optional filters.
Actions) or filtered on a specific device from the a Antigena Actions icon in the Omnisearch
bar. Pending Actions

Indicates Antigena Actions that have not yet been approved by a human operator.

When there are pending Antigena Network or SaaS actions, a notification will appear above
the threat tray in the Threat Visualizer. A notification will also appear in the SaaS console threat
tray for pending SaaS actions only.

Active Actions

Displays current Antigena Actions which are in place and have not yet expired.

Cleared Actions

Lists all Antigena actions that were manually cleared by an operator. Clear will inform Antigena
to stop controlling the device or user and suppress the combination of Antigena Action and
A new window will open on the dashboard. Breach Condition for the time period that the clear action was performed for.

SaaS Console Expired Actions

From the SaaS Console interface, Antigena Actions is available from the sidebar (“a Antigena Includes all previous Antigena activity for devices and users in your environment. Actions can
Actions icon”). In this interface, only Antigena SaaS actions will be visible. be manually extended if desired.

The Antigena Actions page will open in the main workspace.

110
Understanding the Antigena Actions Page

FILTERING THE ACTIONS PAGE REVIEWING A SINGLE ACTION

The first section is a filter to reduce the visible actions. Filtering can be done by action type, by
device, by model, or by status.

Blocked

For Antigena Network actions, this status is represented by the “Blocked” column. Where
“Blocked” : “Yes”, this means Antigena 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 Antigena responded, or it can refer to subsequent connections that matched the criteria From left to right, each entry on the Antigena Actions page contains the following:
for blocking. In some cases, Antigena Network could identify a suspicious connection, block
any future connections, but no subsequent connections actually occur - here, "“Blocked”" ο A device or user under Antigena control
would be “No”. Setting the “Blocked” filter to “Yes” will only display actions where Antigena
Network actively interfered with a connection. ο A summary of the action taking place

Applied ο The start and expiration time of the action.

For Antigena SaaS actions, the status is given by the “Applied” and “Current Status” columns. ο The action status.
Where “Applied” : “Yes”, this means Antigena SaaS successfully performed the action - such
as a forced logout or an IP block. If the status is “No”, the Current Status column will give more ο The model that triggered the action, if applicable.
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 or because the user is marked ο Controls to extend, activate, reactive or clear the action.
as immune at the configuration level. Setting the “Applied” filter to “Yes” will only display
actions where Antigena SaaS successfully actioned the user. Device

In the Threat Visualizer, hovering over the name of the device or SaaS user will show a summary.

Clicking the name will center the visualizer on the device. Clicking the name of a SaaS user
from the SaaS Console will open their profile.

111
Action Summary Action Status

The summary states the type of action and the conditions, such as the IP or port involved. For For Antigena Network actions, this status represents whether the action prevented any further
example, blocking outgoing connections to a specific external IP on port 443, invoking a block connections. If the status is “Yes”, it becomes clickable and will open an event log around the
through a firewall or blocking a SaaS user from logging in from a specific IP. time of the blocked connections so the action and preceding events can be reviewed.

For Antigena SaaS, the status represents whether the action could be successfully applied and
its last known state.

Model

In the Threat Visualizer, clicking the name of the model that triggered the breach will open
a Breach log for the model. In the SaaS console, clicking the model will open the breach
investigation overlay centered on the breach.

In the Threat Visualizer, clicking on the action summary for Antigena Network actions will open For Antigena SaaS, if the action was triggered manually, the user who triggered it will be
an event log of blocked connections. reported here.

Duration (Start/End)

The default action duration is set in the model that triggered the action. For Antigena SaaS, 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. Extend, Activate, Reactivate, Clear

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 Antigena to stop
controlling the device and suppress the combination of Antigena Action and Breach Condition
for the time period that the clear action was performed for.
Where Antigena 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 These states were also covered in Reviewing Antigena Actions.
repeated is defined in the configuration settings.

112
Antigena Models and Actions

Darktrace models are a series of logical statements and conditions which, if met, trigger an Antigena responses are described as ‘inhibitors’ as they inhibit anomalous behavior. Full details
alert or action; models are primarily used to identify and alert on anomalous and potentially of the inhibitors available are included in the documentation for each Antigena component.
malicious behavior. The models framework leverages both the underlying ‘pattern of life’
detection and outputs from Darktrace Deep Packet Inspection and Security Modules. Open a model with Antigena capabilities or add the ‘Antigena’ action to an existing model to
review the following settings. Some settings may not be visible if the Antigena component is
Antigena takes action by monitoring model breaches and connectivity for indications of not present in your environment.
potentially malicious activity or significant anomalies that deviate from the ‘pattern of life’. When
Antigena Network or Antigena SaaS are enabled in your environment, the models used by Network Inhibitors
Antigena will become visible in the Model Editor. This dropdown selects the response that Antigena
Network should take if this model breaches and the
ANTIGENA MODELS Antigena Threshold value is met.

Some Antigena models are what are known as meta-models - models which use other models Full details of Antigena Network inhibitors are available
breaching as part of their logic. For example, the model “Antigena Large Data Volume in Antigena Network Inhibitors.
Outbound Block” (Antigena > Network > Insider Threat) looks for model breaches with a score
over 20% that refer to large outbound data transfers. When one of these models breaches - SaaS Inhibitors
such as the “Anomalous Connection / Data Sent to Rare Domain” model - Antigena Network
will observe the breach, trigger the “Antigena Large Data Volume Outbound Block” model Sets one or more responses that Antigena SaaS should
and take an automatic action against the device transferring the data. take if this model breaches and the Antigena Threshold
value is met. Multiple dropdowns can be added.
Other Antigena models take action directly in response to specific criteria. For example, the
model “Antigena FTP Block” (Antigena > Network > Compliance) looks for outbound FTP Each SaaS platform is different; the same capabilities
transfers over 1 MB. If a device is observed making these insecure transfers, Antigena Network may not be available to Antigena SaaS from one
will block matching connections for 1 hour. platform to the next. To ensure an action is taken on
every applicable platform, more than one can be
If the “Generate Model Breach” action is set on an Antigena model then, like a standard model, specified. Once selected, the inhibitor will display the
it will create model breaches that can be seen in the Threat Tray of the Threat Visualizer or the platforms it is applicable to.
SaaS Console.
Full details of Antigena SaaS inhibitors are available in
ANTIGENA RESPONSE IN THE MODEL EDITOR Antigena SaaS Inhibitors.

Models can take a series of actions in response to breaching such as triggering an alert, raising Automatic Antigena
the priority of a device or adding a tag. When Antigena is enabled on a deployment, the
additional Antigena action becomes available. This Antigena action is already used by the The automatic toggle controls whether the model can
Antigena models described above but can also be added directly to custom models.

113
 Antigena Deployment Modes

take autonomous actions. DEPLOYMENT MODES

If the model breaches when the Antigena Schedule (See Antigena Deployment Modes) is in Antigena Network and Antigena SaaS can be deployed in two distinct ways; Human
the “Use Model Setting” state and Automatic Antigena is enabled, an action will be taken. If Confirmation Mode and Active Mode. In Human Confirmation Mode, Antigena will request
disabled, or the Antigena Schedule is in the “Require Confirmation” state, human approval will approval from a human operator before taking any action. In Active Mode, autonomous actions
be required for the action to proceed. are taken without human intervention. For many organizations, the end goal of an Antigena
Network or SaaS deployment is some level of Active Mode, whether applied to select models,
Antigena Threshold select times of the day, or across all devices and use cases.

This field sets the model breach score that must be achieved to trigger the action. Antigena Network and SaaS Actions can be configured to fit a weekly/hourly schedule. Human
Confirmation Mode can be activated during business hours and deactivated when personnel
Antigena Duration are no longer in the office, ensuring autonomous actions can be taken when an operator is
not available to approve them. Response mode can be tailored by hour and day so weekend
This setting specifies how long in seconds the action should last for. The default is 3600 (1 hour). periods are protected. Similarly, Antigena actions can be disabled entirely during business
hours if desired.

The Antigena Actions weekly schedule is located on the Antigena Actions page in the Settings
tab. It is currently available from the Threat Visualizer only. The grid represents seven days,
comprised of 24 hours. Each block defines when Antigena 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 Do Nothing.

114
Configuration is set on one, shared master layout. The schedule replaces ‘Always Require HUMAN CONFIRMATION MODE
Confirmation’, previously set on the System Config page.
On initial deployment, it is recommended that Antigena be configured in Human Confirmation
Mode. In this mode, Antigena will recommend actions but will not perform them unless a
human operator gives confirmation. Reviewing the actions Antigena recommends in Human
Confirmation Mode will build familiarity and confidence in the kind of autonomous responses
Antigena will take and when they are appropriate. Actions may be ‘activated’ in the Antigena
Actions page in the Darktrace Threat Visualizer or the SaaS console and on the Antigena tab
in the Darktrace mobile app.

Human Confirmation mode can be deployed in two different ways.

GLOBAL

In this mode, Antigena will require an operator to confirm before taking any actions, regardless
Exceptions of whether the individual model breaching has autonomous actions enabled.

ο Manually created actions, such as Antigena SaaS actions, are not subject to the To enable global Human Confirmation Mode, navigate to the Antigena Actions page. In the
schedule as they have been deliberately taken by a human operator. These actions will Settings tab, add periods of Require Human Confirmation to the Antigena weekly schedule.
not require confirmation and will occur even during periods of ‘Do Nothing’. Click in one of the hourly blocks and select Human Confirmation. Repeat for all desired hours.
Alternatively, select the Require Confirmation preset from the dropdown or click the icon
ο Actions reactivated or extended manually will also not be subject to the schedule as beside each day to fill all boxes with the setting, then refine as desired.
they have been deliberately taken by a human operator.
If you wish Antigena to be disabled outside of these hours, select Do Nothing for these
ο Actions created by Antigena-enabled endpoints on the Watched Domains will be time periods. If Antigena is in passive mode, grid settings will have no impact on Antigena
automatically taken regardless of mode or device tags. behavior.

PER-MODEL

Human Confirmation can be configured on a model-by-model basis, where Antigena takes

some actions autonomously but seeks operator confirmation for specific cases. Models
intended for human oversight must be modified in the Model Editor to ensure confirmation will
be requested.

To enable Human Confirmation Mode on select models, access the model editor and locate
the models you wish to edit. Click on the left of the model name in the list to select it, or select
all desired models within a folder. At the top of the list, click the ‘# Selected’ dropdown and
choose Automatic Antigena > False. This will place all selected models into confirmation mode.
115
After editing this setting for all required models, navigate to the Antigena Actions page. In behavior.
the Settings tab, add periods of ‘Use Model Setting’ mode to the Antigena Network weekly
schedule. Click in one of the hourly blocks and select the Use Model Setting option. Repeat PER-MODEL
for all desired 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. For each model you wish to remain in Human Confirmation Mode, open the Model Editor and
ensure that Antigena actions are not automatic and require confirmation. Repeat this for each
If you wish Antigena to be disabled outside of these hours, select Do Nothing for these model intended for Human Confirmation Mode. Additionally, check that no models intended
time periods. If Antigena is in passive mode, grid settings will have no impact on Antigena for Active Mode have automatic Antigena actions disabled.
behavior.
Navigate to the Antigena Actions page. In the Settings tab, add periods of ‘Use Model Setting’
ACTIVE MODE mode to the Antigena Network weekly schedule. Click in one of the hourly blocks and select
‘Use Model Setting’. Repeat for all desired hours. Alternatively select the Require Confirmation
When you are happy with the actions that Antigena Network or Antigena SaaS recommends, preset from the dropdown or click the icon beside each day to fill all boxes with the setting,
enabling Active Mode for at least a select number of models should be considered. As both then refine as desired.
Antigena SaaS and Antigena Network deployments are fully customizable, a combination
of Human Confirmation mode and Active mode responses can be implemented with fully If you wish Antigena to be disabled outside of these hours, select ‘Do Nothing’ for these
autonomous response slowly expanded as Antigena is tuned to the environment. time periods. If Antigena is in passive mode, grid settings will have no impact on Antigena
behavior.
The default setting for new deployments is all hourly blocks in active mode.

GLOBAL

To enable global 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 ‘Use Model Setting’. Repeat for all desired 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.

If one or more models have autonomous actions disabled, Antigena will still ask for confirmation
before taking the action.

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

116
Enabling Antigena SaaS

Antigena SaaS is an exciting new extension to the Cyber AI framework. By learning a sense WORKFLOW
of ‘self’ for your entire workforce, the Enterprise Immune System detects abnormal use of
SaaS credentials and malicious insiders in seconds. This unique self-learning approach The following steps are required to enable Antigena SaaS actions.
enables security teams to identify and contain even the most sophisticated threats in SaaS
environments and beyond. 1. Ensure that an Antigena SaaS license is installed in your Threat Visualizer environment.

Where anomalous behavior in a third-party SaaS platform begins to escalate, Darktrace SaaS 2. Check the level of permissions granted to the Security Module that has been licensed.
and Cloud Security Modules can step in and utilize access policies and administrative tools for actions If required, re-authorize the module with higher permissions to upgrade it
to control the account and sever the malicious actor’s access. Autonomous actions currently to Antigena level.
available include IP blocking, forcing a user logout and disabling a user account for a short
duration. Operators investigating unusual SaaS activity can also trigger actions directly from The permissions level is granted when the app is authorized. Modules authorized
the SaaS Console, or clear and extend those already in place. before Darktrace v5 or authorized solely for monitoring may require reauthorization to
begin taking actions.
The suite of actions differs between each SaaS and Cloud platform - full details are available in
Antigena SaaS Inhibitors. Autonomous response is currently available for the Office 365 and If you are not sure if reauthorization is necessary, consult the Antigena section of the
Zoom modules and will be continually expanded over future software updates. documentation for the module. More information is also available below in “Account
Permissions”.

3. Optionally configure immunity from actions for certain users and IP addresses. more
information can be found in Making Users Immune to Antigena SaaS Actions.

4. Finally, Darktrace recommends that new users of Antigena enable autonomous actions
at a later date, when they are more comfortable with Antigena functionality.

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

117
 Manual Antigena SaaS Actions

ACCOUNT PERMISSIONS Antigena SaaS can be manually performed on a user from the SaaS console or the Threat
Visualizer.
SaaS Modules can be authorized for monitoring, or for monitoring and Antigena actions. For
some modules, Antigena SaaS requires more permissions than initially granted for monitoring SaaS Console
in order to 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 Antigena permissions, the reauthorization
process will include additional prompts for Antigena permissions or provide alternative Users currently being actioned by Antigena SaaS have a green bar beside their profile tile.
authorization links. More information can be found in User Profiles as part of the SaaS console guide.

SaaS Modules operating with monitoring permissions may need to be reauthorized with Threat Visualizer
Antigena permissions before actions can be taken. Whether this is applicable for a SaaS
module will be described in the detailed module documentation. To perform an action on a user from the Threat Visualizer, search for the user in the omnisearch
bar and select them. From the device options in the omnisearch bar, click the a Antigena 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.

118
 Antigena SaaS Inhibitors

TRIGGERING AN ACTION Models can take a series of actions in response to breaching such as triggering an alert,
raising the priority of a device or adding a tag. When Antigena is enabled on a deployment,
There are three settings that must be set at a minimum - the SaaS Module intended to take the the additional Antigena action becomes available. When Antigena SaaS is enabled within
action, the desired action and the duration for that action. your Darktrace environment, it comes with a category of Antigena models already using the
Antigena action to perform responses.
The Actions available to take will differ between different SaaS platforms - a list is available in
Antigena SaaS Inhibitors. The Duration is the initial time the action should be applied for - one This action allows an operator to set one or more ‘inhibitors’ - actions to inhibit the behavior
off actions will be repeated for the length of the duration. that matches the model criteria. For Antigena SaaS, applicable inhibitors differ between SaaS
platforms. Models can therefore have multiple inhibitors set to ensure they can take an action
in every possible environment.
ο If the user has been seen on multiple platforms
where Antigena SaaS actions can be taken, the Antigena SaaS inhibitors can also be triggered manually.
Module field can be used to search for the SaaS
module intended to take the action. 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 Antigena SaaS are
ο If the user has been seen on only one platform eligible for actions. Immunity from actions is controlled on the System Config page.
where Antigena SaaS actions can be taken, the
Module field will be pre-populated with the Please see Making Users Immune to Antigena SaaS Actions for more detail.
SaaS module that can take an action.
INHIBITORS
ο If the user has not been seen on a platform
where Antigena SaaS actions can be taken APPLICABLE
INHIBITOR DESCRIPTION
the button will not appear and manual actions MODULES
cannot be performed. Prevents access to the account from an IP or IP range for the
Block IP(s) Office 365
duration set.
Some actions may have additional fields, such as
defining an IP to be blocked, which are also required. Disable Office 365,
Disables a user account for the duration set.
Complete any additional fields, then click Apply to User Zoom
trigger the action.
Forces the user to log out from the platform. This action is a
Force Office 365, one-off action, so will be repeated at the configured interval for
Logout Zoom the duration set. The default interval is 15 seconds and can be
altered by a member of Darktrace support if required.

119
Making Users Immune to Antigena SaaS Actions

All users are eligible for Antigena SaaS actions by default. Immunity from actions is controlled EXAMPLE CONFIGURATION
on the System Config page.
Immunity and Account Permissions are set for each account within a SaaS module. For example,
To make changes, access the System Config page from the main menu and select Modules an organization may have two Office 365 tenancies - Business and Development. For the
from the left-hand side. Under Cloud and SaaS Security, select the module you wish to change Office 365 module, they have two accounts which correspond to these two tenancies. These
and click on it to open the configuration window. 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 to
add Antigena Permissions and upgrade to the Account Permissions level to Antigena. Once
When a module has Account Permissions - Antigena, new settings will appear which control this is complete, immunity settings will appear against each account.
whether a user or an IP can be actioned by Antigena SaaS. 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.
To do this, it must be added to Immune IP Addresses for both accounts.
ο Immune Users are users which will not be actioned by Antigena SaaS, whether 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 SaaS platform, such as “Block IP”. This field will only appear if the
SaaS 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 SaaS platforms.

120
Antigena Network Models

Darktrace Antigena Network expands Cyber AI response to devices by severing network From the left-hand model list, select the Antigena > Network folder.
connections, restricting access and quarantining devices by limiting their outbound
connectivity. Actions can be taken when a device exhibits significantly anomalous behavior, In this folder, Antigena Network models are grouped into four categories: Compliance, External
when it contravenes a compliance policy, when a device attempts to access a specific watched Threat, Insider Threat and Significant Anomaly.
endpoint, or any other custom criteria defined in a model. Unlike anomaly level, which is
determined on behavior, risk profiles will vary across an organization’s network according to ο Models inside the Compliance folder are
business requirements. You may wish some devices and users to be exempt from Antigena linked to potential compliance breaches like
Actions, to restrict the actions to only match anomalies exhibiting certain behavior or apply unauthorized file storage and TOR usage.
actions automatically only at certain times of the day.
ο Models inside the External Threat folder
MODEL CATEGORIES contain behavioral elements suggestive of an
external threat.
Antigena Network responses are triggered by model breaches within the Threat Visualizer -
Antigena models look for specific behavior or for indicators triggered by other model breaches. ο Models inside the Internal Threat folder contain
Darktrace models are a series of logical statements and conditions which, if met, trigger an behavioral elements which suggest highly
alert or action; models are primarily used to identify and alert on anomalous and potentially unusual internal or lateral behavior.
malicious behavior. The models framework leverages both the underlying ‘pattern of life’
detection and outputs from Darktrace Deep Packet Inspection and Security Modules. ο The Significant Anomaly folder contains models
which are independent of attributable aspects,
When Antigena Network is enabled within your Darktrace environment, a new collection of but are consider significantly anomalous.
models will become available: Antigena > Network. This collection contains specific Antigena
Network models which are set to trigger on specific types of connection or activity and perform When a model breaches that would trigger an Antigena
different actions depending on the incident identified. Network action, the device is checked for the relevant
tag before the action is performed. For example, a
REVIEWING THE ANTIGENA NETWORK MODELS device performs unauthorized file transfer activity
which triggers a compliance breach. If the Antigena
Open the Model Editor. In the Threat Visualizer interface, the Model Editor is accessible from Compliance models are active, they will check that
the main menu under Models > Model Editor or from any breach log with the “ Click to view the device has either the Antigena Compliance or
model” button. Antigena All tags before the action is performed.

121
Antigena Network Tags

Darktrace Antigena 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 Antigena can take action in a highly targeted The Model Editor contains a series of models which apply tags automatically based on criteria.
manner, mitigating threats while avoiding over-reactions. Typically, a subset of all devices will
be deemed appropriate to place under Antigena control. Return to the model editor, but instead select the Tags > Antigena folder. Inside this folder
are models which correspond to each Antigena Network tag. These models are marked
Whether a device is eligible to be autonomously actioned by Antigena Network is defined by as “Requires Configuration”, meaning they are templates and must be modified to suit your
the tags applied to that device. There are five Antigena Network tags, corresponding to the environment before being enabled. The External Threat Tag model will now be used as an
model categories: 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 Antigena 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.

122
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
Antigena Network tagging model to slowly expand coverage across all subnets.

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 Antigena Network External Threat actions, following the example
given.

123
Antigena 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 Antigena is enabled on a deployment, the
additional Antigena action becomes available. When Antigena Network is enabled within Block all outgoing
your Darktrace environment, it comes with a category of Antigena models already using the All outgoing traffic from a device is blocked.
traffic
Antigena action.
Block all incoming
This action allows an operator to set an ‘inhibitor’ - an action to inhibit the behavior that matches All incoming traffic to a device is blocked.
traffic
the model criteria. Antigena Network has a specific set of inhibitors that can be selected.

INHIBITORS

INHIBITOR DESCRIPTION

This option allows Antigena 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 on port
Automatic
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.
Antigena Network will block the specific connection and all future
Block Matching connections that match the same criteria. For example, the FTP block
connections 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 of
transfers which Darktrace considers normal for that device. Any
life
unusual traffic (marked with an unusual message in Darktrace) is
blocked.
Group ‘pattern of life’ allows a device to make any connections and
Enforce group
data transfers that it or any of its peer group typically make. This
pattern of life
action is less strict than the individual ‘pattern of life’ enforcement.

Quarantine device All incoming and outgoing traffic from or to a device is blocked.

124
Workflow for Reviewing Antigena Actions

REVIEWING AND TUNING ANTIGENA NETWORK

When Antigena Network is first enabled, reviewing each Antigena action can be a useful way 6. Understand the conditions of the model that caused the Darktrace Model Breaches
of gaining confidence in the autonomous actions and locating any models which may require
further tuning. It is recommended an operator should review any currently active actions first. If you are not familiar with the conditions of the Darktrace Model Breach, you can review the
model logic by returning to the Model Editor from the main menu.
After reviewing an Antigena Action or after reviewing all Antigena Actions, you may wish to
adjust the parameters of the Antigena Models or tag membership. 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
Model Breach.
1. Identify an action
8. Consider the risk posed by removing the Antigena Action or by extending the Antigena
Open the Antigena Actions menu item and identify an action to investigate. Action

2. Understand the effect of the Antigena 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 Antigena Action in place.

To see specific connections that have been interfered with, click on the device name under ο If YES then consider the anomalous behavior that provoked the Antigena Action.
the device column.
Are you satisfied that the anomalous behavior reported by Darktrace is benign?
3. Understand the conditions of the model that caused the Antigena action
ο If YES then you may wish to remove the Antigena Action on the device. You can do this
If you are not familiar with the Antigena Model that caused this Action, click on the name of the by clicking the Clear button from the Antigena Actions Page.
model to launch the model editor entry.
After reviewing the Event Log you may wish to extend the Action for a period of time. (Note that
4. Review the event log for the action Antigena Actions will automatically extend if further anomalous activity is seen from the device).

To open the Event Log for the device from within the Antigena Actions page, click ‘true’ in the 9. Optionally consider whether the level of anomaly justified the specific Antigena Action
blocked column. placed on that device in the context of your business logic for that device

5. Identify any Darktrace Model Breaches that prompted the Antigena action

In the Event Viewer (opened in previous step) locate the Antigena Action.

Working down the event log, find Darktrace Alerts that may have prompted the Antigena
Action to occur.
125
Antigena Network Deployment Scenarios

TAILORING THE ANTIGENA NETWORK DEPLOYMENT Mode. The approaches below range from more noisy alerts and actions and less complex
implementation but further tuning needed, to more precise alerting and actions but increased
Tailoring Antigena Network responses to best fit the network environment can be approached complexity and lower future tuning needed.
from a number of different angles. Understanding how an Antigena Network action is triggered
on a specified device will ensure that only desired devices will be targeted for autonomous The scenarios below cover the recommended Antigena Tag to apply to the specified device
responses. When a device breaches a model contained within one of the Antigena Network types to produce different levels of configuration. In all cases, substitute ‘Any Client Device’ for
folders, Antigena Network will look for the corresponding tag on the device before responding. a specific IP range(s) as desired.
The ‘Antigena All’ tag allows Antigena to take action when any default Antigena model breaches,
regardless of subfolder. For instance, a model residing within the Antigena Compliance folder SCENARIO 1 - SIMPLE, MORE FREQUENT ALERTS
will only prompt an Antigena response if it is triggered by a device that either has the tag
‘Antigena Compliance’ or ‘Antigena All’. See the Antigena Network Models guide for more
information.

Default Antigena Network models will only fire on devices with one of the Antigena Network Antigena
Antigena Antigena Antigena
Antigena All Significant
tags applied. For custom models with Antigena responses enabled, it is recommended that the Anomaly
External Threat Insider Threat Compliance
model excludes devices without the appropriate tags. This can be achieved with the following
logic, modified as appropriate for the model target: Any Client device 

Tagged [Internal Source/Internal Destination] Has Tag [Antigena All/ Specific Servers
which do not interact with
Antigena Compliance/etc] the whole network

Client devices
DEPLOYMENT SCENARIOS tagged by specific role
(e.g. Sales, Finance)

Starting with one of the following initial deployment configurations - the initial configuration
should be selected to reflect the time constraints and risk appetite of the security team. Tailoring SCENARIO 2 -SIMPLE, LESS FREQUENT ALERTS
the initial configuration will require less model tuning as the deployment process progresses.

The three elements to take into consideration are complexity, tuning and noise. Noise refers Antigena
Antigena Antigena Antigena
Antigena All Significant
to the number of low-level, potentially false-positive alerts generated when Antigena has not Anomaly
External Threat Insider Threat Compliance

been tailored to the network environment. Noise can be reduced with tuning – a process of
reviewing and altering each model to closely fit the network which is performed after initial Any Client device  
deployment. Simple configurations can be implemented quickly but are not targeted, so will
produce more noise and require more tuning at a later date, whilst complex configurations Specific Servers
which do not interact with
require initial investment to tailor to the network environment but will require very little the whole network
refinement down the line. Client devices
tagged by specific role
(e.g. Sales, Finance)
Implementing one of the following options should ensure that 80% of Antigena tuning is taken
care of, therefore reducing the amount of time between initial deployment and enabling Active
126
SCENARIO 3 - MORE COMPLEX

Antigena
Antigena Antigena Antigena
Antigena All Significant
External Threat Insider Threat Compliance *
Anomaly

Any Client device    As appropriate

Specific Servers
which do not interact with  
the whole network

Client devices
tagged by specific role
(e.g. Sales, Finance)

ο Antigena Compliance - Enable Models on a case by case basis as appropriate for

organizational policies and the network environment.

SCENARIO 4 - MOST COMPLEX

Antigena
Antigena Antigena Antigena
Antigena All Significant
External Threat Insider Threat Compliance *
Anomaly

Any Client device As appropriate

Specific Servers
which do not interact with  
the whole network

Client devices
tagged by specific role As appropriate As appropriate As appropriate As appropriate As appropriate
(e.g. Sales, Finance)

ο Tag clients by role (e.g., IT, Sales, Finance) and apply Antigena Tags to the defined roles
as appropriate.

ο Antigena Compliance - Enable Models on a case by case basis as appropriate for

organizational policies and the network environment.

ο Antigena Compliance - Create models specific to your compliance policies.

127
CHAPTER 6 - THE MOBILE APP

Getting Started
REGISTERING THE APP 129

Cyber AI Analyst
AI ANALYST VIEW 130

Devices and Models

MODELS VIEW 132
DEVICES VIEW 133

Other Views and Settings

ANTIGENA VIEW 135
SUMMARY VIEW 136
CONFIG VIEW 136
Registering the App

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
above.
1. Navigate to Account Settings from the main
menu of the Threat Visualizer or SaaS Console. The app should now authenticate.

The ‘Register Mobile App’ option should now Move between the screens for a guide overlay
be available. Click ‘Register Mobile App’ to explaining the functionality.
reveal a QR code.
The guide can be re-enabled at any point from
the config page.

2. On your smartphone, open the appropriate app

store and search for Darktrace.

The Darktrace iOS app is available on the App

Store, and the Android app is available on
Google Play.

Download the Darktrace app.

129
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 Antigena
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 incident.
simple write up; users may wish to spend longer If another user has commented already, the icon
reviewing these incidents and underlying will appear with lines in the body. Submitted
events than they would breaches in the Models comments will appear in grey when pending
or Devices tab. Consequently, Cyber AI Analyst and in white once confirmed as received by the
will not automatically refresh the list of incidents. Darktrace appliance.

Incidents created by Cyber AI Analyst do not encompass ο Tap the pin icon to pin the incident to the top of the Cyber AI Analyst incident list; pinned
all model breaches on the network, only those deemed events will display a filled icon thumbtack. Pinned incidents will always appear at the top of the
particularly unusual or in need of further investigation. list and will persist until unpinned.
Users who wish to review all alerts raised by Darktrace
should also consult the Model or Device tabs. ο Tap ‘acknowledge’ or ‘acknowledge all’ to acknowledge the one or more underlying
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.
130
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 Antigena 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 Antigena actions triggered by the event will

also appear here.

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

132
 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
breach. Acknowledging a breach signals the Darktrace which may have multiple breach instances. At the top of
server which marks the breach as acknowledged, the the list are the current filtering preferences as defined
same as using the tick control in the breach log. If in 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
a pop-up with further information about the 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 this and trigger a manual update.
icon will open a Maps application at the derived
coordinates.

ο Any Antigena 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.

133
DEVICE ACTIVITY GRAPH DEVICE DETAILS

Tapping the graph icon above the number of breaches Tapping on a device breach will open the Device
will open the Device Activity graph. This displays all Details screen. This shows all the recent breaches for
breaches for the given device within the time frame the selected device (depending on filter options). For
defined in the cog Config. each breach instance, the triggering Model is listed.
There is one row per breach, so a Model may appear
ο The y axis represents the time frame selected multiple 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.

134
 Antigena View

BREACH DETAILS ANTIGENA

Tapping on a device within the Device Details screen The Antigena screen displays recent Antigena actions
opens a pop-up that allows you to ‘acknowledge’ the listed by category; Active, Pending, Cleared and
breach. Acknowledging a breach signals the Darktrace 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 Antigena.
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
Antigena.
ο The breach details reflects the contents of the
Model Breach Event Log in the main Threat Tap on an individual Antigena action to review details of
Visualizer. This gives details of the connections the device, the model that prompted the action and the
involved in the breach and any contextual timing of the Antigena action. Any decisions you make
information. will be mirrored in the Threat Visualizer.

ο Tap on any of the breach details to produce Swipe left on an Antigena Action to make changes. Two
a pop-up with further information about the options will appear:
connection or event.
ο Extend will lengthen the Antigena action on the
ο Any Antigena Actions related to the breach will device for the specified time.
appear in this list.
ο Activate will inform Antigena to start controlling
ο Tap the comment-alt icon to add a comment to the breach. If another user has commented already, the device with the action specified.
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. ο Clear will inform Antigena to stop controlling
the device and suppress the combination of
ο Tap the Antigena icon to review any current Antigena actions active against the device. Antigena Action and Breach Condition for the
time period that the clear action was performed
ο Long pressing on the device name will show a pop-up with all recent model breaches for.
by that device.
Tapping the desired option will provide time options
ο Tap the acknowledge button to acknowledge the breach. for how long the Antigena Action should be Extended,
Activated or Cleared 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.

135
Summary View Config View

SUMMARY CONFIG

The Summary screen mirrors the high-level summary The Config screen offers multiple filtering options that
information available on the home screen of the Threat 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 Antigena 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.

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

137
APPENDIX

Model Editor
MODEL EDITOR METRICS 139
Model Editor Metrics

The following metrics are commonly used in Darktrace Models. The available metrics will vary between deployment scenarios, such as environments where SaaS modules or ICS protocols are present.

METRIC DESCRIPTION

Active Connections The number of ongoing connections at any one time involving the device over a period of time

Active External
The number of ongoing connections at any one time between the device and the outside world over a period of time.
Connections

Active Internal
The number of ongoing connections at any one time between the device and other devices on the internal network.
Connections

Antigena Response A device triggered an Antigena Response

A boot event detected, but no recent activity was seen for the device in the 5 minutes beforehand Cross Device Model Breaches - Multiple network devices have
Boots
breached the same model in a pattern that is not common on the network. An example would be a network worm.

Broadcasts The number of data flows to an IP broadcast address.

When inoculation information is sent to the Darktrace appliance, a community inoculation notice will be generated if one of the IoCs has been seen historically on the
Community Inoculation
network.

Connection Spread The number of distinct IPs the device connects to.

The number of connections created involving the device over a period of time. The IP address, port and protocol define a connection. Every connection has an
originator (source) that creates the connection, and an endpoint (destination). Generally speaking, a connection can be between two internal machines, between a
Connections
machine and a public IP address, between a public IP address and an internal machine, or between a public IP address and another public IP address. In this context
device refers to only an internal device. (Darktrace does not consider www.google.com to be a device).

Connections to Closed
Number of TCP connections to a closed port (or failed connections where no response packets were seen)
Ports

Cross Device Model

Number of cross-device breaches that occur during the time frame.
Breaches

139
METRIC DESCRIPTION

Cryptocurrency Miner Cryptocurrency miner found communicating via the JSON-RPC protocol. Once identified, this will trigger periodically throughout the lifetime of the connection

Cryptocurrency Mining Cryptocurrency mining credentials seen. The message filter can be queried for the mining credential seen, usually either a wallet ID or email address, and the mining
Credential protocol detected.

Cryptocurrency Mining
Cryptocurrency mining pool server found serving work to miners. Once identified, this will trigger periodically throughout the lifetime of the connection
Pool Server

Cryptocurrency Possible
Possible mining found communicating via the JSON-RPC protocol. This will trigger periodically throughout the lifetime of the connection until it is confirmed as mining.
Mining

Customer Threat Indicator When third-party threat intelligence is ingested by the Darktrace appliance, this notice will be generated if one of the IoCs has been seen historically on the network.

Data Transfer The volume of data transferred by the device over a period of time.

Data Transfer (Client) Number of bytes transferred where the device initiated the connection (to any host).

Data Transfer (Server) Number of bytes transferred where the device received the connection (from any host).

A DCERPC protocol bind showing the requested service and SUCCESS or Error (raised on the response), commonly used in Windows networking and remote
DCE-RPC Bind
administration

DCE-RPC Request A DCERPC protocol Request with opnum 3 showing the requested operation (raised on the response)

Detects the Operating System in use based on flags and headers in the TCP packet, either because it is the first time Darktrace has detected it, or because it has
Detected Operating
been changed since Darktrace first detected it (e.g., a new OS has been installed on the device). The name of the Operating System can be queried using the
System
‘Message’ field filter.

Device Cluster Changes When a modeled device has changed behavior sufficiently, it will be moved to a different ‘cluster’ (group of similar devices).

140
METRIC DESCRIPTION

Device Cluster Outliers When a modelled device has changed behavior sufficiently for it to become (unusually) an outlier in its normal ‘cluster’ (group of similar devices).

DNS Requests The number of DNS requests (from unique source ports)

This alerts if a DNS server has been added or removed from the automatically managed internal list of DNS servers the Darktrace system tracks. This applies at
DNS Server Changes
system level, not at device level.

Dropped Packet Notices Used when the appliance is dropping packets. This applies at system level, not at device level. This could be caused by the capture card, the SPAN port or the TAP.

DynDNS DNS Requests A DNS request to a Dynamic DNS address provider (for example dyndns.org).

DynDNS HTTP Requests A HTTP request where the host is a Dynamic DNS address.

DynDNS SSL Requests An SSL request where the host (SNI field or Certificate Common Name) is a Dynamic DNS address.

Emails with Watched

Number of POP3/SMTP emails the device has received written in a character set from a watched list.
Character Sets

Detection that over 10% of packets are missing; this is obtained through TCP sequence analysis. The packets could be dropped on the appliance or at the switch
Excessive Capture Loss above the appliance. If there are no ‘Dropped Packet Notices’, then it is very likely that packets are being dropped before they reach the appliance. Split routing can
also cause this.

External Connection
Average duration of a connection between the device and the outside world over a period of time.
Duration

External Connection
The number of distinct IPs the device connects to in the outside world.
Spread

External Connections The number of connections between the device and the outside world over a period of time.

141
METRIC DESCRIPTION

External Connections to
The number of connections between the device and the outside world to closed ports over the time period.
Closed Ports

External Data Ratio The ratio between uploaded and downloaded data with external hosts. Presented as a percentage: 0% = all download, 50% = symmetric.

External Data Transfer The volume of data transferred between the device and the outside world over a period of time.

External Data Transfer

Number of bytes transferred where the device initiated the connection to an external host.
(Client)

External Data Transfer

Number of bytes transferred where the device received the connection from an external host.
(Server)

External Domains Pointing

Number of external domains found to be pointing to internal IP addresses.
to Internal IP

External Multicasts The number of multicasts the device has made to a globally routable IP over a period of time.

External Packets Number of packets sent or received externally.

External Proxy Servers The number of external proxy servers detected over a period of time.

The number of failed DNS lookups (NXDOMAIN DNS failures) made by the device over a period of time. NXDOMAIN is the response returned by the DNS server
Failed DNS Lookups following a DNS request for a non-existent Internet or Intranet domain name. This response is returned if the domain name cannot be resolved using DNS. You can
specify how many failed DNS lookups to look for, and a time period.

File Transfer Start - Exe Triggers when the start of a file transfer of .EXE files is seen.

File Transfers (EXE) The number of .EXE files transferred by the device over known protocols over a period of time. This is based on the detected file type, not on the server headers.

142
METRIC DESCRIPTION

File Transfers (Octet

The number of octet-stream file types transferred over known protocols over a period of time. This is based on the detected file type, not on the server headers.
Stream)

File Transfers (RAR) The number of RAR files detected in known protocols. This is based on the detected file type, not on the server headers.

File Transfers (Unknown

File download in known protocol which has an unknown, non-ascii type.
Binary)

The number of times the device has been seen repeatedly failing to login via FTP over a period of time. Repeatedly failing is defined as 20 rejected FTP logins within
FTP Bruteforces
15 minutes. This detects whether an FTP login has been successful or not.

FTP SITE EXECs The number of “SITE EXEC” responses seen.

Hostname Connections
The number of times a connection has been made to a hostname without a DNS lookup performed for it beforehand.
With No DNS Lookup

The number of files crossing the device (on HTTP/FTP/IRC/SMTP) with a file extension that does not match the MIME type (extracted from the header of the file). This
Incorrect File Types
works when filenames are visible, and is only active on DOS EXEC (Windows executable files such as .exe, .dll, .wat, .bin), RAR files and JAR files.

Inoculation Triggered if an IoC created by Darktrace Inoculation is seen on the network.

Internal Connection
Average duration of a connection between the device and other devices on the internal network over a period of time.
Duration

Internal Connection
The number of distinct IPs the device connects to inside the network.
Spread

Internal Connections The number of connections between the device and other devices on the internal network over a period of time.

Internal Connections to
The number of connections between the device and closed ports on other devices on the internal network over a period of time.
Closed Ports

143
METRIC DESCRIPTION

Internal Data Ratio The ratio between uploaded and downloaded data with internal hosts. Presented as a percentage. 0% = all download, 50% = symmetric.

Internal Data Transfer The volume of data transferred between the device and the internal network over a period of time.

Internal Data Transfer

Number of bytes transferred where the device initiated the connection to an internal host.
(Client)

Internal Data Transfer

Number of bytes transferred where the device received the connection from an internal host.
(Server)

The number of internal domain changes over a period of time. Local domains are domains with IP addresses from an internal IP address range. This metric fires if a
Internal Domain Changes private IP range domain server has been added or removed from the automatically managed internal list of the Darktrace system tracks. Darktrace learns about the
domains by looking at the DNS requests. This applies at system level, not at device level.

Internal Domains Pointing

Number of internal domains found to be pointing to IP addresses outside of the internal network.
to External IP

Internal Packets Number of packets sent or received internally.

Internal Proxy Servers The number of internal proxy servers detected over a period of time.

The number of invalid DNS hostnames over a period of time. Hostnames must be no longer than 22 characters in length. Valid characters are: a-z, 0-9, and ‘-’. A
hostname cannot have any spaces, nor can it start with a hyphen. Very often hostnames are longer than this in practice, particularly internal ones. Darktrace checks
Invalid DNS Hostnames
for invalid characters in the hostname and also for unreasonably long hostnames. If there is a binary character, the details are recorded (byte and byte position) for
displaying to the user.

The number of times over a period of time that an SSL certificate was compared against the Mozilla Certificate Authority list and did not validate. This usually occurs if
Invalid SSL Certificates
a certificate is self-signed or if intermediate certificates are missing (indicating a misconfigured website).

KERBEROS App Kerberos Application server request.

KERBEROS App Failure Kerberos Application server access error.

144
METRIC DESCRIPTION

Kerberos Login Failures The number of times over a period of time that the device has failed to log in using Kerberos. The username can be queried by using the ‘Message’ field filter.

Kerberos Logins The number of times over a period of time that the device has successfully logged in using Kerberos. The username can be queried by using the ‘Message’ field filter.

KERBEROS Ticket Number of Kerberos service ticket requests.

KERBEROS Ticket Failure A Kerberos error was seen when requesting a ticket, the details field will contain more info (e.g., “Ticket has expired”)

The number of link-local connections involving the device over a period of time. A local address is detected if the IPv6 address is fe80::/10 or the IPv4 Address is
Link-Local Connections
169.254.0.0/16.

Missing Notice Alerting that an expected regular event/behavior hasn’t occurred. This is more likely to occur in strongly regular environments like ICS/SCADA deployments.

Model A model has been breached, can create meta models based upon combinations of other breaches. Commonly used to implement Antigena models.

The number of times a Darktrace model has breached too many times over a period of time and has subsequently been deactivated. This metric operates at system
Models Over-Breaching
level.

Multicasts The number of times multicast traffic is observed over a period of time.

Multiple Concurrent A device is active with multiple IP’s at the same time. This is commonly the result of bad device tracking, if the device is not being tracked by MAC address via DHCP
Device Ips this can indicate Darktrace doesn’t have enough data to keep track of the devices effectively.

New Credential Usages Number of times that a login/authorization was detected on a device where the username had not been used that device before.

New Credential Use For

Number of times that a login/authorization was detected on where the username had not been used for the network before.
Network

145
METRIC DESCRIPTION

The number of new user agent strings that are observed on the device over a period of time. A new user agent is assigned a score (the percentage can be set using
New Device User Agents a Filter), based on how different it is both to the device’s previous user agents and to those of the whole environment. A higher score indicates that the user agent is
more different.

New Devices The number of new devices seen on the network over a period of time.

New Failed External

An unprecedented (for this device) failed connection attempt to an external endpoint (host:port).
Connections

New Failed Internal

An unprecedented (for this device) failed connection attempt to an internal endpoint (host:port).
Connections

New Internal Connectivity An unprecedented (for this device) connection to an internal endpoint (host:port).

The number of times over a period of time that a subnet is configured to use DHCP, but no DHCP traffic is found. Whether DHCP is used or not can be configured
No DHCP Traffic Events
according to subnet in the Threat Visualizer under ‘Subnet Admin’. This is a system-level event.

NTLM Login Number of successful NTLM logins seen.

NTLM Login Fail Number of unsuccessful NTLM logins seen.

Outbound TORs The number of times over a period of time that outgoing TOR traffic has been observed. This is based on the SSL certificate.

Packet drops on appliance The appliance is dropping incoming packets.

The number of times over a period of time that the device has successfully logged in via POP3 to check e-mail. The email address of the user can be queried by using
POP3 Login Successes
the ‘Message’ field filter.

POST Requests With No

Number of POST requests performed by the device that aren’t preceded by the usual expected GET request.
Get

146
METRIC DESCRIPTION

The number of times over a period of time that a proxy server has been added or removed from the automatically managed internal list of proxy servers the Darktrace
Proxy Server Changes
system tracks. This applies at system level, not at device level.

RADIUS Login The number of RADIUS logins seen.

RADIUS Login Failure The number of failed RADIUS logins seen.

An RDP Login, which gives additional information if not encrypted including client name, build, color depth, keyboard layout and screen size. This will often fire
RDP Client
alongside RDP Cookie and RDP Keyboard

RDP Cookie An RDP Login can contain a cookie, which are sometimes useful like usernames, and often present when encrypted.

An RDP Login where the keyboard layout was seen. The message field contains the keyboard layout requested. Can be useful if unusual layouts in different
RDP Keyboard
languages are seen.

Reboots The number of times the device has rebooted. This metric is based on TCP flag analysis.

The number of servers found serving a protocol on a port number that is atypical for the protocol in question (e.g., SMTP on port 80). It uses an internal list of
Servers Serving Protocols
application protocol and port combinations. The same result can be achieved using the ‘Connection’ metric in combination with the ‘Unusual Port for Application
on Non-Standard Port
Protocol’ filter.

SMB Access Failure The number of SMB access failures seen and the SMB access failure response(s).

SMB All Will fire on any other SMB metric.

SMB Delete Failure The number of delete requests that were failed.

SMB Delete Success The number of delete requests that were successful

147
METRIC DESCRIPTION

SMB Delete Unknown The number of delete requests for which a reply was not received.

SMB Directory Query

The number of failed SMB2 directory queries over a period of time.
Failures

SMB Directory Query

The number of successful SMB2 directory queries over a period of time.
Successes

SMB Directory Query

The number of directory query requests for which a reply was not observed.
Unknown

SMB Move Failure The number of move requests that were failed.

SMB Move Success The number of move requests that were successful.

SMB Move Unknown The number of move requests for which a reply was not received.

SMB Read Failures The number of failed SMB2 reads over a period of time. The path to the file can be queried by using the ‘Message’ field filter.

SMB Read Successes The number of successful SMB2 reads over a period of time. The path to the file can be queried by using the ‘Message’ field filter.

SMB Read Unknown The number of read requests where a reply was not observed, and as such the status of the request is unknown.

SMB Session Failure The number of unsuccessful session setup operations that were seen.

SMB Session Success The number of successful session setup operations that were seen.

148
METRIC DESCRIPTION

SMB Sustained Mimetype

Many files were observed to change mime type in limited period of time, indicating a possible ransomware attack.
Conversion

SMB Write Failures The number of failed SMB2 writes over a period of time. The path to the file can be queried by using the ‘Message’ field filter.

SMB Write Successes The number of successful SMB2 writes over a period. The path to the file can be queried by using the ‘Message’ field filter.

SMB Write Unknown The number of write requests where a reply was not observed, and as such the status of the request is unknown.

SMTP Block List Blocked The number of times over a period of time that an SMTP sender that is on a block list has been observed trying to send email to an internal machine (indicating a
Hosts possible source of spam).

SSH Data Transferred The number of times over a period of time that an undetermined login results because the ‘new keys’ message was not seen and the amount of data transferred from
Ambiguities the server is in a gray area.

SSH Heuristic Login Failed The number of SSH Login Failures determined heuristically. May occur fire multiple times on the same connection representing multiple failed attempts

SSH Heuristic Login

The number of SSH Login Successes determined heuristically.
Success

The number of times over a period of time that the device has been seen attempting to log on. This is based on rapid connection attempts to SSH over a specific time
SSH Password Guesses
window i.e. 30 connections in 30 minutes, with low byte counts received from the server. (To be phased out).

SSH Undelivered Stream The number of times over a period of time that the amount of data observed in the TCP stream would have been classed as a failure, but unobserved or missing data
Ambiguities would have classed it a success if it was genuine.

SSH Undetermined
Raised when we have reached SSH2 decryption but analysis of encrypted packet sizes is unable to determine a successful or failed login.
Encryption Step

SSL Invalid OCSP The number of Online Certificate Status Protocol (OCSP) responses observed over a period of time, which are not deemed to be valid. This Component checks the
Responses SSL certificate validation requests (e.g., against the SSL certificate revocation lists).

149
METRIC DESCRIPTION

SSL Protocol Errors The number of SSL protocol errors seen by the device over a period of time. This typically happens when something is trying to look like HTTPS (e.g., Skype).

System Internal Darktrace System events, such as Probe down, or subnet size changes .

System Daily Heartbeat A once daily notification, useful in SIEMs to ensure events are correctly arriving. (For example when there are no other model breaches in a day) .

Warning from the Darktrace appliance that is processing too much data and is overloaded. Effects may include unresponsive GUI and dropped packets. Contact your
System Load
Darktrace representative if this is unexpected.

Unique Failed DNS The number of unique hostnames for which an NXDOMAIN DNS failure has been received over a period. This is useful for domain generation algorithm (DGA)
Lookups detection.

Anomalies raised for a device that are derived from the overall behavior of a device as calculated by a variety of mathematical approaches. These are generated with
Unusual Activity Events a particular timestamp, but can be raised as a response to behaviors that have been ongoing for a period of time. These have a strength (20-100) and a set of one or
more of the strongest contributing metrics to the anomaly. The classifier will generate an event whenever it decides a device’s behavior is over 20% unusual.

The number of times the device deviates from its usual pattern of logging in, for example when it logs in at an unusual time or place or as an unusual user. Logging in
Unusual Credential Uses
refers to email and Kerberos logins. The usual pattern is rendered as a percentage score, which can be defined by the ‘Strength’ filter of this metric.

Unusual External DNS The number of DNS requests made by the device to an undefined external DNS server over a period of time. Darktrace automatically learns what the DNS servers are
Servers based on the number of people using them.

Unusual Internal DNS The number of DNS requests made by the device to an undefined internal DNS server over a period. Darktrace automatically learns what the DNS servers are based
Servers on the number of people using them.

The number of connections the device makes over a period of time to domains on an internal watch list. Darktrace maintains an editable list of domains to be watched.
Watched Domains
This is useful, for example, if company policy dictates that users should not connect to certain domains, for example dropbox.com.

The number of connections the device makes over a period of time to IPs on an internal watch list. Darktrace maintains an editable list of IPs to be watched. This is
Watched IPs
useful, for example, if company policy dictates that users should not connect to certain IPs.

Young SSL Certificates The number of certificates younger than a system defined time interval detected.

150
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
January 30 2021

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