PRODUCT GUIDE

Darktrace Virtualized Enterprise Immune System Deployments

Darktrace provides virtualized Enterprise Immune System deployments by hosting a cloud-based master instance within Darktrace
cloud environments (AWS and Azure). Virtualized deployments receive data from local probes in the customer network (physical or
virtualized), from host-based Client sensors, from integrated third-party services (such as SaaS or Cloud) or from connected Darktrace
products such as Antigena Email.

How Does it Work? Antigena-enabled SaaS modules are also available for Office
365, Zoom and Okta, enabling the extension of autonomous
Cloud master instances can analyze and ingest the same data
response into business critical third-party platforms. For advanced
as a standard physical appliance. For coverage over remote
operators, Antigena SaaS offers the Antigena Lambda toolkit for
workers or satellite offices with minimal networking infrastructure,
the creation of versatile, custom actions through AWS Lambda.
the host-based Darktrace client sensor can transmit and analyze
traffic through cloud-based, Darktrace infrastructure directly to
Darktrace Antigena Email integrates seamlessly with a virtualized
the cloud master instance.
master and can be deployed for Google Workspace (formerly
G Suite), Office 365 or Hybrid Exchange environments. When
Organizational network traffic - physical or virtual - can be sent
deployed, Antigena Email and the cloud-hosted appliance will
via a Darktrace vSensor in one of two encrypted communication
share metadata on devices, network and domain rarity and threats
modes. Push Token is particularly recommended as it does
detected by either platform to ensure expanded protection
not require an inbound firewall exception to the vSensor IP.
across the organization.
vSensors can be deployed as a standalone virtual machine, in
a traffic-mirroring scenario, or with up to 255 osSensor agents
Security
(per vSensor). Darktrace osSensors can be installed on devices
running Windows, supported Linux distributions and any Linux Individual, completely separate instances are provisioned for each
environment running the Docker engine. customer within the desired cloud-provider region. Data ingested
from local probes in the network, cloud and virtual environments
In addition to processing and transmitting network traffic, vSensors is encrypted in transit and will not leave the region. In addition,
can ingest and forward syslog-format logs to the Darktrace cloud two-factor authentication is enforced on all user accounts.
master. VPN and DHCP logs can provide valuable device-tracking
enrichment and custom event types derived from ingested log Darktrace is ISO27001 certified, ensuring we maintain a high
data can be used to integrate with a number of third-party tools. standard of information security. Our risk appetite is low and
our multi-layered approach to security includes:
Cloud-based deployments also support Darktrace SaaS and
Cloud Security Modules which extend Darktrace visibility into Ǔ Least-privilege role-based access control
third-party services and virtualized environment management
Ǔ Strong modern ciphers across software and infrastructure
activity. After authorization, each module retrieves and analyzes
(TLS1.2, AES 256 GCM, SSHv2 Chacha-poly20)
audited event data from the specified service, expanding ‘pattern
of life’ detection and anomaly detection outside the network. Ǔ Regular penetration tests by internal and third-party experts

Ǔ Production and development environments covered by 24/7,

Autonomous Response
Virtualized deployments support Antigena autonomous response
applied via vSensors and osSensor agents. vSensors can perform
Antigena Network reset actions directly or instruct their associated
osSensors - agent or containerized - to respond. In VPC traffic
mirroring scenarios, osSensors are required to take autonomous
actions.
year-round monitoring by the Darktrace Security Operations
Center
Ǔ Background checks for new staff members and automatic
account lockouts for departing staff
The full information security policy can be requested from your
Darktrace representative.
Regional Availability Restrictions
If your organization is subject to regional or geographic restrictions Ǔ Darktrace does not offer virtualized master deployments
on data flow that would prevent use any of the following regions, hosted outside the Darktrace AWS and Azure cloud
please discuss this with your Darktrace Representative. environments.

Ǔ For security reasons, the cloud-hosted master will not accept

Each cloud instance is provided with a unique hostname for
or ingest unencrypted data. Network traffic, log data, and
inbound traffic and user interface access. For outbound traffic
other data types must be sent over a secure channel, such
(NAT), the IP address/hostname pairs are listed below for
as a vSensor operating in an approved mode.
each region and cloud provider. These pairs can be used to
whitelist incoming traffic from the cloud-hosted instance to your
Configuration and Management
organizational network.
Cloud masters are managed and maintained by Darktrace
AWS operations; the management and system administration console
is not available in this deployment scenario. If you wish to modify
Darktrace can offer cloud-based deployments hosted in Europe
a setting or configure a process that would normally require
(AWS region “eu-west-1” or “eu-west-2”), the United States (AWS
console access, please contact your Darktrace representative
regions “us-west-1” and “us-west-2”), Canada (AWS region
or a member of Darktrace support who will assist you with this
“ca-central-1”), Singapore (AWS region “ap-southeast-1”) or Australia
process.
(AWS region “ap-southeast-2”).

