Settings

Settings offer complete configurability for NDR sensor.

Data Lifetime Configuration

You can set how long specific types of data remain in the NDR by setting a retention period in days. The daily disk reclaim task manages storage according to these settings and the available disk space on the NDR.

Important: If the retention period is too short, large amounts of data may end up in the archived metadata, significantly slowing down metadata searches.

On the Sensor Health dashboard, the Raw Data Time refers to when data, such as PCAPs and metadata, can be retrieved. The data lifetime configuration applies to both archived and uncompressed metadata.

The disk reclaim task cleans up data in the following prioritized order:

• Metadata of low priority

• Metadata for low notification

• Metadata of medium priority

• Raw Packet data for medium notification

• Raw Packet data for high notification

• Metadata for medium notification

• Metadata for high priority

• Metadata data for high notification

• Compressed Metadata

DLM Generations

DLM Generation refers to the classification of data files into age-based groups used by the NDR’s data lifecycle management (DLM) system. Each generation has a defined retention period in days, which determines when files are eligible for reclamation.

Reclaiming is the process of automatically deleting or compressing data to optimize storage. NDR performs reclamation in multiple sweeps, starting with the younger generations first, based on the age cutoffs defined for each file type.

ArtifactType	Priority (Lower is more important)	Very Old Gen cutoff	Old Gen cutoff	Young Gen cutoff	Toddler Gen Cutoff
Compressed Metadata	0	180	90	30	7
Metadata data for high severity notification	1	360	180	90	14
Metadata for low severity notification	7	90	30	0	0
Metadata for medium severity notification	3	180	90	30	3
Metadata of high priority	2	90	60	30	3
Metadata of low priority	8	30	14	0	0
Metadata of medium priority	6	60	30	7	0
Raw Packet data for high severity notification	4	180	90	30	7
Raw Packet data for medium severity notification	5	90	30	0	0

Email Configuration

Email Configuration is the setup of an SMTP server that enables the NDR to send email alerts and system messages.

Note: All registered recipients will always receive an email upon an AI Prevent block, regardless of configuration subscriptions.

• SMTP configuration

  • TLS On/Off (whether to use encrypted emails)

  • SMTP host - A valid SMTP capable host

  • SMTP port - Port of given SMTP host

• Authentication

  • Auth on/off

  • Username/Password (Credentials for SMTP user)

• Subscriptions

  • Notifications: Severities that should trigger emails

  • System messages: Message types that should trigger emails

  • Chain phases: Chain phases to be notified of via e-mail. If a chain steps into one of the selected phases, an email is sent to notify the user

• Email address configuration

  • To: Recipient of notifications

  • From: Distributor of notifications

• Submit saves the configuration to NDR.

• Test will send a test notification email to the recipient's email with the current configuration.

Notification Triggers

The Notification Triggers configuration lets you adjust the conditions under which notifications are triggered. You can define your own Indicators of Compromise (IOCs) and set threshold values for NDR’s detection scripts.

IoC Lists

This section shows all currently deployed custom IoC lists. An IoC is typically a .dat file that contains entries, including IP addresses, domain names, or certificates. If any of these are detected in network traffic, a notification is triggered.

The file must follow a specific format:

• Add comments at the top, but only before the header. Start comment lines with “#”.

• You must include the header line:

  • #fields indicator indicator_type meta.source meta.url meta.do_notice

• Each IoC entry must be on a separate line using tab-separated fields.

• The fields must appear in this exact order:

  • indicator: the observable that should trigger an alert.

  • indicator_type: must be one of the following:

    • Intel::ADDR – triggers the notification ‘Blacklist match IP’

    • Intel::DOMAIN – triggers the notification ‘Blacklist match domain’

    • Intel::FILE_NAME – triggers the notification ‘Blacklist match file’

    • Intel::FILE_HASH – triggers the notification ‘Blacklist match file’

• meta.source: a description of where the indicator came from.

• meta.url: a reference URL for the source.

• meta.do_notice: set to T or F depending on whether a notification should be generated.

Edit Parameters

Some notifications, for example, port scanning, are triggered when a number of events occur in a short period of time. You can adjust these thresholds and time frames.

Select a parameter from the drop-down. It displays the default and overridden values and allows changes.

The table below lists which parameters are linked to which notification categories.

