Network Traffic Analyzer (NTA)
What is the NTA?
The Samurai Network Traffic Analyzer (NTA) is a virtual appliance designed to provide deep visibility into network activity and detect suspicious or malicious behaviour. It can be deployed in a virtual environment or as an AWS EC2 instance, enabling passive monitoring and analysis of east-west and north-south traffic for security threats and anomalies.
The NTA compliments existing security measures, delivering deeper insight into traffic and potential risks. Our approach leverages core capabilities to maximize protection and visibility:
Advanced Analytics
- Utilizing machine learning and behavioral analysis, the Samurai Real-Time Engine (deployed on the NTA) identifies anomalous network activities that could indicate security threats, even those that evade traditional detection methods.
Cyber Threat Intelligence Integration
- We apply our global threat intelligence feeds to enrich network data with context about known malicious actors, emerging threats, and attack patterns. This enhances the accuracy and speed of threat detection.
Network Layer Threat Hunting
- The ability to proactively hunt for threats at the network layer, our Samurai SOC analysts can identify suspicious patterns and indicators of compromise that automated systems might miss.
Full Packet Capture (PCAP)
- With full packet capture capabilities, the Samurai NTA allows for comprehensive forensic analysis. In the event of a security incident, Samurai SOC analysts can reconstruct sessions and examine payloads to understand the full scope and impact of the breach.
What are example use cases for the NTA
- Clients with bespoke or unsupported systems e.g no current integration
- Clients who want to expand their monitoring capabilities leveraging NTTs global threat intelligence
- Clients who want to expand monitoring beyond telemetry data sources integrated into Samurai MDR, or have systems that do not produce telemetry data with limited threat detection capabilities, refer to Telemetry Data Source Categorization to understand how Samurai categorizes supported integrations
- Clients who wants to get a quick cyber security grip on new acquisitions
- Clients with distributed branch offices with heterogenous environments and no central log collection
What are the components of the NTA?
The NTA gains visibility of network traffic through traffic mirroring. The NTA monitors the traffic utilizing specific components and generates security detections (alerts) which are sent to the Samurai platform and triaged, investigated and validated by SOC analysts potentially leading to a security incident reported to you. Refer to the high level diagram below:
Figure 1: The NTA internal components
Traditional IDS Meets Advanced Analytics
- The NTA includes a traditional Intrusion Detection System (IDS) component (Suricata), which provides baseline network monitoring. However, its true strength lies in its ability to decode network protocols, converting them into detailed activity logs.
Real-Time Detection with Advanced Analytics
- These activity logs are processed by the NTA resident Samurai Real-Time Engine, which applies:
- Advanced Analytics to identify subtle anomalies.
- Threat Intelligence to detect known malicious patterns.
- This approach ensures a proactive, accurate understanding of network activity.
Full Traffic Recording (Stenographer)
- The NTA records all traffic flowing through its sensor.
- This enables comprehensive forensics and retrospective analysis, providing critical insights into historical activity.
Automatic Alert Data Collection
- When an alert is triggered, the NTA automatically captures related packet data and sends it upstream to the Samurai platform for investigation by SOC Analysts.
- This allows for immediate analysis and a deeper understanding of a potential incident.
What data is analyzed by the NTA?
All network traffic you decide to mirror to the NTA is analyzed. The NTA operates passively monitoring the mirrored taffic without introducing latency or affecting production systems. Even when network traffic is encrypted (e.g HTTPS, SSL/TLS), the NTA can still extract and analyze unencrypted meta data such as IP addresses, port numbers, traffic patterns etc and correlate this metadata with Threat Intelligence such as known malicious IPs, domains or abnormal behaviors - the NTA can identify potential threats and suspicious activity maintaining effective threat detection without decrypting the payload.
If a client has the capability to decrypt traffic before mirroring to the NTA it is of course advantageous, however we recognize this may not be optimal or available in many cases.
All data resides local to the NTA. Any security detections (alerts) made by the NTA coupled with PCAP data is sent to the Samurai platform for investigation by SOC Analysts.
What are the deployment options?
There are two options for deploying the Samurai NTA, both options cover network traffic visibility but are deployed and configured differently.
- Deployment on virtual system(s)
- Deployment on an AWS EC2 instance
Who is responsible for the NTA?
You, the client is responsible for installation and configuration of the NTA including the underlying hypervisor/virtual machine settings and/or AWS EC2 configuration and settings.
The Samurai team is responsible for ensuring health and availability of the NTA which includes maintenance of the Operating System and installed software.
Samurai will send email notifications to registered users should your NTA encounter any problems, once any issues have been resolved you will be notified again when a healthy status is reached.
If the Samurai team determines that an NTA is oversubscribed we will liaise with you to determine the best plan forward - this could include requesting you to update assigned virtual resources.
Can I get assistance with deployment of an NTA
Yes, if you require help and guidance with NTA deployment and configuration we can help via the Samurai Onboarding service. The service is typically utilized by new Samurai MDR clients to support transition onto Samurai Managed Detection and Response (MDR) but also for clients who wish to expand or review existing commitment including the NTA.
What’s Next?
Review the requirements to determine what is needed before deployment and configuration of an NTA.
1 - Requirements
What you need to get started
Access to the Samurai MDR portal and your specific tenant.
A hypervisor to run the virtual machine, for example VMware ESXi, Microsoft Hyper-V or relevant access to AWS for deployment to an Amazon EC2 instance.
Make any necessary updates to comply with the NTA Communications Requirements.
A static IP address for the NTA management interface and DNS server IP addresses unless you decide to use DHCP.
Necessary access to configure traffic mirroring to the NTA.
The NTA requires two network interfaces, 1 interface for management for secure outbound communication to the Samurai platform and 1 interface for traffic monitoring (we currently only support 1 monitoring interface).
Supported Hypervisors
The NTA supports the follows hypervisors and versions:
| Hypervisor | Version |
|---|
| VMware ESXi | 7.x and above |
| Microsoft Hyper-V | 2016 and above |
| Proxmox Virtual Environment | 8.4.1 and above |
Amazon Web Services Support
For AWS deployment, the NTA requires use of AWS Nitro instances that support traffic mirroring, more information can be found at:
Recommended Specifications
There are two NTA sizes which are based on network throughput, therefore note the specifications based on your requirements.
| Medium | Large |
|---|
| Throughput | 500 Mbit/s | 1000 Mbits/s |
| CPU | 8 Cores | 8 cores |
| Memory | 52 GB RAM
(32 GB RAM for OS and 20GB RAM for ramdisk) | 104 GB RAM
(64 GB RAM for OS and 40GB RAM for ramdisk) |
| Disks | System disk: 300GB
Data disk 200GB | System disk: 300GB
Data disk 200GB |
| Network Interfaces | Management:1 x 1 Gbit/s
Network Monitoring:1 x 1 Gbit/s | Management:1 x 1 Gbit/s
Network Monitoring:1 x 1 Gbit/s |
Communication Requirements
The NTA requires connectivity to resources outlined within the table below, you may need to update your security controls e.g firewall to allow this connectivity.
| Function | Protocol | Port | Source | Destination | Details |
|---|
| Enrolment, NTA backend | TCP | 443 | NTA | *.*.security.ntt
nttsecurity.io
.nttsecurity.io
.*.nttsecurity.io
samurai-xdr-prod-westeurope-xgliuoit.azure-api.net | All regular backend communication |
| Remote Management | TCP | 443 | NTA | ra.cto.nttsecurity.io
deb.releases.teleport.dev
apt.releases.teleport.dev | Remote administration of an NTA |
| NTP | UDP | 123 | NTA | Client infrastructure (NTP server(s)) if configured in Samurai app
OR
0.ubuntu.pool.ntp.org
1.ubuntu.pool.ntp.org
2.ubuntu.pool.ntp.org
3.ubuntu.pool.ntp.org | Time synchronization |
| DNS | UDP | 53 | NTA | Client infrastructure (DNS server(s)) or external DNS servers (based on your NTA configuration) | Domain name resolution |
| Ubuntu updates | TCP | 80, 443 | NTA | *.ubuntu.com
api.snapcraft.io | Ubuntu software repository |
| Container Management | TCP | 443 | NTA | docker.com
*.docker.com (private container registry)
docker.io (private container registry)
*.docker.io (private container registry) | Private container registry |
| Amazon Cloud dependencies | TCP | 443 | NTA | *.cloudfront.net | Amazon CDN used by NTA API |
What’s Next?
Now you have an understanding of the recommended specifications and communication requirements we recommend you proceed to Samurai NTA Deployment
2 - Deployment
Deployment Considerations
Traffic Source
The NTA is a passive device and relies on client infrastructure to stream a copy of network traffic to the NTA’s monitoring interface. When deploying an NTA in a virtual environment or on AWS EC2, several key consideration should be addressed to ensure effective monitoring and minimal impact on performance:
Resource Allocation
- Ensure the NTA meets the recommended specifications. In some circumstances the resources may not be sufficient and we will work with you on any modifications we recommend based on your traffic throughput once the NTA is deployed and running.
Multi-NTA Deployments
- If your network throughput figures exceeds what a single NTA can accomodate you have the option to deploy multiple NTA’s to ensure coverage.
Network Topology and Segmentation
- Map out the virtual network topology and identify where the NTA should be deployed for optimal coverage e.g east-west traffic which typically flows between VM’s connected in the same virtual switch or virtual network, or EC2 instances in the same VPC. Additionally north-south traffic which typically flows between internal and external networks such as web traffic.
Traffic Visibility
A stream copy of data needs to be provided to the NTA monitoring interface. Capturing traffic requires configuring network mirroring or traffic monitoring as outlined below based on your deployment:
Virtual Environment
- Network mirroring on a virtual switch is a method used to capture and analyze traffic passing through a virtual machine (VM) or virtual networks. This is typically achieved by configuring a port mirror, where a copy of the network traffic from one or more source ports is sent to a designated mirror port i.e the NTA mirror interface.
- In a virtualized environment, network mirroring and promiscuous mode can be configured on a virtual switch (such as those in VMware vSphere, Microsoft Hyper-V or others) to facilitate traffic analysis without affecting the networks performance.
Figure 1: The NTA in a virtual environment
Amazon EC2
- For deployment on an EC2 instance, VPC Traffic Mirroring is utilized which allows you to copy traffic from an Elastic Network Interface (ENI).
Figure 2: The NTA running atop AWS
Login to the Samurai MDR portal, click Telemetry and select Network Traffic Analyzer from the main menu
Select Create
Complete the fields as required.
| Field | Description |
|---|
| NTA name | A name for the NTA |
| Description (Optional) | A description of your NTA |
| Location (Optional) | Useful if you have NTAs in multiple locations |
| Hostname | A hostname for your NTA |
| Proxy Server address (Optional) | Optional HTTP proxy server (URL that contains a hostname or IP address with port e.g https://192.168.1.254:8080) |
| NTP Servers (Optional) | Input your own NTP server IP addresses |
| Size | Select the appropriate Size based on throughput |
| DHCP or Static | Determine whether the NTA will use DHCP or specify static IP address and network information |
Select Create NTA once you have completed all relevant fields
Select the NTA you created by clicking the NTA Name used in Step 3
Select Download
- Download the appropriate files for your deployment.
NTA Installation
Based on your chosen deployment follow the relevant section:
Most 1 Gbit/s network interfaces are running in Full-Duplex mode (1 Gbit TX and 1 Gbit RX/s), resulting in an actual maximum throughput of 2 Gbit/s.
Be sure to consider this during sizing and solutioning of the NTA. For example, use multiple NTAs and leverage a load balancer if the throughput is at risk of exceeding NTA capacity. This would require that the mirroring technology used supports traffic splitting (typically based on VLAN, IP’s, Net ranges).
VMware vSphere Installation
Follow the documentation from VMware:
- Provide a virtual machine name.
- Be sure to select the .ova file you downloaded when asked for the file to deploy your virtual machine from.
Once complete follow the VMware article to mount the config ISO file
- Be sure to select the .iso file you downloaded when asked to select file
- The management interface will by default be Network Device (net0)
- The monitoring interface will be by default Network Device (net1) - ensure it is connected to your monitoring network.
- The VM is now ready to be powered on.
- Jump to Deployment Status for next steps.
The .iso file must be mounted at first boot to configure the NTA, after which ensure the .iso should be dismounted or removed.
Proxmox VE Installation
Follow the documentation from Proxmox:
- Follow the steps to first setup a new storage for an import source.
- Refer to the OVA/OVF Import section to import the OVA file you downloaded from the SamurAI Portal.
- Import the NTA configuration ISO file to Proxmox
- Navigate to the Datacenter - Storage section
- Select the storage where you want to store the ISO file
- Click on ISO Images
- Click Upload
- Choose the NTA ISO file and upload it using default settings
- Configure the NTA virtual machine to use the NTA configuration file
- Select the NTA virtual machine and click on Hardware and then Add
- Select CD/DVD Drive
- Check Use CD/DVD disk image file (iso) and locate your NTA configuration file. Click Add
- The management interface will by default be Network Device (net0)
- The monitoring interface will be by default Network Device (net1) - ensure it is connected to your monitoring network
- The VM is now ready to be powered on.
- Jump to Deployment Status for next steps.
The .iso file must be mounted at first boot to configure the NTA, after which ensure the .iso should be dismounted or removed.
Microsoft Hyper-V Installation
Follow the documentation from Microsoft:
- Provide a virtual machine name
- Use the Virtual Machine Requirements when configuring memory and network
- When asked to Connect Virtual Hard Disk ensure to use the .vhdx file you previously downloaded
- For Installation Options ensure you use the .iso file you previously downloaded
- The management interface will by default be Eth0
- The monitoring interface will be by default Eth1 - ensure it is connected to your monitoring network
- The VM is now ready to be powered on.
- Jump to Deployment Status for next steps.
Amazon EC2 Installation
Prerequisitve steps:
- Ensure you have the AWS cloud-init.yaml file you downloaded from Create, Configure and Download an NTA.. This file will be used later during EC2 instance deployment.
Follow the vendor documentation from Amazon to launch a EC2 instance:
Follow the steps outlined in Launch an instance
Perform the following adjustments to the vendor documentation when launching the instance:
- During step 5.a, select Ubuntu as AMI.
- During step 5.b*,* select the latest Ubuntu 24.04 Server AMI
- During step 6*,* select a suitable Instance Type based on estimated performance requirements while fulfilling the Recommended Specifications.
- During step 7 & 7, Set Key pair & Network Settings as per your AWS policies. Ensuring the the Network settings still fulfills the Communications Requirements.
- Before step 9, modify the Configure storage section based on the appropriate NTA size disk requirements.
- Before step 9, expand the section Advanced details and paste in the content of the cloud-init.yaml file into the User data section. Ensure that the check box User data has already been base64 encoded is not enabled.
- Proceed with step 10 and finish the rest of the installation as per the vendor documentation.
- Jump to Deployment Status for next steps.
Deployment Status
Once you have deployed your NTA you can view the deployment steps and status within the Samurai MDR portal.
Login to the Samurai MDR Portal
Click Telemetry and select Network Traffic Analyzer from the main menu
Click the relevant NTA from the presented list
Under General the Status will display as Provisioning.
Deployment Status will be displayed and along with phases and a timestamp. As the NTA builds the status will be listed and cycle green as completed. This includes:
| No. | Deployment Status Message | Description |
|---|
| 1. | Initial call to backend. Network connectivity ok | First message sent to NTA Samurai backend, this indicates that the enrolment has started |
| 2. | Refreshing OS package lists | Refreshing operating system software repository information |
| 3. | Upgrading packages | Starting updating operating system |
| 4. | Finished upgrading packages | Operating sytem update completed |
| 5. | Base OS update completed | Post operating system update maintenance jobs completed |
| 6. | Initiating CTS Build X | NTA installer downloaded and started |
| 7. | Running verification to ensure minimal requirements | Installer started self check to verify minimum requirements and software settings |
| 8. | Completed verification to ensure minimal requirements | Self check completed |
| 9. | Request device_id | Requesting device identity |
| 10. | Request init | Started the registration process |
| 11. | Initiator successfully contacted backend | Contacting backend to retreive basic operating information |
| 12. | Downloading configuration | Downloaded configuration |
| 13. | Logged in to dockerhub | Authorized to Docker hub to access private containers |
| 14. | Downloading Docker containers | Containers was downloaded from Docker hub and are ready to be used |
| 15. | Storing device configuration to the backend | Sent device information to the backend |
| 16. | Starting Manager | Starting NTA manager software, more software/containers will be downloaded in the background |
The deployment log is saved and available, on the right hand side of the NTA Details, click on
(more options) and select
Deployment Logs.
If you run into any errors, check your deployment and if errors persist
raise a ticket with the Samurai SOC.
- Once the NTA has completed deployment, Status will display as Not Healthy as individual components need to start. Once complete the Status will be updated to Healthy which may take approximately 5 minutes.
Refer to
Current Status for additional information on the metrics displayed.
Once you have deployed your NTA you will need to determine the Monitoring interface.
Login to the Samurai MDR Portal
Click Telemetry and select Network Traffic Analyzer from the main menu
Click the relevant NTA from the presented list
Select System Information and view Network which will display the Management and Monitoring interfaces. Take note of each MAC address and ensure it aligns with the relevant configuration for your hypervisor or AWS EC2 configuration.
You will now need to configure traffic mirroring to the monitoring interface of the NTA. Based on your chosen deployment. We advise you to refer to vendor documentation for traffic mirroring as environments may differ. We have provided some useful links based on your deployment model:
VMware VSphere
Microsoft Hyper-V
The following Microsoft documentation is based on Microsoft Defender for IoT, however is applicable to traffic mirroring configuration in general.
Amazon EC2
Delete an NTA
If you delete an NTA it cannot be reversed!
If you need to delete an NTA you can do so by following the steps below:
From the Samurai MDR portal click Telemetry and select Network Traffic Analyzer from the main menu
Select the relevant NTA from your list
On the left hand side of the relevant NTA, click on (more options) and select Delete NTA
The following warning will appear: ‘Warning: This is a destructive action and cannot be reversed.’. To ensure you intended to delete the NTA you will need to type DELETE in the field and select Delete NTA
What’s Next?
You have now deployed and configured your NTA. Refer to NTA Details.
3 - NTA Details
In this article all elements of the Network Traffic Analyzer are outlined to help you understand the panels available.
List all NTAs
Login to the Samurai MDR Portal
Click Telemetry and select Network Traffic Analyzer from the main menu
A list of all NTAs will be displayed. Various fields are displayed based on information you included when creating the NTA.
Click on an entry to drill into an NTA’s details.
General
The General panel of an NTA provides an overview of the NTA and status.
| Field | Description |
|---|
| Status | Status of the NTA. See NTA status for list of potential statuses |
| Description | A decription field for your NTA. You can edit this field at any time |
| Location | Populated from Location specified during creation of the NTA |
| Hostname | Hostname specified during creation of the NTA |
| Size | The size selected during creation of the NTA |
NTA Status
| Status | Description |
|---|
| Offline | NTA created but not online |
| Not available | NTA has been online but no longer available |
| Healthy | NTA deployed and components healthy |
| Not-Healthy | Component(s) deployed on the NTA not healthy |
| Provisioning | NTA is in setup |
Current Status
The Current Status widget provides a visual representation of the CPU, Memory and Disk usage of the NTA. Each metric is displayed as a half-donut chart, offering a quick visual snapshot of system load.
| Metric | Description |
|---|
| CPU Utilization | Displays the percentage utilization across all CPU cores. |
| Memory Utilization | Displays the percentage of system memory consumed. |
| Disk Utilization / | Represents the percentage of storage space used for the system disk. |
| Disk Utilization /srv | Represents the percentage of storage space used for the data disk. Monitoring this metric ensures sufficient space for data/memory cache |
The above metrics are updated in the Samurai MDR portal every 5 minutes and are monitored by the Samurai platform. It is important to note that it is normal to observe high utilization of all metrics as the NTA performs continuous resource intensive inspection of mirrored traffic with processes that inherently demand significant resources to maintain performance and accuracy. For deeper insight we recommend reviewing the additional performance metrics plotted as time-series graphs found under
NTA details.
This widget may also include status messages of individual components of the NTA, this will assist with identyfing any problems the NTA encounteres. raising a ticket with the Samurai SOC.
NTA Status Notifications
Samurai will send email notifications to registered application users should your NTA status change from Healthy to Unavailable. The Samurai team monitor deployed NTAs and it is our responsibility to maintain health, availability and rectify any problems, however we may reach out to you if you are required to make any changes. Once any issues have been resolved, you will also be notified when a Healthy status is reached.
If your NTA restarted, during final startup you may notice the Status change from Healthy to Not-Healthy, this is not cause for alarm as this typically occurs for a short period of time as processes restart. Once complete your NTA status will be displayed as Healthy.
The System Informatiom panel displays important NTA system information and metrics including:
System
| Field | Description |
|---|
| Operating System | The NTA leverages Ubuntu, it is our repsonsibility to maintain the Operating System. |
| CPU | CPU information captured |
| Cores | No. of physical and logical cores of the NTA |
| Memory | Total memory of the NTA |
| Swap | Allocated disk space used as virtual memory |
Storage
| Field | Description |
|---|
| Mount | Directory where storage device or parition is attached to the file system |
| Device | Represents the virtual storage medium by path or Amazon EBS volume |
| Size | Capacity of storage device or partition |
| Usage | Amount of storage consumed in % |
Network Management
| Field | Description |
|---|
| Configuration | Static or DHCP |
| IPv4 | The assigned IP address. The Monitoring interface will not have an IP address |
| Proxy server | Proxy server configured during cofiguration creation |
| NTP servers | Network time protocol servers configured during configuration creation |
| Interface | Virtual adapter |
| Type | Management interface |
| MAC | Unique identifier assigned to the interface |
| Current Bandwidth | The data transfer rate of the network interface measured in Mbit/s |
Network Monitoring
| Field | Description |
|---|
| Interface | Virtual adapter |
| Type | Monitoring interface |
| MAC | Unique identifier assigned to the interface |
| Current Bandwidth | The data transfer rate of the network interface measured in Mbit/s |
Metrics
All metrics displayed are by default over the past 2 hours however you can adjust via the Time Picker
| Metric | Description |
|---|
| CPU Utilization | Displays the percentage utilization across all CPU cores. High usage may indicate heavy traffic analysis or potential system strain |
| Memory Utilization | Displays the percentage of system memory consumed. Persistent high usage could impact performance and may require optimization |
| Disk Utilization | Represents the percentage of storage space used across each disk mount. Monitoring this metric ensures sufficient space for traffic data and system operations |
| Bandwidth Utilization | Displays bandwidth utilization of the mirror interface in Mbit/s |
Alerts
The Alerts panel displays security detections made by the NTA.
You do not have to act on any alerts as the Samurai SOC analysts triage, investigate and validate alerts as part of the Managed Detection & Response (MDR) service.
As alerts are validated by the Samurai SOC analysts and investigated, they may potentially lead to a reported Security Incident and are marked accordingly. Our strategy includes visibility and transparency of the service we provide to you therefore this feature provides you that visibility showcasing the value of the NTA and service.
Alerts Summary
Alerts are summarized in a panel which can be updated based on a specified time period and includes:
- Security Incidents - the total number of security incidents reported to you that may correspond to one or more alerts.
- Alerts - the total number of alerts detected by the NTA.
- Real-time engine- the total number of alerts created by the NTA resident Samurai real-time engine.
- Vendor - the total number of alerts created by the NTA resident Intrusion Detection System (IDS) - Suricata.
Filters
Various filters are available to determine the alerts to be displayed.
Figure 1: Time and Display filter
The total number of alerts within the alerts table in displayed to the left of the Time Period filter.
Time period
You can update all panels to specific date and time ranges. We default to the Last 24 hours however have included Quick time ranges.
Figure 2: Date and time selection
Display Filter
Enter any values you wish to filter and highlight within the display filter.
Figure 3: Display filter
Alert Column Filter
Adjust and show/hide any of the column values within the Alert Table.
Figure 4: Alert column filter
Alerts Table
All alerts related to the NTA are listed within the alert table, it is important to note is that the table is limited to 10,000 alerts therefore apply filters to narrow the results.
For description of each field within the Alert table refer to Alerts Table