Telemetry

• 1: Telemetry Monitoring
• 2: Integrations
• 2.1: Supported Integrations
• 2.2: Create
• 2.3: High Availability
• 2.4: Details and Status
• 2.5: Delete
• 2.6: Generic Log Sources
• 3: SamurAI Collectors
• 3.1: Local Collector
• 3.1.1: Requirements
• 3.1.2: Deployment
• 3.1.3: Local Collector Details
• 3.2: Cloud Collector
• 3.2.1: Deployment
• 3.2.2: Cloud Collector Details
• 4: Network Traffic Analyzer (NTA)
• 4.1: Requirements
• 4.2: Deployment
• 4.3: NTA Details
• 5: SamurAI Endpoint Agent
• 5.1: Support and Pre-requisites
• 5.2: Download and Installation
• 5.2.1: Download
• 5.2.2: Microsoft Windows
• 5.3: Management
• 5.3.1: Settings and Updates
• 5.4: Uninstall
• 5.5: FAQ

1 - Telemetry Monitoring

The Telemetry Monitoring view provides you a clear concise view of any integrations that have a status of Warning and Critical.

Access Telemetry Monitoring

1. Click Telemetry in the main menu
2. Select Telemetry Monitoring

Figure 1: Telemetry monitoring menu and visual indicator  

Summary Panel

Telemetry Monitoring provides a summary of all integrations and their current status.

Figure 2: Example summary information

Possible status and their associated descriptions are outlined in the table below:

Telemetry Monitoring Table

The table lists all integrations for which the SamurAI Platform has not received events according to defined thresholds for Critical and Warning.

Figure 3: Example detail table

Clicking on the Integration will navigate you to the Integration Details. For integrations of type Log an events graph will be displayed which may help in troubleshooting.

Additional Table Information

• HA Group

  • Represents integrations configured in High Availability (HA) mode (e.g. Active/Passive pairs)
  • The best member state determines the group’s overall status
  • Notifications are sent only for HA groups — not for individual members
  • Refer to High Availability and Integrations

• Unsupported integrations

  • Displayed as Product - unknown and Vendor - unknown
  • The SamurAI platform does monitor these telemetry event sources in line with default or customized status thresholds

If you want additional information on Integration health, please review How do I know if my integration is functioning?

2 - Integrations

What is an Integration?

A data source integrated with the SamurAI platform. An integration allows us to collect and ingest telemetry data from multiple sources, including network, endpoint and cloud.

What integrations are available?

We have pre-built integrations to a comprehensive array of 3rd party products and services. Select Supported Integrations to view what is available.

For syslog sources, even if events do not match a supported Integration, we will still ingest events into our data lake as a Generic Log Source. You will still be able to process this data using Advanced Query, and include events from generic log sources within your queries.

How do I integrate data sources?

Select Create for steps to integrate data sources.

Integration Health

Once you have configured Integrations to bring your data into the SamurAI platform, you will also want to make sure that your data sources are healthy. For more details on how to maintain Integration health and troubleshoot problems, please read our article about Integration Health.

What’s Next?

Upon completion of your integrations and validation of health, the platform will start collecting and ingesting telemetry data. Dependent on your phase of MDR onboarding our team will be in contact with you.

2.1 - Supported Integrations

Integrations facilitate the ingestion of data sources from a wide range of third party vendors. Our Integrations are updated regularly as new and emerging technologies are released.

Each Integration typically requires a configuration guide outlining steps you must follow to integrate your data source to the SamurAI platform.

For details such as transport methods and logs collected please refer to each supporting vendor configuration guide by clicking the link in the table or browsing directly to Product Integration Guides.

All supported integrations are categorized according to our Detection Categorization. For further information refer to the following article: Telemetry Data Source Categorization.

Available configuration guides

In the pipeline

Outlined below are integrations we have in the pipeline however have no committed dates for support. Please note any integration may be influenced by changing business opportunities and client requirements. Please contact NTT for further information or if you require additional support.

2.2 - Create

Create Integration

1. From the SamurAI Portal click Telemetry and select Integrations from the main menu.
2. Click Create integration.
3. Select the product you wish to integrate with the SamurAI platform.
4. Click Next. Dependent on how we collect telemetry, the product may be integrated via a Cloud Collector or Local Collector. Follow the steps based on the Collector type:

Cloud Collector

1. If the integration is cloud-based you need to select the relevant Cloud Collector. Select the relevant Cloud Collector and click Next.
   • If you are using a public cloud storage account you should already have completed the steps in Cloud Collector.
   • If no cloud storage is utilized then a default cloud collector is available.
2. Select Configuration Guide which will direct you to SamurAI documentation outlining how to configure your product and obtain required fields.
3. Once you have configured your product, complete the required fields.
4. Select Finish.

Local Collector

1. Your Local Collector(s) will be listed. Select the Local Collector that you will integrate the product with.
2. Click Next (typically this is the syslog destination host when configuring your device). If you do not have a Local Collector setup and deployed, follow the steps in our SamurAI Local Collector article.
3. The Local Collector IP Address will be displayed, copy the IP address or take note of it.
4. Click Configuration Guide which will direct you to SamurAI documentation outlining how to configure your product.
5. Based on the product, Extended Data Collection may be displayed, if so jump to Extended Data Collection.
6. Click Finish

Extended Data Collection

For many products we are able to collect extended data enhancing our threat detection capabilities and accuracy, for example Packet Capture (PCAP) data. This option will be displayed during configuration of an integration.

1. If extended data collection is available for the product, you can choose to enable or disable via the toggle. If you choose to disable, Select Finish
2. If you choose to enable extended data collection you must complete all the necessary fields. The parameters for each field are derived from following the associated product configuration guide. Once complete, Select Finish

2.3 - High Availability

If you have products configured in a High Availability configuration e.g. Active/Passive pair you have the option to configure HA Groups.

HA Groups are important for telemetry health monitoring and notifications. An example scenario is if you have an Active/Passive product configuration where the Active node consistently sends data to a local collector, however the Passive node sends intermittent data. In this scenario the Active node status would be reported as OK, however the Passive node status may appear as Critical despite there not being a telemetry ingestion problem.

HA Group telemetry monitoring is handled based on the ‘best’ state of all members e.g in the scenario above if a HA Group has two members and one member has an OK status, and the second member has Critical status the overall group state will be considered OK.

Create HA Group

1. Click Telemetry and select Integrations from the main menu
2. Click (more options) at the top right of the table and select Create HA Group
3. A Create HA Group window will be displayed

Figure 1: Create HA Group window

4. Enter a Name for the HA Group
5. From the drop down menu select the integrations to be members of the HA Group
6. Click Confirm

Within the Integrations table, the field type HA Group will be displayed with the number of members highlighted.

Edit a HA Group

1. Click Telemetry and select Integrations from the main menu
2. Click on (more options) to the left of the HA Group and select Edit HA Group
3. Add or remove the group members required
4. Click Confirm

Delete HA Group

1. Click Telemetry and select Integrations from the main menu
2. Click on (more options) to the left of the HA Group and select Delete HA Group
3. A confirmation window will be displayed, Click Confirm

The HA Group will be deleted and integrations will be listed within the table individually.

HA Group Email Notifications

Email notifications are sent per HA Group and not per individual group member.

At least one member of the HA Group must have notifications enabled, taking into consideration enablement at the Integration or Product level.

Refer to:

• Enable or disable email notifications per Product
• Enable or disable email notification per Integration

2.4 - Details and Status

View Integration

There are multiple methods of viewing your integrations.

To view integrations associated with a specific collector:

1. From the SamurAI Portal click Telemetry and select Collectors from the main menu
2. Select the relevant Collector
3. All integrations associated with the Collector will be displayed with associated information

You can also view all integrations regardless of collector:

1. Click Telemetry and select Integrations from the main menu
2. An Integrations table will be displayed with all of your Integrations listed

Click on the specific integration to view configuration parameters. You can edit and update a description to help keep track of the integration.

High Availability (HA) Groups

For integrations configured in a HA Group, selecting a HA Group allows you to view the status and details of all members together in a single view.

For integrations of type Log an events graph will be displayed. This is a useful indicator of the number of events over a given period and may show spikes and drops in events.

Figure 1: Example events graph

By clicking the time picker you can update the events graph to a specific date and time range. We default to the Last 7 days however have included Quick time ranges.