Notification Category	Parameter Name (threshold and time interval
NTLM User Password bruteforce	NTLM bruteforce threshold, NTLM bruteforce time frame
SSH Failed Attempts	SSH failed attempts threshold, SSH failed attempts time frame
Lateral movement and execution	Lateral movement execution threshold, Lateral movement execution time frame
Lateral movement using SMB admin shares	SMB Lateral movement threshold, SMB Lateral movement time frame
Discovery using RPC	RPC discovery threshold, RPC discovery time frame
HTTP Authentication Bruteforce	HTTP bruteforce threshold, HTTP bruteforce time frame
Misconfigured HTTP basic auth client	HTTP misconfigured server threshold, HTTP misconfigured server time frame
P2P Patterns	P2P patterns conn threshold
P2P Ports	P2P ports threshold, P2P ports threshold
DarkNet or Tor activity detected	tor cert threshold, tor cert time frame
OT write rate exceeded	OT write threshold, OT write time frame
OT unknown function codes	OT function code threshold, OT function code time frame
Traceroute detected	traceroute icmp time exceeded threshold, traceroute icmp time exceeded time frame
HTTP crawler detected	HTTP crawler threshold, HTTP crawler time frame
HTTP SQL injection detected	HTTP SQLi threshold, HTTP SQLi time frame
Port scan detected	Scan port threshold, Scan port time frame
Address scan detected	Scan address threshold, Scan address time frame
FTP brute force login detected	FTP bruteforce threshold, FTP bruteforce time frame
SSH Failed Attempts	SSH bruteforce threshold, SSH bruteforce time frame
SMB File Rename	SMB file rename threshold, SMB file rename time frame

User Management

User Management displays the list of current users. As an admin, you can create and delete other users. Once a new user is created, they appear in the user table.

An admin can apply these settings for an existing user:

• Change Password: Modify a user's password if the current password is known.

• Reset Password: Creates a one-time 5-digit PIN for the selected username. The user is then prompted to create a new password change upon their next login.

• Edit Username and Roles: Change the username, add or remove roles.

• Disable MFA: If MFA (Multi-Factor Authentication) is enabled for a user, you can disable it. The user must manually reactivate MFA if required.

Machine Learning Configuration

The machine learning engines adapt and learn by building models from observed traffic patterns in the network. You can control two configurations of the machine learning engines:

Sensitivity

Sensitivity is a measure of how easily an anomaly event triggers a notification. Range: Value between 0 and 1. Close to 1: Makes the anomaly detection hypersensitive, producing more notifications. Close to 0: Makes the detection less sensitive, possibly producing no notifications. Impact: Controls the frequency of anomaly detection notifications based on the sensitivity setting.

Network Group

Network Group allows you to configure machine learning engines for specific network groups. Configuration Options: Each network group can have the two machine learning engines enabled or disabled. If enabled, the sensitivity for each engine can be adjusted separately. Network Group Selector: The Network Group Selector allows users to choose from different network groups when multiple groups are in use.

If only a single network group is in use, the Network Group Selector will not appear. Impact: Customizes the anomaly detection sensitivity for each network group, affecting the number of notifications received.

System Management

The System Management tab allows you to choose NDR system-level settings for data retention, external system integrations, and notification generation.

Logpoint Integration Configuration

Integration allows Logpoint NDR to receive Ms365 and Azure NSG flow logs, which you can also search in the Meta Data Events Search.

Ms365

1. On the dashboard, click the Settings icon and select Logpoint Integration Configuration.

2. Select the Ms365 tab.

3. Enter Client ID, Client Secret ID, and Tenant ID.

4. Click Test to ensure it works.

5. In case the test fails:

   1. Double check all values.

   2. Make sure API permissions have been added, and that Admin consent is granted.

   3. Run another test.

If the test succeeds, click Update.

Azure NSG flow

1. On the dashboard, click the Settings icon and select Logpoint Integration Configuration.

2. Select the Azure tab.

3. Enter Client ID, Client Secret ID, Tenant ID, the Container Name, and the Account URL.

4. Click Test to ensure it works.

5. In case the test fails:

   1. Make sure API permissions have been added, and that Admin consent is granted.

   2. Run another test.

If the test succeeds, click Update.

Syslog

NDR sends notifications and system messages via syslog to the host configured in the third party integration modal.

Netflow

NDR forwards all seen connections via Netflow V9 to the host configured in the third party integration modal.

LDAP

LDAP is used to query objects in Active Directory. In NDR, it enriches host information with details like Distinguished Name (DN) and Windows version. You can configure multiple LDAP integrations for different Active Directories.

To configure LDAP:

• Add a name for the LDAP configuration.

• Enter the host IP address of the Active Directory.

• Provide a valid user in the format domain\\username with appropriate access rights.

• Enter the base domain name in the format DC=domain,DC=local.

LDAP servers are queried one at a time. When a match is found, the remaining servers are not queried.

Testing the Configuration

The configuration window includes a Test option to help verify new or modified LDAP setups. You can test the connection before adding the configuration.

Enter the hostname of a device to search, or leave the field empty to test the connection. If the test is successful, a green confirmation box will appear.

DHCP

DHCP allows NDR to search hostnames for known IP addresses. It provides information, including lease duration, default gateway, and DNS server, collected through passive monitoring of DHCP requests.

To configure DHCP:

• Enter a name for the DHCP configuration.

• Enter the host IP address of the DHCP server.

• Enter the client subnet covered by the DHCP server in CIDR format (e.g., 10.11.12.0/24).

• Enter the domain name for the subnet (e.g., local).

DHCP servers are queried one by one. When a match is found, the remaining servers are skipped.

Testing the Configuration

To test a DHCP configuration, click the Test button while adding or modifying the entry. You can include the IP address of a host for reverse lookup to check if the DHCP server has information about it. If the test is successful, a green confirmation box will appear.

DNS

DNS provides information about a device, including IP address, hostname via reverse lookup, and canonical name. This information helps NDR identify hostnames for specific IP addresses. You can configure as many internal DNS servers as needed.

To configure DNS:

• Enter a name for the DNS configuration.

• Enter the host IP address of the DNS server.

• Enter the subnet that the DNS server covers in CIDR format (e.g., 10.11.12.0/24).

DNS servers are queried one by one. When a match is found, the remaining servers are skipped.

Testing the Configuration

To test a DNS configuration, click the Test button while adding or modifying the entry. You can enter an IP address in the hostToLookup field to perform a reverse lookup. If you are only checking the connection, you can leave the field empty. A green confirmation box will appear if the test is successful.

ServiceNow

ServiceNow integration allows NDR to create incident tickets directly in ServiceNow. You can configure multiple ServiceNow instances, each with its own settings.

To configure ServiceNow:

• Enter a recognizable name for the ServiceNow configuration.

• Choose an integration method:

  • Email, or

  • Username and Password (requires ServiceNow to support REST API requests).

• After entering connection details, specify which severity levels should trigger automatic ticket creation.

Email

For email-based integration, a valid Email Configuration must exist.

• Enter the email address where tickets should be sent.

• Select the severity levels that should trigger ticket creation.

Tickets are sent as incidents in JSON format and include the necessary incident data.

Field Name	Data
correlation id	notification uid
assignment group	the configured assignment group from the servicenow configuration
correlation display	NDR
description	notification data
short description	short notification data
Note that there is no requirement that the target email address is actually part of a ServiceNow installation.
The benefit of using this option over the standard Email Configuration is that the email body will be
specifically formatted with field names native to ServiceNow.

REST

When configuring via username and password, specify an IP address or a resolvable hostname where NDR can reach the ServiceNow instance and the port to use for the connection. Next, specify the username and the password which NDR should use to authenticate to ServiceNow.

MISP

MISP (Malware Information Sharing Platform and Threat Sharing) integration supports only attributes, not events from the MISP data model.

Attributes in MISP are individual network indicators such as:

• Network Indicators: For example, IP addresses, domain names

• System indicators: For example, a string in memory

• Other data indicators like, bank account details.

The MISP integration enables NDR to collect threat intelligence data from external MISP repositories. You can integrate with multiple MISP repos as required and assign each a name.

The integration searches the external MISP data collection and can filter/narrow the collected data from its filter configuration. The collected data will be transformed into an IOC List that is maintained by the MISP integration only.

Configuring MISP Connection

To set up MISP integration, you must specify an IP address or a resolvable hostname that NDR can use to connect to the MISP instance, along with the port number for the connection.

Then, provide the Authentication Keythat NDR must use to authenticate the connection to the external MISP. The Authentication Key is generated in the external MISP instance for the API user.

Configuring the Misp filter

Misp Attributes documentation

Field overview

Each field in filter configuration can have multiple values. They must be separated by commas.

Note: If you want to control which attributes are used for generating IoC lists, then we recommend that you create an NDR tag in MISP installation. Use this tag to mark attributes that are to be included.

• Category

  • Example data

  • Internal reference

  • Targeting data

  • Payload delivery

  • Artifacts dropped

  • Network activity

• Organization

• Type

  • If type field is empty, the search will be populated with all supported types below

  • Not supported types will be ignored

    • supported types

      • filename

      • filename|md5

      • filename|sha1

      • filename|sha256

      • domain

      • email

      • url

      • link

• Tags

  • Example data type:OSINT

Example of MISP filter configuration

Field Name	Data
Category	Network activity,Targeting data,Payload delivery
Organisation	MyOrganisation
Type	domain,email,url,link
Tags	type:OSINT,NDR

Notification Forwarding integrations

The sensor can be set up to forward notifications to other systems. The available integrations are Logpoint, Microsoft Sentinel and a generic notification forwarding.

Logpoint Integration

Integrating with Logpoint enables you to monitor NDR notifications. You can select which notifications to forward based on their severity level.

To configure the sensor to forward notifications to Logpoint navigate to Advanced Settings > Logpoint Integration Configuration.

To add a new configuration:

• Click the add icon, a form should open up

• Fill in all the field information.

  • Sensor Nickname is a field used for you to identify which sensor the notification came from on the Logpoint side.

• Click Create, then the configuration should show up in the list of configurations

To test a configuration:

• Fill in the Logpoint configuration information just as if you were to save it

• Optional: provide a notification UID.

  • Find a notification of interest for the test through the notification search

  • Click the specific notification so that the notification details open

  • Once that has been done the UID of the notification should show in the URL.

  • Copy the value after "uid=" in the URL

Microsoft Sentinel integration

Microsoft Sentinel is a SIEM (Security Information and Event Management) tool. Integrating NDR with Sentinel allows you to monitor notifications in the Sentinel platform along with other security tools.

The integration allows you to choose which notifications get forwarded based on their severity level.

To configure notification forwarding to Microsoft Sentinel:

1. Go to Advanced Settings > All Settings > System Management > Integration Configuration.

2. Open the Notification Forwarding tab.

To add a new configuration:

• Press the green plus button. It opens a form.

• From the Config Type drop down, select Sentinel.

• Fill in all the fields information.

  • NOTE: Sensor Nickname is a field used for you to identify which sensor the notification came from on the Sentinel side

• Press create, then the configuration should show up in the list of configurations

To test a configuration:

• Fill in the Sentinel configuration information just as if you were to save it

• Optional: provide a notification UID.

  • Find a notification of interest for the test through the notification search

  • Click the specific notification so that the notification details open

  • Once that has been done the UID of the notification should show in the URL.

  • Copy the value after "uid=" in the URL

Sensor Phase Configuration

Suspicious network events trigger notification with different severity levels based on:

• How long it has been since NDR started monitoring your network.

• The extent NDR was baselined, such as proper notification rules put in place.

When a baselining milestone is reached, NDR’s baselining phase must be updated. These milestones vary across networks, but typically follow these phases:

Phase	Time Since Deployment	Status

Phase	Time Since Deployment	Status
Pre Production	0-3 months	Creating an overview & remove F/P
Production I	4-12 months	Establishing a baseline
Production II	13+ months	Mastering anomalies

You can change a NDR’s phase in the Sensor Phase Configuration.

To access it:

1. Click on Settings.

2. Select Sensor Phase Configuration.

Changes do not take effect until the sensor is rebooted.

If you change the sensor phase,

• The number of notification categories with 'High' severity increases immediately.

• More notifications are likely to trigger with the severity of 'High', thus more rules are potentially needed to establish a new baseline.

• If AI prevent is enabled, check the blocking events that may occur by going through the 'NDR AI Prevent Configuration'.

User Management

User drop-down

You can find the settings for the current user in the top-right corner. The overview of the user roles has these options:

• Change Password

• Enable Multi-factor Authentication: when enabling MFA a popup will open up when selected from the user drop-down.

• Appearance: change to dark-mode, light-mode or system default.

• Log out

Sensor status and traffic light

Sensor Status provides an overview of the health and operational state of each NDR sensor in your network. Clicking on the Sensor icon displays system information, including:

• CPU, memory, disk usage

• NDR version

• Packets captured

• Searchable metadata

• Other system metrics

The Sensor Status uses a traffic light system to indicate the sensor health:

1. Green: No errors or warnings

2. Yellow: Warnings (high resource usage or packet drops)

3. Red: Errors (detected system issues)

To view current messages, click Sensor and select Show Messages.

If warnings or errors occur, they appear as pop-up messages on the dashboard. The sensor health state and messages are also pushed to the NDR Portal.

Active mirror session

If a mirror session was initiated from the NDR Portal, the NDR logo appears at the bottom. This indicates when the mirror session will expire. Click on the logo to extend the mirror session's lifetime.