Deploy Sophos NDR on AWS

Sophos NDR runs on AWS as an EC2-based integration appliance. It receives a copy of selected VPC traffic through VPC Traffic Mirroring, analyzes it passively, and sends NDR data to the Sophos Data Lake. The appliance is not inline and replaces neither Security Groups nor a firewall.

The reliable high-level process is: clarify licensing and responsibilities, document the AWS network details, create the appliance in Sophos Fusion, download the generated CloudFormation template, subscribe to the Marketplace offering, create the stack, add exactly one controlled Mirror Session, restrict management access, and validate each layer separately.

⚠️ This runbook intentionally does not include a complete teardown. The safe sequence and the consequences of deleting stack, appliance, EC2, EBS, ENI, Security Group, Elastic IP, mirror, and Marketplace resources have not been fully verified. Therefore, a failed deployment must not be “cleaned up” using an improvised deletion sequence.

Architecture and decisions before you begin

CloudFormation creates two logically separate network paths:

The Management Interface is located in a Public Subnet and uses an assigned Elastic IP Address. SSH and access to Sophos Appliance Manager use this path.
The SPAN interface receives mirrored traffic. The NDR SPAN Target created by the template serves as the Mirror Target.
A Traffic mirror session connects a selected source ENI to this target. The NDR Traffic Mirror Filter, which is also created by the template, determines which packets are mirrored.
The appliance processes the copies and sends NDR data to Sophos. The original flows remain on their normal AWS data path.

The most important design decision is therefore not “which entire VPC should we monitor?” but which ENI is a useful Mirror Source. Start with a single documented ENI belonging to a test system. This keeps data volume, cost, and the scope of potential errors small. Add further sources only after technical acceptance.

At a minimum, document the following in a deployment plan before deployment:

AWS account, Region, VPC, Availability Zone, and owner tags;
VPC ID and the Management and SPAN Subnet IDs;
at least one Elastic IP assigned in the AWS account for the Management Interface; this is an account prerequisite, but the documented parameter list does not expose it as a template input that can be selected in advance;
EC2 types currently supported by Sophos: c5n.2xlarge, c6i.4xlarge, or c7i.16xlarge with Nitro virtualization; verify the type that is actually used against the current tenant template and on the instance after deployment;
the name of the existing SSH Key Pair and the secure storage location of the Private Key;
a Security Group for SSH and fixed administrator source networks;
the initial Mirror Source ENI and the workload team responsible for it;
the expected normal test traffic for this ENI;
cost center, budget alarm, and approval for AWS infrastructure costs and the Marketplace terms displayed for this account.

VPC, Subnets, and Elastic IP

You can use an existing VPC and existing Subnets. Do not base the selection on names alone:

Plan the Management Subnet as a Public Subnet. Check its Route Table and intended internet path before selecting it.
Specify the SPAN Subnet for the NDR SPAN interface. Record the Subnet and Availability Zone together with the Mirror Source rather than later inferring the values from resource names.
The Elastic IP belongs on the Management Interface, not the SPAN side. Ensure in advance that at least one Elastic IP is assigned in the account. Do not claim that the stack uses a particular existing address: after CREATE_COMPLETE, determine and record the address actually created or used and its ENI association.
The template selects the AMI and Region automatically based on the AWS Region where the template is uploaded. Do not force a different AMI by editing the template manually.

Security Groups and SSH Key Pair

Use an existing AWS Key Pair whose Private Key is already stored securely. CloudFormation requires the name of the Key Pair; the Private Key is not stored in Sophos Fusion or in the template. Without the Private Key, the SSH access documented by Sophos for the AWS appliance will not be available later.

Prepare a Security Group that permits SSH only from the administrative access network, such as a fixed corporate egress IP as a /32 or through a controlled Jump Host. Do not expose either SSH or TCP 8443 to 0.0.0.0/0.

The template also creates InternalMgmtSG. After deployment, allow TCP 8443 there only for the actual administrator sources. If the same appliance also hosts a Log Collector, permit Syslog only with the protocol and port required by the relevant connector and only from internal source networks. VPC Traffic Mirroring itself does not require a blanket Syslog rule from the internet.

Validate outbound connectivity in advance

A Public Subnet and an Elastic IP do not by themselves prove that a working outbound path exists. Before Submit, the responsible network team must confirm that the Management Interface can communicate outbound through the intended route and an Internet Gateway or the approved centralized egress design. Check DNS resolution, the Route Table, Network ACL, Security Group egress, and proxy and upstream firewall rules.

The required destinations and ports are not copied into this runbook. Instead, at the time of the change, compare the current port and domain exclusions for Sophos appliances against the egress rules. These allowances are relevant to boot, updates, registration, and data upload; proof of connectivity to one destination does not replace the complete comparison.