Figure 2: Data and time selector

From the events graph you can pivot directly into Advanced Query by selecting the magnifying glass icon () to view the underlying event data.

Views

You can save filters you set through views. This is useful if, for example, you have a large number of integrations and wish to view only specific products or types of integration.

Click Views to save/reset/delete your different filters. Once saved you can toggle between views.

Figure 3: Views drop down

Integration Status

Potential status displayed are included in the table below:

Status Thresholds

The SamurAI platform defines default Warning and Critical thresholds for each integrated product. These thresholds determine when an integration status is reported as Warning or Critical. You can adjust these values per product (e.g for all integrated Palo Alto NG Firewalls) or per integration (e.g for a single Palo Alto NG Firewall). Refer to Custom Thresholds for further information.

To view the default status threshold per product:

1. Click on more options () to the right of the table as depicted:

Figure 4: Status thresholds option

2. Select Status Thresholds per product

Figure 5: Example default status thresholds per product

Status threshold per product will be displayed, defined in single units or a combination as d (days), h (hours) and m (minutes).

In the example above (Figure 5) for all integrated Cisco: Secure Firewall (FTD) the default thresholds are:

• Warning: 4h. If the SamurAI platform does not receive or ingest any events after 4 hours, the integration status is updated to Warning (displayed within the Integrations Table and the Telemetry Monitoring Table).
• Critical: 10h. If the SamurAI platform does not receive or ingest any events after 10 hours, the integration status is updated to Critical (displayed within the Integrations Table and the Telemetry Monitoring Table, and an email notification is sent to registered users (by default) or as configured by each user.

Custom Thresholds

Custom thresholds can be set per Product (e.g for all integrated Palo Alto NG Firewalls) and/or per Integration (e.g for a single integrated Palo Alto NG Firewall). Set thresholds using a single or combination of time units. Use d for days, h for hours and m for minutes e.g 12h or 1d 2h 10m.

Adjust thresholds per Product

1. Click on more options () to the right of the table
2. Select Status Thresholds per product
3. Enter the Warning threshold in days, hours and/or minutes for the Product
4. Enter the Critical threshold in days, hours and/or minutes for the Product
5. Click Save

Adjust thresholds per Integration

1. Click on more options () to the left of the integration
2. Select Status Thresholds
3. Enter the Warning threshold in days, hours and/or minutes for the integration
4. Enter the Critical threshold in days, hours and/or minutes for the integration
5. Click Save

Once saved:

• The integration will display an Info icon ()
• Hovering over the icon will display Custom Status Threshold text with the threshold set per status

Integration Notifications

By default email notifications are enabled. The SamurAI platform sends email notifications to registered users when an integration is reported as Critical e.g. the SamurAI platform has not receieved or ingested any data from the integrated product according to the defined threshold, however this is fully customizable.

Additionally the SamurAI platform will send push notifications if the SamurAI Portal is installed as an app (Progressive Web App - PWA) and notifications are configured within user settings.

Notifications can be set per Product (e.g for all Palo Alto NG Firewalls) and/or per Integration (e.g for a single Palo Alto NG Firewall). Registered users can also customize what notifications they receive. Refer to User Notifications Settings.

Enable or disable notifications per Product

1. Click on more options () to the right of the table
2. Select Notifications Per Product
3. Toggle the setting to enable or disable by selecting the bell icon. Alternatively you can select the default setting
4. Click Save

Figure 6: Example notification settings

Enable or disable notification per Integration

1. Click on more options () to the left of the integration
2. Select Notifications
3. A Notifications Settings window will be displayed
4. Toggle the setting to enable or disable by selecting the bell icon. Alternatively you can select the default setting
5. Click Save

Hide Integration

Hiding an integration will remove it from the integrations displayed and also from the Telemetry Monitoring view and disable notifications.

Only integrations of type Log can be hidden. Some reasons why you may want to hide an integration include:

• You may want to hide all of your unsupported/generic log source integrations.
• And you do not want to receive notifications if there is an issue with telemetry ingestion to the SamurAI platform.

To hide an integration:

1. Find the relevant Log integration within the table
2. Click on more options () select Hide integration
3. A Hide Log Integration window will be displayed, click Confirm

To view any hidden integrations:

1. Click on more options () at the top right of the table and select Hidden log integrations
2. A Hidden Log Integrations window will be displayed with hidden integrations

Unhide Integration

1. Click more options () at the top right of the table and select Hidden log integrations
2. A Hidden Log Integrations window will be displayed
3. Find the relevant Hidden integration
4. Click on more options () to the left of the integration and select Unhide integration

2.5 - Delete

Delete Integration

If you wish to delete an integration associated with a specific Collector:

1. From your SamurAI Portal Telemetry and select Collectors from the main menu
2. Select the relevant collector from your list
3. You will now see all integrations associated with the collector
4. Select your integrations
5. On the right hand side of the relevant integration, click on (more options) and select Delete Integration
6. The following warning will appear: ‘Warning: This is a destructive action and cannot be reversed.’. To ensure you intended to delete the integration you will need to type in the highlighted ‘Integration’s Hostname’ and select Delete Integration

You can also delete from the Integrations menu item:

1. Click Telemetry and select Integrations from the main menu
2. Find and select your integrated product
3. On the right hand side of the relevant integration, click on (more options) and select Delete Integration

2.6 - Generic Log Sources

While we make an effort to support a wide variety of Integrations and different types of log sources, it is possible that there may be a log source that you would like to ingest into the SamurAI platform which we are not able to parse and analyze. This is especially true for events generated via syslog log sources.

The fact that we are not able to use a log source for detections doesn’t mean that it won’t still be useful to ingest into the SamurAI platform. We will ingest any event data, provided via syslog (sent to a SamurAI local collector), into our data lake and you will still be able to analyze that event data using Advanced Query. This allows you to include events from generic log sources when you are performing queries.

If a log source, ingested via syslog, does not match one of our supported integrations, we will ingest the log events, which will still contain, amongst others, the following fields:

• timestamp: the time at which the log message was ingested
• collector: the id of the collector which ingested the event
• host: the source host from which the event was received
• raw: the complete raw log message

You can then proceed to query these events using Advanced Query. For example, the following KQL query finds all the attempts to connect to a host using invalid user ids and then counts the attempts by source IPv4 or IPv6 address:

events | where host == "10.1.1.1" and i(raw contains "Invalid" or raw contains "failed") and raw !contains "connect" | project timestamp, user = extract("user ([a-zA-Z0-9\\-]+) from ", 1, raw), ipaddr = extract(".+ ([0-9a-f]+[\\:\\.][0-9a-f\\.\\:]+) ", 1, raw) | summarize num_attempts = count() by ipaddr| order by num_attempts

The output is ordered by the number of attempts from each IP address, producing a table like the following:

3 - SamurAI Collectors

What are SamurAI Collectors?

SamurAI Collectors are components used to receive and securely transport telemetry data from client environments, security controls, and cloud services to the SamurAI Platform, where it is ingested for use within the SamurAI MDR service.

Collectors act as ingestion points within the SamurAI Platform, enabling telemetry to be collected from a wide range of technologies and environments.

What do SamurAI Collectors do?

SamurAI Collectors perform the following functions:

• Receive telemetry from security tools, infrastructure, and cloud services
• Support multiple data collection methods depending on the integration
• Securely transmit telemetry to the SamurAI Platform
• Enable consistent ingestion of telemetry across different environments

Collectors act as transport mechanisms, ensuring telemetry is delivered from source systems to the SamurAI Platform for processing and analysis.

Types of SamurAI Collectors

SamurAI MDR uses different types of collectors depending on how telemetry is accessed and integrated.

Local Collector

The Local Collector is deployed within a client-controlled environment and is used to collect telemetry from systems and services that are not directly integrated with the SamurAI Platform.

It is typically used when:

• Telemetry is generated within internal or controlled environments
• A local ingestion point is required to collect and forward telemetry
• Direct integration with the data source is not available

The Local Collector can be deployed on client-managed infrastructure, including virtual environments hosted on-premises or in cloud platforms such as Amazon EC2 and Microsoft Azure.

Cloud Collector

The Cloud Collector is used to collect telemetry from cloud-based services and platforms.

It is typically used when:

• Telemetry is accessed directly from the source using methods such as APIs, cloud storage, or push-based ingestion
• Data is stored in cloud storage or provided by SaaS platforms
• Integration does not require a client-deployed component

The Cloud Collector retrieves or receives telemetry from cloud services and transfers it to the SamurAI Platform.

How are collectors used?

The type of collector required depends on how the telemetry is sourced:

• Local Collector is used when a locally deployed ingestion point is required to collect and forward telemetry
• Cloud Collector is used when telemetry can be accessed directly from cloud services, APIs, or cloud storage

In many cases, the appropriate collector is determined automatically as part of the integration configuration.

How do SamurAI Collectors fit into the platform?

SamurAI Collectors are part of the telemetry ingestion layer within the SamurAI Platform.

• Collectors receive telemetry from source systems
• Data is securely transferred to the SamurAI Platform
• Telemetry is ingested, normalized, and processed for detection and response

This architecture enables consistent telemetry collection across hybrid environments, regardless of where systems are hosted.

Next steps

• Review the Supported Integrations and associated Integration Guides to determine the required collector type. Each Integration Guide includes details on whether a Local Collector or Cloud Collector is used, and this is also shown in the SamurAI Portal during integration setup.

• You can also work directly in the SamurAI Portal to explore and configure integrations.

To continue and for additional information for each collector type:

• SamurAI Local Collector
• SamurAI Cloud Collector

3.1 - Local Collector

What is the Local Collector?

The SamurAI Local Collector is a deployable component that enables the collection and secure transfer of telemetry data from client-controlled environments to the SamurAI Platform.

It is used when a local ingestion point is required to collect and forward telemetry from systems that are not directly integrated with the platform.

Multiple Local Collectors can be deployed by a client as necessary to support scaling, segmentation of data sources, or architectural requirements.

What does the Local Collector do?

The Local Collector performs the following functions:

• Receives telemetry from systems within the client environment
• Processes and forwards data to the SamurAI Platform
• Supports multiple ingestion methods, such as syslog and log forwarding mechanisms
• Securely transmits data to the SamurAI Platform
• Buffers data locally during temporary connectivity interruptions

The Local Collector integrates with the broader SamurAI telemetry ingestion architecture, alongside cloud-based and API-driven collection methods.

How does the Local Collector work?

The Local Collector operates as an intermediary between source systems and the SamurAI Platform.

• Telemetry is generated by systems within the client environment
• Data is forwarded to the Local Collector
• The Local Collector receives and prepares the data for ingestion
• Data is securely transmitted to the SamurAI Platform
• The platform processes and analyzes the telemetry

Depending on the integration type, the Local Collector supports both push and pull data collection models.

Where can the Local Collector be deployed?

The Local Collector can be deployed within environments, including:

• On-premises virtual infrastructure (for example VMware vSphere or Microsoft Hyper‑V)
• Cloud-hosted virtual machines (for example Amazon EC2 or Microsoft Azure)
• NTT Smart Data Platform (SDPF)

This flexibility allows the Local Collector to be positioned close to telemetry sources while maintaining secure connectivity to the SamurAI Platform.

What data sources are supported?

The Local Collector can ingest telemetry from a range of systems, including:

• Network infrastructure (for example firewalls and proxies)
• Servers and operating systems
• Identity and authentication systems
• Security tools that generate log-based telemetry

Telemetry is typically forwarded using syslog or supported log forwarding methods.

What is the data flow?

The Local Collector participates in the SamurAI ingestion pipeline as follows:

• Receives telemetry from source systems
• Forwards data securely to the SamurAI Platform
• Data is ingested, normalized, and processed for detection and response

When should the Local Collector be used?

The Local Collector is typically used when:

• Telemetry originates from internal or client-controlled environments
• Systems cannot be integrated directly using API-based methods
• A local ingestion point is required due to network or architectural constraints

Who is responsible for the Local Collector?

The client is responsible for the deployment, installation, and configuration of the Local Collector, including the underlying infrastructure (for example virtual machine, storage, networking, and cloud-hosted environments such as Amazon EC2 or Microsoft Azure).

The client is also responsible for configuring data sources to forward telemetry to the Local Collector and ensuring ongoing connectivity between the Local Collector and the SamurAI Platform.

The SamurAI team is responsible for providing and maintaining the Local Collector software and ensuring its integration with the SamurAI Platform.

The SamurAI platform monitors the health and availability of the Local Collector and will notify registered users if any issues are detected. Once issues are resolved, a notification will confirm the return to a healthy state.

If the SamurAI team identifies that a Local Collector is undersized or under heavy load, we will liaise with the client to determine the appropriate next steps, which may include adjustments to allocated resources or deployment architecture.

What’s Next?

Review the requirements to determine what is needed before deployment and configuration of a Local Collector.

3.1.1 - Requirements

What you need to get started

• Access to the SamurAI Portal and your specific tenant.
• A supported deployment platform for the Local Collector. Supported hypervisors and cloud platforms are listed below.
• A virtual machine that meets the minimum virtual machine requirements.
• The required network changes to meet the Collector connectivity requirements.
• A static IP address for the Collector and DNS server IP addresses, unless you use DHCP.
• Access to the products where you need to make the changes described in the relevant integration guide.

Supported hypervisors

Supported cloud platforms

Minimum virtual machine requirements

Connectivity required for the Collector

The Collector requires connectivity to the resources listed below. Update security controls, such as firewall rules, proxy settings, and DNS configuration, as needed to allow the required communications.

What’s next?

You now understand the supported deployment platforms, minimum virtual machine requirements, and required connectivity. Proceed to Deployment.

3.1.2 - Deployment

The need for a Local Collector depends on the product being integrated with the SamurAI platform. This is indicated in the relevant Product Integration Guide.

Create, configure and download a Collector

1. Log in to the SamurAI Portal, select Telemetry, and then select Collectors from the main menu.
2. Select Create Collector.
3. Select Local Collector.
4. Complete the fields as required.

5. Select Create Collector.
6. Select the Collector by clicking the name provided in step 4.
7. Select Download.

The files you download depend on the deployment platform.

• Configuration

  • ISO — Collector-specific configuration file.
  • Required for all virtual-machine deployments. Mount this ISO when the Collector starts for the first time so that it can configure and register with the SamurAI platform.

• Cloud init

  • AWS — Cloud-init data for an AWS instance.
  • Azure — Cloud-init data for an Azure virtual machine.
  • SDPF — Cloud-init data for an NTT Smart Data Platform (SDPF) instance.

• Virtual machine

  • OVA — Virtual appliance package for VMware vSphere and Proxmox VE.
    • Includes the virtual disk image and virtual-machine configuration.
  • VMDK — Virtual disk image for VMware vSphere.
    • For manual deployment; it requires manual virtual-machine configuration.
  • VHDX — Virtual hard-disk image for Microsoft Hyper-V.
  • KVM bundle — Virtual-machine package for KVM-based environments.
    • The bundle contains the files required to deploy the Local Collector on a KVM platform.

8. Download the Collector configuration ISO file and the file required for your selected deployment platform.

Install a Collector

Select the section relevant to your deployment platform:

• VMware vSphere
• Microsoft Hyper-V
• Proxmox VE
• KVM-based environments
• Amazon EC2
• Azure Virtual Machine
• NTT Smart Data Platform (SDPF)

VMware vSphere

Follow the VMware documentation:

• Deploy a Virtual Machine from an OVF or OVA File in the VMware Host Client

1. When prompted for a virtual-machine name, use a meaningful name, for example samurai-nttsh-collector.
2. Select the Local Collector OVA file downloaded from the SamurAI Portal.
3. Ensure the virtual machine is configured to use UEFI firmware.
4. Configure CPU, memory, storage, and networking in accordance with the Minimum Virtual Machine Requirements.

After deployment, configure the virtual machine to use the Local Collector configuration ISO file. Refer to VMware documentation:

• Configure a Datastore ISO File for the CD/DVD Drive

1. Select the Collector configuration ISO file downloaded from the SamurAI Portal when prompted to select an ISO file.
2. Ensure that the CD/DVD drive is connected when the virtual machine starts.
3. Power on the virtual machine.

Microsoft Hyper-V

Follow Microsoft documentation:

• Create a virtual machine in Hyper-V

1. When prompted for a virtual-machine name, use a meaningful name, for example samurai-nttsh-collector.
2. Configure the virtual machine to use UEFI firmware.
3. Configure memory and networking in accordance with the Minimum Virtual Machine Requirements.
4. When prompted to connect a virtual hard disk, select the VHDX file downloaded from the SamurAI Portal.
5. Attach the Collector configuration ISO file to the virtual DVD drive and ensure that the drive is connected at startup.
6. Start the virtual machine.

Proxmox Virtual Environment

Follow the Proxmox documentation:

• Import Wizard

1. Create or select storage to use as the import source.
2. Use the OVA/OVF import workflow to import the Local Collector OVA file downloaded from the SamurAI Portal.
3. Ensure that the imported virtual machine is configured to use UEFI firmware.
4. Configure CPU, memory, storage, and networking in accordance with the Minimum Virtual Machine Requirements.

Import the Local Collector configuration ISO file to Proxmox:

1. Navigate to Datacenter and select Storage.
2. Select the storage location where you want to store the ISO file.
3. Select ISO Images.

4. Select Upload.
5. Select the Local Collector configuration ISO file and upload it using the default settings.

Configure the Local Collector virtual machine to use the configuration ISO file:

1. Select the Local Collector virtual machine, select Hardware, and then select Add.

2. Select CD/DVD Drive.

3. Select Use CD/DVD disk image file (ISO), locate the Local Collector configuration ISO file, and then select Add.

4. Confirm that the network interface is available as Network Device (net0).
5. Start the virtual machine.

KVM-based environments

This section applies to KVM environments, including platforms that use libvirt, QEMU/KVM, or another KVM management interface. Because KVM implementations and management interfaces differ, follow the documentation provided by your KVM platform for the virtual-machine creation and import workflow.

Prerequisites:

1. Download the Collector configuration ISO file for the Collector you created.
2. Download the Local Collector KVM bundle from the SamurAI Portal.
3. Extract the KVM bundle.

Use your KVM platform documentation to create or import a virtual machine using the extracted Local Collector image.

When creating or configuring the Local Collector virtual machine:

1. Configure the virtual machine to use UEFI firmware.
2. Configure CPU, memory, storage, and networking in accordance with the Minimum Virtual Machine Requirements.
3. Attach the Local Collector configuration ISO file as a virtual CD/DVD drive.
4. Ensure the virtual CD/DVD drive is connected when the virtual machine starts for the first time.
5. Start the virtual machine.

For guidance on KVM virtual-machine configuration, refer to the documentation for your management platform. Examples include:

• libvirt domain XML format
• Red Hat Enterprise Linux: Managing virtual devices

Amazon EC2

Prerequisite steps:

1. Download the AWS cloud-init.yaml file from Create, configure and download a Collector. You will use this file during EC2 instance deployment.

Follow Amazon documentation to launch an EC2 instance:

• Launch an instance

Apply the following adjustments while following the Amazon documentation:

1. Select Ubuntu as the AMI.
2. Select the latest supported Ubuntu AMI.
3. Select an instance type that meets the Minimum Virtual Machine Requirements.
4. Configure the key pair and network settings according to your organisation’s policies. Ensure network settings fulfil the Connectivity required for the Collector.
5. In Configure storage:
   • Set the root volume to at least 64 GiB.
   • Add a secondary volume of at least 500 GiB, sized in accordance with the Minimum Virtual Machine Requirements.

6. In Advanced details, paste the contents of the AWS cloud-init.yaml file into User data. Do not select User data has already been base64 encoded.
7. Complete the remaining instance configuration according to your organisation’s requirements and the Amazon documentation.

Azure Virtual Machine

Prerequisite steps:

1. Download the Azure cloud-init.yaml file from Create, configure and download a Collector. You will use this file during Azure virtual-machine deployment.

Follow Microsoft documentation to create an Azure virtual machine:

• Create a virtual machine

Apply the following adjustments while following the Microsoft documentation:

1. Under the Basics tab, select Ubuntu Server 22.04 LTS as the image.
2. Under the Basics tab, select a suitable size that meets the Minimum Virtual Machine Requirements.
3. Under the Disks tab, add one data disk of at least 500 GiB, sized in accordance with the Minimum Virtual Machine Requirements.

4. Under the Advanced tab, paste the contents of cloud-init.yaml into the Custom data field.

NTT Smart Data Platform (SDPF)

Prerequisite steps:

1. Download the SDPF cloud-init.yaml file from Create, configure and download a Collector. You will use this file during instance creation.

Follow NTT documentation to create a server instance:

• Create an instance

Apply the following adjustments while following the NTT documentation:

1. When selecting the image, select the latest Ubuntu 24.04 official image.
2. When selecting compute series and size, select a suitable specification that meets the Minimum Virtual Machine Requirements.
3. Add a separate data disk of at least 500 GB, sized in accordance with the Minimum Virtual Machine Requirements.

4. When selecting the logical network, ensure that it fulfils the Connectivity required for the Collector. This typically requires an Internet Gateway, logical network, subnet, and potentially firewall rules that allow the Collector’s required outbound connectivity.
5. In the Post-install script field, select Direct Input and paste the contents of the cloud-init.yaml file.

Deleting a Collector

To delete a Local Collector:

1. In the SamurAI Portal, select Telemetry and then Collectors.
2. Select the relevant Collector.
3. On the right side of the relevant Collector, select More Options () and then select Delete Collector.
4. Review the warning. To confirm the destructive action, enter DELETE and select Delete Collector.

Replacing a Collector

If a Local Collector virtual machine is lost because of corruption or damage, such as a major storage failure, delete the existing Collector in the SamurAI Portal, discard the old virtual-machine image, and create a new Collector by following the installation process.

What’s next?

You have now deployed and configured your Local Collector.

Refer to Local Collector Details for information about validating Collector status and additional configuration.

3.1.3 - Local Collector Details

Validate Collector Status

1. Click Telemetry and select Collectors from the main menu

2. Select the relevant Collector from the presented list

3. View Status

After you provision a Collector VM and start it, it will go through a process of installing updates and modules specified in the configuration ISO file which you downloaded. The time taken for this process is dependent on factors like the speed of the hardware you are running the Collector on and connectivity to the repositories that it downloads updates from. In some cases this process can take around 30 minutes.

If you have any problems, please submit a ticket via the SamurAI Portal.

Collector Email Notifications

By default email notifications are enabled. The SamurAI platform sends email notifications to registered users when a Collector is reported as Critical (e.g. the SamurAI platform cannot communicate to the Collector) however this is customizable by users for any Collector status.

Enable or Disable Email Notifications

1. Click on More Options () to the right of the table
2. Select Notifications
3. Toggle the setting to enable or disable by selecting the bell icon. Alternatively you can select the default setting
4. Click Save

You can also achieve this per individual Collector by:

1. Click on More Options () to the left of the Collector
2. Select Notifications
3. Toggle the setting to enable or disable by selecting the bell icon. Alternatively you can select the default setting (send notification).
4. Click Save

What’s next?

The next step is to start configuring integrations which will allow the SamurAI platform to start receiving your telemetry data.

Select Integrations Overview for more information on integrations and where to start.

If you require high availability for your collector, this can be achieved using the capabilities of your virtualization platform.

3.2 - Cloud Collector

What is a Cloud Collector?

The SamurAI Cloud Collector enables the collection and secure transfer of telemetry data from cloud-based services and platforms to the SamurAI Platform.

It is used when telemetry can be accessed directly from the source without requiring a locally deployed component.

The Cloud Collector is a platform-managed component that integrates with supported services to retrieve or receive telemetry data.

Multiple Cloud Collectors may be used as part of a deployment, depending on the integration design and architecture.

What does the Cloud Collector do?

The Cloud Collector performs the following functions:

• Retrieves or receives telemetry from cloud-based services and platforms
• Supports multiple integration methods depending on the data source
• Securely transfers telemetry to the SamurAI Platform
• Enables ingestion of telemetry without requiring client-managed infrastructure

The Cloud Collector operates as part of the SamurAI telemetry ingestion architecture, alongside Local Collectors.

How does the Cloud Collector work?

The Cloud Collector integrates directly with supported services to access telemetry data.

• Telemetry is generated by cloud services or external platforms
• The Cloud Collector receives or retrieves telemetry using the appropriate integration method
• Data is securely transferred to the SamurAI Platform
• The platform ingests, processes, and analyzes the telemetry

Depending on the integration type, the Cloud Collector supports both push and pull data collection models.

How is telemetry accessed?

The Cloud Collector supports multiple integration methods depending on the source system:

• API-based collection – telemetry is retrieved directly from service APIs (for example SaaS or cloud security platforms)
• Cloud storage ingestion – telemetry is read from cloud storage (for example AWS S3 or Azure Blob Storage)
• Push-based ingestion – telemetry is sent directly to the platform over HTTP (for example Splunk HTTP Event Collector)

The method used is determined by the supported integration and data source.

Where is the Cloud Collector deployed?

The Cloud Collector is a platform-managed component. It does not require software to be deployed on client-managed infrastructure.

Where a cloud provider deployment is required for a supported integration, deployment-specific configuration and provisioning steps are described in the relevant Deployment guide.

It integrates directly with supported services to access telemetry data.

When should the Cloud Collector be used?

The Cloud Collector is typically used when:

• Telemetry is available from cloud-based services or SaaS platforms
• Data can be accessed directly via APIs, cloud storage, or push-based ingestion
• No local ingestion point is required

Who is responsible for the Cloud Collector

The Cloud Collector is managed as part of the SamurAI Platform and does not require deployment or maintenance within the client environment.

The SamurAI team is responsible for the operation, health, and availability of the Cloud Collector.

The SamurAI platform monitors the status of the Cloud Collector and will notify registered users if any issues are detected. Once issues are resolved, a notification will confirm when a healthy state has been restored.

The client is responsible for configuring each integration and ensuring that required data sources remain accessible. This includes setting up and maintaining the required credentials, permissions, connection details, and cloud-provider configuration described in the relevant Integration and Deployment Guides.

The client is also responsible for reviewing Collector status and responding to configuration issues that prevent telemetry from being collected or accessed.

What’s next?

Review Deployment to understand how to create and deploy a Cloud Collector.

3.2.1 - Deployment

The need for a Cloud Collector is based on the specific product being integrated with the SamurAI platform. This will be clearly indicated within the Product Integration Guide.

Create a Cloud Collector

1. From the SamurAI Portal, click Telemetry and select Collectors from the main menu

2. Select Create Collector

3. Select Cloud collector

4. Complete the fields as required.

5. Select Create Collector

6. Follow the relevant section below based on your provider:

• Microsoft Azure
• Amazon Web Services (AWS)
• Splunk HTTP Event Collector

Microsoft Azure

1. Click Deploy to Azure and you will be redirected to the Microsoft Azure login.

2. An Azure Resource Manager (ARM) template will be launched, follow the steps and complete the necessary fields within the template:

Project Details

Instance Details

3. Select Next

4. Select Review and Create

5. Upon creation your Collector status will be updated to Healthy.

6. You can now refer to the relevant Product Integration Guides.

Amazon Web Services (AWS)

1. Click Launch Stack and you will be redirected to the AWS login.

2. Login to your AWS account with administrative permissions.

3. The SamurAI cloud formation template will be displayed.

4. If you have an existing S3 Bucket enter the name within the Parameters section under Enable SamurAI ingestion on existing S3 bucket. If you have no existing S3 bucket, leave this field blank and a new S3 bucket will be created.

5. If you are integrating Cisco Umbrella, be sure to update Cisco Umbrella under the Parameters section to Yes.

6. Click Create Stack.

7. Upon creation of the stack your Collector status will be updated to Healthy.

8. You can now refer to the relevant Product Integration Guides.

Additional required steps when using an existing bucket

1. Add the following to the bucket policy, please update the json with the correct bucket name.

 {
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::600502389717:user/samurai-xdr-s3-reader-user"
    },
    "Action": [
        "s3:GetObject",
        "s3:ListBucket"
    ],
    "Resource": [
        "arn:aws:s3:::BUCKET_NAME",
        "arn:aws:s3:::BUCKET_NAME/*"
    ]
}