Darktrace manages instance scaling in line with traffic-load.

REGION IP ADDRESS DNS ENTRY
US (1) 52.9.179.107 cloud-nat-usw1.darktrace.com Software Updates
US (2) 54.187.177.155 cloud-nat-usw2.darktrace.com
Threat Visualizer software is automatically updated when a new
Canada 15.223.16.1 cloud-nat-cac1.darktrace.com
version becomes available; where possible, updates will be
EMEA (Ireland) 52.51.139.68 cloud-nat-euw1.darktrace.com applied outside standard business hours. If this is not possible,
EMEA (UK) 18.132.236.38 cloud-nat-euw2.darktrace.com the update process will cause minimal disruption for Threat
APAC (Singapore) 52.220.237.248 cloud-nat-apse1.darktrace.com Visualizer users.
APAC (Australia) 3.24.26.120 cloud-nat-apse2.darktrace.com
Backups
Multiple short-term snapshot backups are taken on a rolling basis
to ensure continuity in a disaster recovery scenario.
Azure
Darktrace can offer cloud-based deployments hosted in Europe
Access
(Azure region “UKSouth” or “WestEurope”), the United States Cloud-hosted deployments are accessed via a unique hostname
(Azure region “EastUS”), Canada (Azure region “CanadaCentral”), in the format “https://[region]-XXXX-01.cloud.darktrace.com”,
South East Asia (Azure region “SoutheastAsia”) or Australia (Azure where “region” denotes the geographical region that cloud
region “AustraliaEast”). instance is hosted within and the cloud-provider prefix, where
applicable. This hostname cannot be modified - if this is unsuitable
REGION IP ADDRESS DNS ENTRY for your organizational naming scheme, you may wish to configure
US (East) 52.170.164.120 cloud-nat-eastus.darktrace.com
a custom internal DNS record and a matching FQDN value on
the System Config page.
cloud-nat-canadacentral.darktrace.
Canada 52.139.10.121
com
EMEA (UK) 20.49.143.39 cloud-nat-uksouth.darktrace.com
Two-factor authentication is enabled for all user accounts by
default.
EMEA (EU) 20.61.9.184 cloud-nat-westeurope.darktrace.com
cloud-nat-australiaeast.darktrace.
APAC (Australia) 20.193.44.157
com
cloud-nat-southeastasia.darktrace.
APAC (SEA) 20.197.98.133
com
Example Deployment Process with Darktrace
Client Sensors
1. Darktrace operations will provision a cloud-based master
instance in your desired cloud region and preinstall the
required SaaS and Security Module modules. The available
regions are listed in the Regional Availability section.
2. Receive the access and log in details from your Darktrace
representative (credentials will be sent over separate secure
channels) and access the instance for the first time.
Two-factor authentication is enabled as standard on virtualized
deployments; 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.
3. Retrieve the authentication information and Client Sensor
(cSensor) installation files for the relevant operating
systems from the Customer Portal or from your Darktrace
representative. Three key values are required for installation
and are available from the same location as the installer:
Ǔ The Fully Qualified Domain Name of your dedicated
cSensor cloud infrastructure.
Ǔ The unique authentication token.
Ǔ The identifier of the unique authentication key.
4. Install cSensor agents on all desired devices using the
authentication information supplied on the Darktrace Customer
Portal and/or directly by your Darktrace representative.
5. Confirm that all elements have been successfully deployed
and that cSensor monitored devices populate in the user
interface. The System Status and System Config pages
provide details of system health and traffic.
Your Darktrace representative can assist with troubleshooting,
sizing virtual probes and adding additional modules as
desired.
Example Deployment Process with SaaS
Coverage
1. Darktrace operations will provision a cloud-based master
instance in your desired cloud region and preinstall the
required SaaS and Security Module modules. The available
regions are listed in the Regional Availability section.
2. Receive the access and log in details from your Darktrace
representative (credentials will be sent over separate secure
channels) and access the instance for the first time.
Two-factor authentication is enabled as standard on virtualized
deployments; 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.
3. From the System Config page of the cloud master, locate the
“SaaS / Cloud” subsection of the Modules view and proceed
through the authorization process for each module.
4. Confirm that the authorization was successfully and the
modules are able to retrieve data. The System Config page
will provide details of module service status.
Your Darktrace representative can assist with troubleshooting,
adding additional modules or network traffic probes as
desired.
 Example Deployment Process with Darktrace