Prerequisites, roles, license, and costs

The setup requires:

an AWS account with an existing VPC, Subnets, and Availability Zones;
a Sophos Fusion account;
generally, the Sophos Network Detection and Response integration license pack;
at least one suitable source EC2 instance or its ENI;
at least one Elastic IP Address assigned in the AWS account;
a stored AWS SSH Key Pair;
current change approval for network mirroring and the data processed through it.

Where possible, divide the work as follows without inventing unconfirmed IAM policy names:

A Sophos Fusion administrator creates the NDR configuration and downloads the template.
A person authorized for procurement accepts the terms for Sophos Integration Appliance in AWS Marketplace.
An AWS administrator with the permissions required for the stack and referenced network resources creates the CloudFormation, EC2, VPC Traffic Mirroring, Security Group, and Elastic IP resources.
The responsible network or workload team confirms the Mirror Source, filter behavior, test window, and expected traffic.

Sophos does not identify a separate minimum NDR-specific Fusion role for this process. Therefore, if Add Configuration, Download image, or Open Appliance Manager is not visible, do not guess: a Super Admin must check the effective tenant permissions and the license.

The only exception considered here is narrowly defined: for MSP Flex customers with an XDR license, Sophos documents that Sophos NDR can be integrated without an additional Integration License Pack. This does not mean that every XDR or MDR subscription includes NDR, nor that the exception applies to Term licenses. Therefore, confirm the specific tenant/SKU entitlement in Fusion and, if anything is unclear, with Sophos or the procurement partner using the current Sophos integration license rules.

CloudFormation creates billable AWS resources. The virtual appliance is included in the applicable Sophos NDR entitlement; no public list price or statement about the account’s specific Marketplace offering is inferred from that here. Check the Marketplace terms currently displayed before Submit. Estimate the AWS categories EC2, storage, public IPv4 address/Elastic IP, data transfer, and VPC Traffic Mirroring separately. This runbook intentionally provides no fixed amounts: Region, runtime, data volume, and the AWS pricing model change the calculation. Tags and a budget alarm must be included in the change before production mirroring begins.

1. Create the appliance and CloudFormation template in Sophos Fusion

In Sophos Fusion, open Threat Analysis Center > Integrations > Marketplace.
Open Sophos Network Detection and Response (NDR).
Under Data Ingest (Security Alerts), click Add Configuration.
In Step 1, enter a unique name and description, for example ndr-aws-prod-eu1 and NDR Sensor für AWS Produktions-VPC eu1.
In Step 2, under Virtual platform, select AWS.
Click Save. Sophos generates the CloudFormation file aws_ndr_cf_latest.json.
Open Threat Analysis Center > Integrations > Configured, followed by the Integration Appliances tab.
Find the appliance you just created. In the right-hand column, open the three-dot menu, select Download image, and save aws_ndr_cf_latest.json in the protected change folder.

The JSON comes from your own Fusion tenant and the appliance you just created. Do not use an old file from another tenant or change. Do not manually edit the template to force unsupported instance types, AMIs, or network variants.

Search AWS Marketplace for Sophos Integration Appliance.
On the Product Overview page, click Continue to Subscribe.
On Subscribe to this software, review the terms and accept them only with the intended procurement approval. Then click Continue to Configuration.
On Configure this software, check the version and Region. They must match the deployment plan. Click Continue to Launch.
On Launch this software, first open Usage instructions and document the displayed access instructions.
Click Launch. AWS opens Create stack.

The Marketplace subscription is a prerequisite for AWS to accept the software referenced by the template. Therefore, if an AMI is unavailable or an entitlement error occurs, begin troubleshooting with the subscription, Region, and version rather than by modifying the JSON.

3. Create the CloudFormation stack

Before filling in the form, inspect the parameters in the template currently generated from this tenant. If it offers a documented parameter for the EC2 instance type, select only a type currently supported by Sophos and record the parameter name and value. If it offers no such parameter, the template selects the type; do not edit the JSON manually. In either case, verify the EC2 type actually launched after creation.

Under Create stack, leave Template is ready selected.
Under Specify template, select Upload a template file.
Click Choose file, select the newly generated aws_ndr_cf_latest.json, and then click Next.
Under Specify stack details, enter a unique Stack name, such as sophos-ndr-prod-eu1.
Under Network Configuration, enter:
- the planned existing VPC;
- the Public Subnet for the NDR Management Interface;
- the Subnet for the NDR SPAN interface;
- the prepared Security Group for administrative SSH access.
Under EC2 Instance Configuration, select the existing SSH Key Pair. Check again that the Private Key can be located and is protected.
Click Next. Under Configure stack options, review tags and the remaining AWS options. Do not accept defaults blindly; compare them with the change.
Review the summary and click Submit.
Wait for CREATE_COMPLETE. Sophos states that this typically takes five to six minutes; the CloudFormation events are authoritative, not this time estimate.