2. Create an Event Notification in the bucket properties.

3. Enter an Event Name for the notification, leave the Prefix and Suffix boxes blank.

4. Select All object create events

5. Under Destination, select SNS Topic and select the SNS topic that was created by the Cloud Formation Template from the drop down and click Save Changes.

Splunk HTTP Event Collector

1. If you selected this option you will be presented with the following information:

• API URL
• Token

Copy these entries as you will need them when completing your integration.

2. Select Close.

Deleting a Collector

If you need to delete a Cloud collector you can do so by following the steps below:

1. From your SamurAI Portal click Telemetry and select Collectors from the main menu
2. Select the relevant collector from your list
3. On the right hand side of the relevant collector, click on More Options () and select Delete Collector
4. The following warning will appear: ‘Warning: This is a destructive action and cannot be reversed.’. To ensure you intended to delete the collector you will need to type DELETE in the window and select Delete Collector

What’s next?

You should now have a Cloud Collector running.

Refer to Cloud Collector Details for information on validating Collector Status and details.

3.2.2 - Cloud Collector Details

Validate Collector Status

1. Select Telemetry and Collectors from the main menu

2. Select the relevant Collector from the presented list

3. View Status

Collector Email Notifications

By default email notifications are enabled. The SamurAI platform sends email notifications to registered users when a Collector is reported as Critical (e.g. the SamurAI platform cannot communicate to the Collector) however this is customizable by users for any Collector status.