vSensors
Networking Requirements 5. Confirm that all elements have been successfully deployed
and that probes are accessible and processing data. The
For network traffic ingestion, a minimum of one vSensor
System Status and System Config pages provide details of
authenticated to communicate with the Darktrace master in an
system health and traffic.
encrypted mode is required.

Your Darktrace representative can assist with troubleshooting,

Ǔ In Push Token mode (recommended), the vSensor must be
sizing virtual probes and adding additional modules as
able to contact the cloud master outbound on port 443 at
desired.
the hostname provided by your Darktrace representative.

Ǔ In Pull mode, the vSensor IP must be continually accessible

inbound on port 443 from the cloud master IP/Hostname
listed under Regional Availability.
Example Process
1. Darktrace operations will provision a cloud-based master
instance in your desired cloud region. The available regions
are listed in the Regional Availability section.
2. Receive the access and log in details from your Darktrace
representative (credentials will be sent over separate secure
channels) and access the instance for the first time.
Two-factor authentication is enabled as standard on cloud
master deployments; 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.
Alternative Pull Mode Configurations
If exposing the vSensor IP directly to the Cloud master is not
possible, multiple vSensors can be configured behind a custom
proxy with a single external IP. Alternatively, HTTPS traffic could
be proxied to any vSensor(s) using an OpenVPN tunnel via a
server outside of the network firewall.
Additionally, if access to the vSensor on port 443 is not possible
due to networking restrictions or more than one vSensor exists
behind the same IP, an alternative external port can be used as
long as a corresponding NAT rule exists in the firewall to route
this traffic to port 443 on the vSensor internal IP. This must be
specified when entering the vSensor IP in the System Config
page, for example: “123.45.12.34:14677”.
Your Darktrace representative can advise and assist with these
alternative configurations.

3. Configure at least one Darktrace vSensor in an approved Log Forwarding

mode and authenticate it with the cloud master System
In addition to processing and transmitting network traffic, vSensors
Config page.
can ingest and forward syslog-format logs to the Darktrace cloud
master or actively query a Splunk instance for desired logs.
a. If the vSensor is configured in Pull Mode, ensure that
vSensors accept both unencrypted and TLS/SSL encrypted logs.
the relevant firewall rules have been configured to
For encrypted logs, the vSensor accepts TCP traffic on port 6514
ensure continuous access to the vSensor IP from the
and uses a self-signed TLS/SSL certificate by default. For details
cloud master location.
on providing your own certificate, please see the vSensor FAQ.
b. If the vSensor is configured in Push Token mode
(recommended), ensure that the relevant firewall rules If the vSensor is located locally within your network then you
have been configured to ensure continuous access may wish to send log input data to the vSensor unencrypted on
outbound from the vSensor to the cloud master location. port 1514 (UDP or TCP) - this is not recommended for vSensors
outside the network boundary.The vSensor forwards matching
log entries in the same way as network traffic, therefore logs
vSensors can process traffic from virtual or physical networks1,1
sent in plaintext to the vSensor will be encrypted when passing
from VPC packet mirroring environments, or from host-
between the virtual probe and the master.
based osSensors directly installed on devices or deployed
in containerized environments.
Pattern-matching is configured on the Darktrace master and
then propagated to the vSensor to apply to all future log entries.
4. Optionally deploy osSensors, SaaS and Cloud security
Matching (and discarding) is performed at the vSensor level; valid
modules and configure log input to ensure maximum visibility
matches are then forwarded on to the master.
over your extended network environment.

Please see the Log Input Guide or the Darktrace System

Administration Guide for a more in-depth explanation of log input.

11vSensors run a virtual kernel by default which supports only a limited number of hardware drivers. Please see the vSensor FAQ for
details about expanding the kernel to support physical traffic.

US: +1 415 229 9100 UK: +44 (0) 1223 394 100 LATAM: +55 11 4949 7696 APAC: +65 6804 5010 info@darktrace.com darktrace.com
LAST UPDATED: AUGUST 4 2021