Before creating the Mirror Session, you must be able to find at least the expected Sophos appliance, its actual EC2 type, the Management and SPAN ENIs, NDR SPAN Target, NDR Traffic Mirror Filter, InternalMgmtSG, and the Elastic IP actually used and its association in the stack or associated AWS resources. If any element is missing or the stack does not end in CREATE_COMPLETE, do not create a Mirror Session.

4. Create one Traffic Mirror Session

Not every EC2 ENI or topology is automatically suitable as a Mirror Source. Before creating it, use the current AWS documentation to check the supported source instance types, the prerequisites and limitations for the Mirror Target, and the specific Source/Target, Region, and Availability Zone topology. Also check Service Quotas and the AWS quotas for Traffic Mirroring to confirm that sufficient quota exists for sources, sessions, targets, and filters. This AWS review is a separate approval gate; the Sophos list of supported appliance types does not confirm that an arbitrary workload ENI supports mirroring.

Open VPC > Traffic mirror sessions > Create traffic mirror session and complete the fields deliberately:

Name Tag: a descriptive name, such as ndr-prod-app01;
Description: purpose and change reference, such as Mirror app01 ENI to Sophos NDR - CHG-1234;
Mirror Source: the ENI of the approved test system, not merely an EC2 instance with a similar name;
Mirror Target: the NDR SPAN Target created by the stack;
Session number: a number appropriate for this Source. AWS uses it for ordering when the same Source has multiple sessions. Inventory existing sessions before choosing it;
VNI: 1;
Filter: the NDR Traffic Mirror Filter created by the stack.

Click Create only after a four-eyes review of Source, Target, Session number, VNI, and Filter. VNI = 1 and use of the generated filter are product requirements. The Source, name, description, and Session number, by contrast, must match your own AWS environment.

Do not add further sources “just in case” during the initial test. An additional Mirror Session increases data volume, costs, and the scope of investigation and therefore requires its own technical approval.

5. Configure management access and credentials

In the AWS Console, search for the appliance name, select the EC2 tab, and open the Sophos Appliance instance.
On Instance Summary, open the Security tab and then InternalMgmtSG.
Under Inbound rules, add TCP 8443 only for the approved administrator CIDRs. Document the Rule ID, source, and change reference.
In Sophos Fusion, open Threat Analysis Center > Integrations > Configured > Integration Appliances.
Open the appliance’s three-dot menu and select Open Appliance Manager.
In the confirmation dialog, click reset it to set the password.
Sign in with the fixed username zadmin and the password you set.

Treat the zadmin password as a privileged secret. Store it in the approved password vault, not in the CloudFormation template, ticket, or screenshot. All administrators use the same Appliance Manager password. If it is lost, reset it through Open Appliance Manager > reset it.

Validate deployment and initial registration

A running EC2 status alone proves neither the mirror path nor registration. Check in this order:

CloudFormation: The stack shows CREATE_COMPLETE; the expected resources are present, with no skipped or failed events.
Network association: The VPC, Management Subnet, SPAN Subnet, Elastic IP, both ENIs, and SSH Key Pair match the deployment plan.
Exposure: SSH and TCP 8443 are accessible only from the approved administrator networks. No new management rule with 0.0.0.0/0 exists.
Mirror configuration: The session points to exactly the approved Source ENI, the NDR SPAN Target, VNI 1, and the NDR Traffic Mirror Filter. The Session number and any existing parallel sessions are documented.
Sophos connection: The appliance is visible under Integration Appliances; its NDR status in Sophos Fusion is green, Open Appliance Manager opens the expected destination, and signing in as zadmin works.
Preliminary data path: During the approved test window, generate normal, harmless traffic on the Mirror Source ENI. On the NDR tab in Appliance Manager, check the upload percentage, the capture percentage for the configured SPAN port, and the Total flows graph. Record the measurement time and values. A Detection is not required for this infrastructure test.
Negative control: An unapproved administrator source must not be able to reach TCP 8443. This control verifies the management restriction, not NDR detection.

Record the Stack ID, appliance name, instance ID and type, Management and SPAN ENIs, actual EIP association, Mirror Session ID, Source ENI, Target, Filter, VNI, Security Group Rule IDs, NDR measurements, and acceptance window. Secrets do not belong in this record. This acceptance confirms only deployment and initial registration. Next, fully validate the mirrored data path with Configure and validate Traffic Mirroring for Sophos NDR, and then perform a safe end-to-end detection test. Neither a successful login nor ordinary test traffic alone proves that the detection chain is working.