Enable or Disable Email Notifications

1. Click on More Options () to the right of the table
2. Select Notifications
3. Toggle the setting to enable or disable by selecting the bell icon. Alternatively you can select the default setting
4. Click Save

You can also achieve this per individual Collector by:

1. Click on More Options () to the left of the Collector
2. Select Notifications
3. Toggle the setting to enable or disable by selecting the bell icon. Alternatively you can select the default setting (send notification).
4. Click Save

What’s next?

The next step is to start configuring integrations which will allow the SamurAI platform to collect your telemetry data.

Select Integrations Overview for more information on integrations and where to start.

4 - 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 traffic 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 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.

1. Deployment on virtual system(s)
2. 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.

4.1 - Requirements

What you need to get started

• Access to the SamurAI Portal and your specific tenant.
• A supported deployment platform for the NTA. Supported hypervisors and cloud platforms are listed below.
• An NTA virtual machine that meets the recommended specifications for the required monitoring throughput.
• Network changes required to meet the NTA communication requirements.
• A static IP address for the NTA management interface and DNS server IP addresses, unless you use DHCP.
• Access to configure traffic mirroring to the NTA monitoring interface.

Supported hypervisors

Supported cloud platforms

Amazon Web Services support

For AWS deployment, the NTA requires AWS Nitro instances that support traffic mirroring. For more information, refer to:

• Instances built on the AWS Nitro System
• Traffic mirror sources

Recommended specifications

NTA sizing is based on the expected monitored network throughput. Select the NTA size that meets your required throughput.

Communication requirements

The NTA requires connectivity to the resources listed below. Update security controls, such as firewall rules, proxy settings, and DNS configuration, as needed to allow the required communications.

What’s next?

You now understand the supported deployment platforms, NTA sizing requirements, and required communications. Proceed to SamurAI NTA Deployment.

4.2 - Deployment

Deployment considerations

Traffic source

The NTA is a passive device. It relies on customer infrastructure to send a copy of network traffic to the NTA monitoring interface. When deploying an NTA in a virtual environment or on Amazon EC2, consider the following requirements to achieve effective traffic monitoring and minimise performance impact.

Resource allocation

Ensure the NTA meets the recommended specifications. In some circumstances, the allocated resources may not be sufficient. We may recommend changes after the NTA is deployed and traffic throughput has been assessed.

Multi-NTA deployments

If expected network throughput exceeds the capacity of one NTA, deploy multiple NTAs to maintain coverage.

Network topology and segmentation

Map the virtual network topology and identify the optimal deployment location for the NTA. Consider both:

• East-west traffic between workloads on the same virtual switch, virtual network, or Amazon VPC.
• North-south traffic between internal and external networks, such as internet-facing web traffic.

Traffic visibility

A copy of monitored traffic must be sent to the NTA monitoring interface.

Recommended traffic sources include:

• Client-to-internet traffic.
• Client-to-client traffic.
• Client-to-server traffic.

Traffic that is typically not useful for NTA monitoring includes:

• High-volume encrypted traffic where the NTA cannot inspect the payload.
• SAN and backup traffic.

Capture traffic by configuring network mirroring or traffic monitoring for the selected deployment platform.