Troubleshooting by symptom

Stack does not end in `CREATE_COMPLETE`

First open the stack’s Events tab and work forward from the first failed event rather than backward from the final consequential error.

For Marketplace or AMI entitlement errors: check the subscription, accepted terms, version, and Region.
For permission errors: have the AWS administrator check the action and resource named in the specific event. Do not assign a blanket administrator policy as a quick fix.
For network parameters: compare the VPC and Subnet IDs, assigned Elastic IP or available EIP quota, Security Group, and SSH Key Pair with the deployment plan.
For capacity or quota errors: check the selected supported instance type and the specific AWS error message. Do not switch to a type that the template does not offer.

While the stack is incomplete, do not create either a Mirror Session or additional Inbound Rules.

Appliance is running, but no mirrored traffic arrives

Check the chain in this order:

Is the Mirror Source really the ENI through which the test traffic passes?
Is the Mirror Target the NDR SPAN Target from this stack rather than a similarly named target from another environment?
Is VNI set to 1?
Is the NDR Traffic Mirror Filter selected?
Does the Session number conflict with the intended evaluation order of other sessions from the same Source?
Was traffic actually generated through this ENI during the documented window?

Change only one of these variables at a time, then repeat the same test. A broader filter or Source selection is not a substitute for root-cause analysis.

Mirror Session cannot be created

First read the specific AWS API or console error; do not change the Source, Target, and Filter at the same time.
Recheck the Source ENI and its EC2 instance type against the current AWS prerequisites and limitations for Traffic Mirroring.
Compare the Source/Target topology and Region/Availability Zone selection with the current AWS documentation.
Check the affected Traffic Mirroring quotas in Service Quotas. Request an increase or change the design through the regular AWS change process rather than deleting existing sessions without review.

Registration or NDR upload fails

First check the path established under Validate outbound connectivity in advance. In particular, DNS, the Route Table, Internet Gateway or approved egress design, Network ACL, Security Group egress, proxy, and upstream firewall must align. Compare the rules again with the current Sophos port and domain exclusions. According to Sophos, an upload error involving a presigned S3 URL often indicates outbound internet traffic blocked at the proxy or firewall. Do not broaden egress indiscriminately; document the specific blocked destination and allow only the exception currently required by Sophos.

Appliance Manager is not reachable over TCP 8443

Check whether InternalMgmtSG permits the current public administrator source address.
Check the Elastic IP association with the Management Interface and the selected Public Subnet.
Ensure that Open Appliance Manager opens the expected appliance.
If a rule was temporarily broadened to 0.0.0.0/0, close it again immediately; broad access is not a diagnostic step.

Investigate a password problem only after the network path works.

`zadmin` sign-in fails or Appliance Manager is locked

For an unknown password, use Open Appliance Manager > reset it in Sophos Fusion. If the appliance explicitly displays a lockout message, Sophos documents the following SSH intervention for AWS:

redis-cli --no-auth-warning -h redis-master.default.svc.cluster.local -p 6379 -a $(jq -r .RedisPassword /etc/dragonfly/sensorapi_config.json) SET userlockout '{"attempt":0,"locked":false}'

Run this command only in the SSH session of the affected Sophos NDR EC2 instance, using the Private Key selected during deployment. This runbook intentionally provides neither an operating-system username nor complete SSH syntax because the reviewed Sophos page does not document them. Obtain the current connection identity from the Usage instructions for the subscribed Marketplace offering or clarify it with Sophos Support; do not guess. Before connecting, compare the destination address, instance ID, and host fingerprint against the AWS inventory. The command changes the lockout state but does not set a new password. Use it only when a lockout is explicitly shown, not as a general login fix. Then test the existing password; if it does not work, reset it in Sophos Fusion. Record the command and result, without the password or Private Key, in the change record.

Limited rollback instead of an unverified teardown

Before any manual Security Group change, export the initial state or document it using Rule IDs. If the new TCP 8443 or Syslog rule causes a problem, you can remove precisely this manually added rule and verify the documented initial state. This is a narrow rollback for your own inbound change, not a teardown of the NDR appliance.

No complete deletion sequence is intentionally provided here for the stack, Marketplace subscription, appliance object, EC2/EBS, ENIs, Elastic IP, Traffic Mirror Session, Target, Filter, and Security Groups. Nor does this runbook claim that deleting the CloudFormation stack resolves all associated resources, costs, Sophos objects, or data consequences. Until these dependencies have been verified against current vendor documentation and by testing, remove resources only through a separately reviewed retirement change.