Virtual environments

Network mirroring on a virtual switch copies traffic from one or more source ports to a destination mirror port. Connect that destination to the NTA monitoring interface. In virtualised environments, the implementation may use port mirroring, SPAN, promiscuous mode, or a platform-specific monitoring capability.

Figure 1: The NTA in a virtual environment

Amazon EC2

For Amazon EC2 deployments, use VPC Traffic Mirroring to copy traffic from an Elastic Network Interface (ENI) to the NTA monitoring interface.

Figure 2: The NTA running on AWS

Create, configure and download an NTA

1. Log in to the SamurAI Portal, select Telemetry, and then select Network Traffic Analyzer from the main menu.
2. Select Create.
3. Complete the fields as required.

4. Select Create NTA after completing the relevant fields.
5. Select the NTA by clicking the NTA Name used in step 3.
6. Select Download.

The files you download depend on the selected deployment platform.

• Configuration

  • ISO — NTA-specific configuration file.
    • Required for all NTA deployments. Mount this ISO when the NTA starts for the first time so that it can configure and register with the SamurAI platform.

• Cloud init

  • AWS — Cloud-init data for an Amazon EC2 instance.

• Virtual machine

  • **OVA - Virtual appliance package for VMware vSphere and Proxmox VE (includes disk images)
  • VMDK — Virtual disk image for VMware vSphere manual deployment (not needed if using the OVA).
  • VHDX — Virtual hard-disk image for Microsoft Hyper-V.
  • **KVM bundle — — Virtual-machine package for KVM-based environments

7. Download the NTA configuration ISO file and the file or files required for the selected deployment platform.

NTA installation

Select the section relevant to your deployment platform:

• VMware vSphere
• Proxmox VE
• Microsoft Hyper-V
• KVM-based environments
• Amazon EC2

VMware vSphere installation

Follow the VMware documentation:

• Deploy a Virtual Machine from an OVF or OVA File in the VMware Host Client

1. Provide a meaningful virtual-machine name.
2. Select the NTA OVA file downloaded from the SamurAI Portal. Select the appropriate E1000 or E500 variant for the target environment.
3. Ensure the virtual machine is configured to use UEFI firmware.
4. Configure CPU, memory, storage, and both virtual network interfaces in accordance with the recommended specifications.

After deployment, mount the NTA configuration ISO file. Refer to VMware documentation:

• Configure a Datastore ISO File for the CD/DVD Drive

1. Select the NTA configuration ISO file downloaded from the SamurAI Portal.
2. Ensure the CD/DVD drive is connected when the virtual machine starts.
3. Confirm that Network Device (net0) is connected to the management network.
4. Confirm that Network Device (net1) is connected to the network or port group that receives mirrored traffic.
5. Start the virtual machine.
6. Continue to Deployment status.

Proxmox VE installation

Follow the Proxmox documentation:

• Import Wizard

1. Create or select storage to use as the import source.
2. Use the OVA/OVF import workflow to import the NTA OVA file downloaded from the SamurAI Portal. Select the appropriate E1000 or E500 variant for the target environment.
3. Ensure the imported virtual machine is configured to use UEFI firmware.
4. Configure CPU, memory, storage, and both virtual network interfaces in accordance with the recommended specifications.

Import the NTA configuration ISO file to Proxmox:

1. Navigate to Datacenter and select Storage.
2. Select the storage location where you want to store the ISO file.
3. Select ISO Images.

4. Select Upload.
5. Select the NTA configuration ISO file and upload it using the default settings.

Configure the NTA virtual machine to use the configuration ISO file:

1. Select the NTA virtual machine, select Hardware, and then select Add.

2. Select CD/DVD Drive.

3. Select Use CD/DVD disk image file (ISO), locate the NTA configuration ISO file, and select Add.

4. Confirm that Network Device (net0) is connected to the management network.
5. Confirm that Network Device (net1) is connected to the network or bridge that receives mirrored traffic.
6. Start the virtual machine.
7. Continue to Deployment status.

Microsoft Hyper-V installation

Follow Microsoft documentation:

• Create a virtual machine in Hyper-V

1. Provide a meaningful virtual-machine name.
2. Create the NTA as a Generation 2 virtual machine.
3. Configure CPU, memory, storage, and two virtual network adapters in accordance with the recommended specifications.
4. When prompted to connect a virtual hard disk, select the NTA VHDX file downloaded from the SamurAI Portal.
5. Attach the NTA configuration ISO file to the virtual DVD drive and ensure the drive is connected at startup.
6. Connect Eth0 to the management network.
7. Connect Eth1 to the virtual switch or network that receives mirrored traffic.
8. Start the virtual machine.
9. Continue to Deployment status.

KVM-based environments installation

This section applies to KVM environments, including platforms that use libvirt, QEMU/KVM, Open vSwitch, or another KVM management interface. The exact workflow for creating or importing a virtual machine and configuring traffic mirroring differs by KVM management platform. Follow your platform’s documentation for these actions.

Prerequisites:

1. Download the NTA configuration ISO file for the NTA you created.
2. Download the NTA KVM bundle.
3. Extract the KVM bundle.

Use your KVM platform documentation to create or import a virtual machine from the extracted NTA image.

When creating or configuring the NTA virtual machine:

1. Configure the virtual machine to use UEFI firmware.
2. Configure CPU, memory, system disk, and data disk in accordance with the recommended specifications.
3. Add two virtual network interfaces.
4. Connect the first interface to the management network, which must allow the required outbound connectivity.
5. Connect the second interface to a dedicated monitoring network, virtual switch, bridge, or port that receives mirrored traffic.
6. Attach the NTA configuration ISO file as a virtual CD/DVD drive.
7. Ensure the virtual CD/DVD drive is connected when the virtual machine starts for the first time.
8. Start the virtual machine.
9. Continue to Deployment status.

Refer to the documentation appropriate for your KVM environment:

• libvirt domain XML format
• Red Hat Enterprise Linux: Managing virtual devices
• Open vSwitch: Basic configuration and port mirroring

Amazon EC2 installation

Prerequisites:

1. Download the AWS cloud-init.yaml file from Create, configure and download an NTA. You will use this file during EC2 instance deployment.

Follow Amazon documentation to launch an EC2 instance:

• Launch an instance

Apply the following adjustments while following the Amazon documentation:

1. Select Ubuntu as the AMI.
2. Select the latest supported Ubuntu 24.04 Server AMI.
3. Select an instance type that meets the recommended specifications.
4. Configure the key pair and network settings according to your organisation’s policies. Ensure network settings fulfil the communication requirements.
5. Configure storage according to the system-disk and data-disk requirements for the selected NTA size.
6. In Advanced details, paste the contents of the AWS cloud-init.yaml file into User data. Do not select User data has already been base64 encoded.
7. Complete the remaining instance configuration according to your organisation’s requirements and the Amazon documentation.
8. Configure VPC Traffic Mirroring so that the selected traffic is sent to the NTA monitoring interface.
9. Continue to Deployment status.

Deployment status

After deploying the NTA, view deployment progress and status in the SamurAI Portal.

1. Log in to the SamurAI Portal.
2. Select Telemetry, and then select Network Traffic Analyzer from the main menu.
3. Select the relevant NTA.
4. Under General, the Status initially displays as Provisioning.
5. Review Deployment Status, which displays deployment phases and timestamps. Each completed phase is shown in green.

6. When NTA deployment is complete, Status initially displays as Not Healthy while individual components start. The status changes to Healthy when startup is complete, which can take approximately five minutes.

Configure traffic mirroring

After deployment, determine the NTA monitoring interface before configuring traffic mirroring.

1. Log in to the SamurAI Portal.
2. Select Telemetry, and then select Network Traffic Analyzer from the main menu.
3. Select the relevant NTA.
4. Select System Information and review Network to identify the Management and Monitoring interfaces. Record each MAC address and confirm that it matches the relevant hypervisor or AWS configuration.
5. Configure traffic mirroring to send the required traffic to the NTA monitoring interface. Refer to your deployment platform documentation because mirroring implementations differ between environments.

Useful vendor documentation includes:

VMware vSphere

• Working with port mirroring

Microsoft Hyper-V

The following Microsoft documentation uses Microsoft Defender for IoT examples, but its traffic-mirroring concepts also apply to NTA deployments:

• Traffic mirroring overview
• Configure traffic mirroring with a Hyper-V virtual switch

KVM-based environments

Use the traffic-mirroring capability of the KVM platform, virtual switch, bridge, or network fabric that carries the traffic you want to monitor. Examples include Open vSwitch port mirroring and platform-specific bridge or switch mirroring.

• Open vSwitch: Basic configuration and port mirroring

Amazon EC2

• What is Traffic Mirroring?

Detection testing

After deploying the NTA, validate that network traffic is monitored and analysed correctly.

The NTA includes a built-in test detection signature that triggers on ICMP Echo Request traffic with a payload size of 333 bytes. This allows you to validate end-to-end traffic visibility and detection without affecting normal operations.

Generate test traffic

Generate ICMP traffic using one of the methods below.

Windows

From Command Prompt, run:

ping -l 333 X.X.X.X

Linux

From a terminal, run:

ping -s 333 X.X.X.X

Cisco routers and switches

Use Extended Ping and specify a datagram size of 361 bytes.

The Extended Ping datagram size includes:

• IP header: 20 bytes.
• ICMP header: 8 bytes.
• ICMP payload: 333 bytes.

Total: 361 bytes.

Expected detection

After generating the test traffic, the NTA should generate the following alert:

Test Alert using ICMP size 333 for NTA validation

View this alert in the NTA Alerts panel. Refer to Alerts for more information.

• The detection is triggered by the ICMP Echo Request. A reply from the destination host is not required.
• The test signature does not affect traffic analysis or detection accuracy and is safe to use for validation.

If no alert is generated

If no alert is shown after generating the test traffic, verify the following:

• Test traffic was generated from a network segment monitored by the NTA.
• Traffic from the source network is mirrored to the NTA.
• The NTA is receiving traffic on the monitoring interface.
• The ICMP Echo Request used the correct 333-byte payload size.
• Sufficient time has been allowed for the alert to be processed and displayed.

If all checks pass and no alert is generated, submit a ticket through the SamurAI Portal.

Delete an NTA

To delete an NTA:

1. In the SamurAI Portal, select Telemetry, and then select Network Traffic Analyzer.
2. Select the relevant NTA.
3. Select the More options icon and then select Delete NTA.
4. Review the warning. To confirm the destructive action, enter DELETE and select Delete NTA.

What’s next?

You have now deployed and configured your NTA. Refer to NTA Details.

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

1. Login to the SamurAI Portal

2. Click Telemetry and select Network Traffic Analyzer from the main menu

3. A list of all NTAs will be displayed. Various fields are displayed based on information you included when creating the NTA.

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

NTA Status

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.

This widget may also include status messages of individual components of the NTA, this will assist with identifing any problems and should be included if you submit a ticket with the SamurAI SOC.

NTA Notifications

The SamurAI platform will send email notifications to registered users should your NTA status change to Critical. Once any issues have been resolved, you will also be notified again when rectified. Users have the option to enable or disable notifications.

Additionally the SamurAI platform will send push notifications if the SamurAI Portal is installed as an app (Progressive Web App - PWA) and notifications are configured within user settings.

Enable or Disable Notifications

1. From the NTA Table view, click on More Options () to the right of the NTA View
2. Select Notifications Settings
3. Toggle the setting to enable or disable by selecting the relevant icon per listed NTA. Alternatively you can select the default setting (send notification).
4. Click Save.

You can also achieve this per individual NTA by:

1. From the NTA Table view, click on More Options () to the left of the NTA.
2. Select Notifications
3. Toggle the setting to enable or disable by selecting the relevant icon. Alternatively you can select the default setting (send notification).
4. Click Save.

System Information

The System Informatiom panel displays important NTA system information and metrics including:

System

Storage

Network Management

Network Monitoring

Metrics

All metrics displayed are by default over the past 2 hours however you can adjust via the Time Picker

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

5 - SamurAI Endpoint Agent

What is the SamurAI Endpoint Agent?

The SamurAI Endpoint Agent is a light weight, software component installed on an endpoint (such as a workstation or server) providing deep visibility and enabling SamurAI Managed Detection and Response across your endpoints. Capabilities include:

Telemetry Data Collection

• Standardized and targeted telemetry data collection independent of operating system (e.g the agent utilizes a custom Sysmon configuration, specifically tuned for the SamurAI Platform applied to Microsoft Windows to optimize event collection and analysis).
• Eliminates the need for 3rd party integrations to the SamurAI Platform (e.g winlogbeat agents installed on the Microsoft Windows OS).
• Eliminates the need for any endpoint configuration in telemetry collection.

Detection

• Leverages the SamurAI Real-Time Engine for detection of threats.
• We apply our global threat intelligence feeds to enrich data with context about known malicious actors, emerging threats, and attack patterns enhancing accuracy and speed of threat detection.
• Leverages the SamurAI Hunting Engine for automated and analyst driven threat hunting.

Investigate

• Provides a powerful query capability (osquery) with real-time visibility into endpoints (e.g query for installed browser extensions to help analysts detect potential persistance mechanisms used by threat actors and accelerate investigations).
• Event driven threat hunting to investigate, validate and contextualize a threat/incident.

Respond

• Provides incident response tooling and aids endpoint forensics.

What’s Next?

Review the SamurAI Endpoint Agent Support and Pre-requisites.

5.1 - Support and Pre-requisites

Listed below are supported Operating Systems (OS) and communication pre-requisites. If you do not see a specific OS version listed please reach out to us.

Supported Operating Systems

Communication Pre-Requisites

Ensure endpoints with the SamurAI Endpoint Agent installed have the following network connectivity:

What’s Next?

Now you have an understanding of support and pre-requisites, learn about Download and Installation.

5.2 - Download and Installation

Before you begin download and installation of the SamurAI Endpoint Agent you must first select how you wish to manage SamurAI Endpoint Agent Updates and decide settings for the SamurAI Endpoint Agent for Windows.

1. From the SamurAI Portal select Telemetry and click SamurAI Endpoint Agent

Upon first navigation to this page, the following will be displayed:

Figure 1: SamurAI Endpoint Agent settings

Updates

Select how you want to manage SamurAI Endpoint Agent updates:

• Auto Managed : Auto updates of agents is enabled by default, this option will automatically update agents as new versions are released without any action needed on your part.
• Self Managed : Select this option should you wish to manage updates yourself. See Self Managed for more information.

SamurAI Endpoint Agent for Windows

1. Determine whether to Accept Microsoft Sysinternals Software Licence Terms (Sysmon EULA).

2. If you accept the Sysmon EULA, you can select to Install Sysmon if missing

3. Click Apply SamurAI Endpoint Agent Settings

The SamurAI Endpoint Agent and Sysmon

For enhanced telemetry on Windows, the SamurAI Endpoint Agent optionally leverages Microsoft System Monitor (Sysmon), a vital component for collecting detailed process and system activity. Read more about Sysmon from Microsoft Documentation.

Sysmon is not bundled with the SamurAI Endpoint Agent therefore if you Accept Microsoft Sysinternals Software Licence Terms (Sysmon EULA) upon installation of the SamurAI Endpoint Agent, sysmon will be downloaded and installed or updated silently using standard Microsoft provided installation flags.

The SamurAI Endpoint Agent leverages a custom Sysmon configuration tuned and maintained by the SamurAI detection engineering team. This provides:

• Noise reduction: a default Sysmon deployment generates an extremely high volume of data, our tuned configuration filters out unnecessary events which are irrelevant for SamurAI Managed Detection and Response.

• High Fidelity detections: we selectively enable and enrich valuable event IDs (e.g process creation, network connections, registry modification etc) aligned with the MITRE ATT&CK framework.

• Consistency across environments: ensures standardized event coverage across deployments.

• Ongoing Tuning: we regularly update the configuration to reflect emerging attacker techniques, new ATT&CK mappings and lessons learned.

What’s Next

You can now proceed to Agent Download

5.2.1 - Download

To download the SamurAI Endpoint Agent follow the steps below:

1. Login go the SamurAI Portal

2. Click Telemetry and select SamurAI Endpoint Agent from the main menu

3. Click Installers

4. Select the relevant installer based on your operating system and click Download

Verify Download

Microsoft Windows

To ensure your download has not been corrupted or tampered with, you can validate it’s checksum using the built-in Windows tool ‘certutil’.

Run the following command and view the checksum to ensure it matches the installer within the SamurAI Portal:

c:\certutil -hashfile spiral-windows-amd64.msi sha256

example:

c:\certutil -hashfile spiral-windows-amd64.msi sha256
SHA256 hash of spiral-windows-amd64.msi:
85193aa8c4e7a1eaba1da36251bc6ea78e0e62b2
CertUtil: -hashfile command completed successfully.

What’s Next?

Based on your Operating System jump to the relevant SamurAI Endpoint Agent installation guide:

• Microsoft Windows

5.2.2 - Microsoft Windows

Manual Installation

Locate the Windows MSI installer file that you previously downloaded and double-click, a small progress window will appear which does not require any interaction.

Additional commands are available using the command line as outlined below. All commands can be used in combination as required.

Proxy Support

If your organization leverages a proxy then use the following command during install:

Example:

msiexec.exe /i "spiral-windows-amd64.msi" PROXY=http://<ip>:<port>

This will create a key in the Windows registry: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\NTT\Spiral with a parameter Proxy with the proxy from the command line.

This can be added/changed/removed at a later time, if so the SamurAI Endpoint Agent services must be restarted.

Quiet Mode Installation

Use the the following command for quiet mode installation (i.e no progress window is displayed):

msiexec.exe /i "spiral-windows-amd64.msi" /qn

Verbose Installation Logs

If you wish to view installation logs you can use the following command to save logs to a file for review:

Example:

msiexec.exe /i "spiral-windows-amd64.msi" /L*vx output.txt

Validate installation

After the installation has completed, there will be a Spiral entry under installed programs.

Figure 1: Windows apps & features

The installation folder is C:\Program Files\Spiral with full control permissions to SYSTEM and Administrators.

This should apply to all subfolders and files with one exception osquery.db which will have an additional read access to Everyone/World.

Figure 2: SamurAI Endpoint Agent Windows install path and files

There will also be a service named Spiral running.

Figure 3: Task manager service

The Spiral process will also be visible.

Figure 4: Task manager process

Additionally osquery processes will be running.

Figure 5: osquery processes

The following files are created by the installer:

C:\Program Files\Spiral\bin\spiral.exe: The Spiral launcher (more details what it does and functions further down)
C:\Program Files\Spiral\bin\osqueryd.exe: The Osqueryd binary that will be launched by spiral.exe (more details further down)
C:\Program Files\Spiral\config.yaml: The configuration for Spiral launcher
C:\Program Files\Spiral\secret: The embedded tenant/enrollment secret
C:\Program Files\Spiral\ca.pem: Spiral CA bundle used to communicate with the SamurAI platform. Will download new if missing or if outdated. Used by both spiral.exe and osqueryd.exe.

The following files are created by either the Spiral or Osquery process:

C:\Program Files\Spiral\server.crt: Exported server certificate chain from Spiral Node API (typically excluding Root CA). 
C:\Program Files\Spiral\sysmon.xml: The sysmon configuration downloaded from Spiral Node API.
C:\Program Files\Spiral\data\osquery.db: RocksDB data folder used by Osquery for state keeping. Osquery sets this with read access to Everyone/World at intervals.
C:\Program Files\Spiral\data\extensions.load: Purposely left empty
C:\Program Files\Spiral\data\osquery.flags: Osquery startup flags (generated by Spiral), extended configuration is fetched by Osquery over HTTPS.
C:\Program Files\Spiral\data\osquery.log: Stdout/stderr log output from osqueryd.exe
C:\Program Files\Spiral\data\osquery.pid: Osquery PID
C:\Program Files\Spiral\data\osquery.uuid: UUID for this specific node
C:\Program Files\Spiral\data\spiral.log: Stdout/stderr log output from spiral.exe
C:\Program Files\Spiral\data\shell: A folder created if running spiral.exe with "shell" command which is an interactive mode to run Osquery commands.

Dependant on your selection for SamurAI Endpoint Agent for Windows the agent may:

1. Download Sysmon from Microsoft official servers.
2. Install or update Sysmon silently using standard Microsoft provided installation flags.
3. Modify Sysmon with the configuration.

Review Deployed SamurAI Endpoint Agents

Review and Manage within the SamurAI Portal.

5.3 - Management

View Nodes

To view all deployed agents:

1. Login go the SamurAI Portal

2. Click Telemetry and select SamurAI Endpoint Agent from the main menu.

Dashboard

The dashboard panel displays summary information:

• Nodes: the total deployed and seen by the SamurAI platform
• Online: the total currently online (have communicated with the SamurAI platform within five minutes)
• Offline: the total number offline (have not communicated with the SamurAI platform for five minutes)
• Platforms: the total number of platforms i.e Windows / MacOS / Linux

Nodes Table

A table displays all deployed agents with node specific information:

Inactive Node(s)

Nodes communicate with the SamurAI platform every minute and are marked offline if no communication is received after five minutes.

Offline nodes will be visible for 90 days, after this threshold it is deemed to be inactive and purged from the SamurAI platform backend and the current view.

You can view inactive and deleted nodes within the Node History.

Delete Node(s)

You can delete nodes from the table:

1. Select the nodes you wish to Delete
2. Click Actions and select Delete selected nodes
3. To ensure you intended to delete the agents you will need to type DELETE in the field and select Delete
4. The deleted node record will appear under Node History.

Node History

The Node History log displays a table of Deleted Nodes and Purged (deemed inactive) with node specific information:

5.3.1 - Settings and Updates

Settings

You can change the Update and Sysmon EULA selections by clicking Settings from the SamurAI Endpoint Agent view.

• Auto Managed : Auto updates of agents is enabled by default, select this option if you want the agent updates to occur automatically without any action needed on your part.
• Self Managed : Select this option should you wish to manage agent updates yourself.

Updates

Self Managed

If Self Managed is selected a new option entitled Update Tasks is displayed.

Update Tasks

Selecting Update Tasks allows you to configure tasks for updating your deployed agents.

1. Click on Create Update Task

2. Enter a Name for the task e.g Windows 10 Pro Update

3. Toggle whether you wish to Start immediately. If you do not start the task immediately you have the option to update the status at a later date/time. See Update the Task.

4. Select whether you wish to update:

• SamurAI Agent version (the latest version will always be displayed)
• Sysmon version

5. Rate Limit is enabled by default to 5 nodes per 1 minute. Read more about Rate Limiting

6. Once complete, select Review Selection and review your tasks

7. Click on Create Update Task

Rate Limiting

Rate limiting allows you to roll out updates to nodes gradually instead of updating all at once. This controlled approach reduces risk of disruption, avoids overloading networks and ensures that if an unexpected issue occurs, only a small number of nodes are affected.

Rate limiting allows you to configure the number of nodes to update per time duration (which can be set per minute/hour/day).

When rate limiting is recommended:

• Large fleets (typically 500+ nodes)
• Networks with remote sites, VPN’s or limited bandwidth
• Critical workloads where uptime and stability are essential
• Major agent version upgrades or significant configuration changes

When rate limiting may not be necessary:

• Small fleets with a few hundred nodes
• Minor, low-risk updates

View Update Tasks

1. From the SSamurAI Endpoint Agent view, click Update Tasks.

A table displays all Update Tasks with specific information:

Select an Update Task from the list to display status of individual node updates.

A summary will be displayed including:

• Update task status
• Number completed
• Number failed
• Target
• Rate Limit

Additional details for each node are also included:

Update the Task

You can update the State of an Update Task to either Paused or Running.

For example, if you previously set an Update Task NOT to Start Immediately you can set the state to Running to begin the update:

1. From the Update Tasks list select the relevant Update Task

2. Select More Options ().

3. Click Update the Task

4. Select the State to Paused to pause the update task or to Running to begin or resume the update task.

5.4 - Uninstall

Follow the steps to uninstall the SamurAI Endpoint Agent based on your Operating System:

Microsoft Windows

1. Go to Add or remove programs

2. Find Spiral Agent

3. Click Uninstall

4. When uninstalled, program files and registry entries are removed from the endpoint/node, however some files may remain:

   • All files not added by the installer itself such as the Data folder in C:\Program Files\Spiral\Data
   • Files server.crt and sysmon.xml in C:\Program Files\Spiral remain after uninstall.

5. It is safe to delete C:\Program Files\Spiral after the uninstall has completed.

5.5 - FAQ

General

Support

Installation and Setup

Management