| Feature | LMNTRIX NDR | Traditional NDR |
|---|---|---|
| Integrated with XDR | Yes | Siloed |
| Behavioral AI | Yes | Partial |
| Cloud-native visibility | Full | Limited |
| Encrypted traffic detection | Yes | Decrypt required |
| Deception Integration | Native | Not supported |
| Response Automation | Playbooks & AI | Manual |
LMNTRIX Network Detection & Response (NDR)
What is LMNTRIX NDR?
LMNTRIX NDR is a subscription feature of LMNTRIX XDR. LMNTRIX NDR uses a proprietary multi-vector threat detection sensor (NDR network sensor) to detect suspicious ingress and egress communications 24 hours a day, 7 days a week, and 365 days a year. With the application of context provided by the NDR Sensor, the service provides detection of zero-day attacks, known threats, data leakage detection, post-infection detection of bots on hosts & pre-infection detection of malware that have evaded the customer’s preventive security controls.
The LMNTRIX NDR also relies on advanced analytics and machine learning algorithms to analyze network traffic within traditional perimeter controls to identify abnormal behaviors and patterns indicative of a security threat.
- It is deployed as a virtual or physical appliance to network choke points with high-value digital assets/servers
- Scales to support small through to enterprise networks
- Continuous network monitoring and management by our Cyber Defense Center (CDC)
- Integrates with the LMNTRIX Intelligence real-time TIP solution
- Automatic incident creation in the event of a confirmed validated breach. Incidents are contained automatically or where system is unsure, incidents are confirmed by our Intrusion Analysts firsts before containment and remediation actions take place or escalated to the client/partner.
- Includes optional monitoring for OT networks where applicable
Does LMNTRIX NDR support advanced malware detection?
LMNTRIX NDR provides the following advanced malware detection capabilities:
- Detection and alerting on inbound malware targeting Customer’s network through e-mail attachments and web traffic.
- Detection against inbound malware in unencrypted and a subset of encrypted e-mail attachments. Attachments are executed and inspected for maliciousness and, if necessary, alerted on.
- Detection and alerting on existing malware infections that have evaded preventative security controls.
- Detection and alerting on malware in unencrypted web content. Web content is inspected in real time, observed for malicious behaviour and, if necessary alerted on.
What is best practice deployment architecture for the LMNTRIX NDR sensor?
The LMNTRIX NDR sensor appliance is deployed on customer’s premises in SPAN or TAP mode after the customer’s perimeter security controls (Firewalls, IPSs, WAF, DDoS, SWG, SMG, etc). It needs to at minimum monitor the internal interface of the perimeter firewall and optionally for east-west threat detection monitor the server VLAN/segment. Once deployed, the NDR Sensor is tuned to automatically connect to the LMNTRIX XDR where it’s managed and monitored by the LMNTRIX CDC. Connectivity between the LMNTRIX XDR and the NDR sensor is secured using high security industry standard encryption. All ten (10) threat detection engines constantly monitor traffic flow to detect pre-infection of malware, post-infection of bots on hosts, data leakage and alert the CDC of potential breaches.
What are the best placement strategies for the LMNTRIX NDR?
The most important decision when deploying NDR sensors is locating strategic areas for capturing network traffic. Once key network segments are identified, the NDR sensors can be deployed and optimized to meet security and administrative needs.
One more important thing to consider while deploying NDR sensors is that it should be placed after the Customer’s network perimeter controls (Firewalls, IPSs, email and web security solutions) to ensure the data is cleansed before reaching the NDR sensor.
The NDR sensor requires a SPAN/Mirror/Tap connection to passively capture packets as the data traverses your network. It is important to capture network traffic at key network segments to fully benefit from the threat detection capabilities of the NDR sensor.
The most obvious network segment to cover is the Internet Egress Gateway. The sensor can be deployed almost anywhere in your network, but most common deployments include:
- Monitoring egress traffic as it leaves the network at the perimeter/firewall.
- Internal core to monitor communication of internal traffic flows to/from servers.
- In the DMZ to capture inbound traffic to servers
- Within the corporate cloud (Amazon Web Services for example) to monitor inbound/outbound traffic flows from a corporate cloud.
What are the NDR sensor deployment requirements?
The NDR sensor is pre-configured and shipped as an appliance, VMWare, Hyper-V or KVM based on the client requirement.
Once the network segments have been identified for monitoring, the next step is to deploy the NDR sensor. The NDR sensors are typically deployed with one management interface with bi-directional access to the LMNTRIX XDR via a VPN and one or more capture interfaces. The management interface needs to be assigned a private IP to ensure it is accessible from the LMNTRIX XDR to allow for remote management.
The capture interfaces monitor traffic coming from a mirror, SPAN, or tap interface on the network infrastructure. An NDR sensor can have one or more capture interfaces depending on your architecture. Where VPN is not available, then direct Internet access is supported by opening ports to the NDR sensor from the LMNTRIX XDR.
What are the NDR sensor hardware requirements?
LMNTRIX NDR relies on the customer to provision a SPAN, mirrored or physical tap on their internal switch that will provide bi-directional flow traffic and that is configured to capture traffic from one or more monitored ports, and copy this traffic to the interface on the NDR sensor. Tap must support bidirectional copy to a single interface.
The number of NICs required depends on the network segments to be monitored. The NDR sensor must have a minimum of 2 NICs, one of which is used for establishing management connectivity to the LMNTRIX XDR and for integrating the NDR sensor with the customer’s AD server. The other NIC is used to connect to the SPAN/mirrored port on the switch. A NDR sensor can have 2 or more NICs where multiple segments need to be monitored.
The NDR sensor hardware requirements are based on the throughput requirements of your SPAN/TAP port. Below table lists the minimum hardware configuration requirements based on various throughputs. We would recommend scoping more than the minimum requirements to allow for growth.
No. CPU Cores | SPAN/TAP (Mbps) |
2 core | 200 Mbps |
4 cores | 300 Mbps |
8 cores | 600 Mbps |
12 cores | 800 Mbps |
16 cores | 1 Gbps |
20 cores | 1.2 Gbps |
24 cores | 1.4 Gbps |
CPU / SPAN Throughout Guide
The server hardware we used in our testing was as follows:
- 12 GB RAM – 5 million concurrent connections
- 2 GB RAM – 1 million concurrent connections
- VMWare ESXi 5.5 with dedicated virtual cores
- Intel E5-2637
- NICs – vmxnet3
The memory amount is based on the number of connections it needs to inspect.
The performance increase it is not linear and this may vary depending on the virtual CPU cores allocated, CPU type, RAM, traffic blend as well as hypervisor release and configuration. We believe that the most efficient performance is achieved at 8 virtual cores.
What are the NDR sensor network access requirements?
The NDR sensor needs bi-directional communication with the LMNTRIX XDR. Connectivity between the LMNTRIX XDR and the NDR sensor is secured using industry standard high security encryption and digital certificates. The NDR sensor does not support SSL decryption of the management traffic.
The NDR sensor also requires access to our XDR via the Internet to receive updates.
Two (2) forms of access are supported between the NDR sensor and the LMNTRIX XDR:
- IPSec VPN: We establish a VPN between the LMNTRIX XDR and the client’s Internet perimeter (VPN termination point) or optionally we establish a VPN directly to the NDR sensor.
- The below ACL needs to be created to enable internet access for the LMNTRIX NDR sensor.
Direction | Source | Destination | Service/Port | Remarks |
Outbound | NDR sensor IP address | Any | http(80), https(443) | To enable the internet access for NDR sensor |
- The below ACLs need to be created to allow bi-directional communication between the LMNTRIX XDR and the LMNTRIX NDR sensor. These rules are used for updating the multiple engines and remote sensor management by the LMNTRIX CDC.
Direction | Source IP | Destination IP | Port | Remarks |
Inbound | xxx.xxx.xxx.xxx/22 | NDR sensor IP address | TCP/22 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx/22 | NDR sensor IP address | TCP/256 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx/22 | NDR sensor IP address | TCP/443 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx/22 | NDR sensor IP address | TCP/3978 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx/22 | NDR sensor IP address | TCP/4488 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx/22 | NDR sensor IP address | TCP/8305 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx/22 | NDR sensor IP address | TCP/18191 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx/22 | NDR sensor IP address | TCP/18192 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx/22 | NDR sensor IP address | TCP/18208 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx/22 | NDR sensor IP address | TCP/18209 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx/22 | NDR sensor IP address | TCP/18211 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx/22 | NDR sensor IP address | TCP/28443 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx/22 | NDR sensor IP address | ICMP | To access NDR sensor from LMNTRIX XDR |
Outbound | NDR sensor IP address | xxx.xxx.xxx.xxx/22 | TCP/257 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | xxx.xxx.xxx.xxx/22 | TCP/389 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | xxx.xxx.xxx.xxx/22 | TCP/443 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | xxx.xxx.xxx.xxx/22 | TCP/3978 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | xxx.xxx.xxx.xxx/22 | TCP/8081 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | xxx.xxx.xxx.xxx/22 | TCP/8305 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | xxx.xxx.xxx.xxx/22 | TCP/8446 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | xxx.xxx.xxx.xxx/22 | TCP/9090 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | xxx.xxx.xxx.xxx/22 | TCP/18191 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | xxx.xxx.xxx.xxx/22 | TCP/18210 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | xxx.xxx.xxx.xxx/22 | TCP/18264 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | xxx.xxx.xxx.xxx/22 | ICMP | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | xxx.xxx.xxx.xxx/32 | TCP/5000 | To access LMNTRIX XDR from NDR sensor |
Note: xxx.xxx.xxx.xxx: request IP from LMNTRIX
- Direct Internet Access: With this option communication to the LMNTRIX NDR sensor is established through the Internet without the use of a VPN, although all of the communication between the sensor and the LMNTRIX Platform is encrypted by default. An unused and routable Internet IP address is required to be setup with one to one NAT.
Below are the pre-requisites for establishing communication between LMNTRIX XDR and the LMNTRIX NDR sensor without VPN:
- Bi-direction static NAT of NDR sensor with Public IP address.
- Below ACL needs to be created to enable internet access from the NDR sensor.
Direction | Source | Destination | Service/Port | Remarks |
Outbound | NDR sensor IP address | Any | http(80), https(443) | To enable the internet access for NDR sensor |
- The below ACLs need to be created to allow bi-directional communication between the LMNTRIX XDR and the LMNTRIX NDR sensor. These rules are used for updating the multiple engines and remote sensor management by the LMNTRIX CDC.
Direction | Source IP | Destination IP | Port | Remarks |
Inbound | xxx.xxx.xxx.xxx | NDR sensor Public IP address | TCP/22 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx | NDR sensor Public IP address | TCP/256 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx | NDR sensor Public IP address | TCP/443 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx | NDR sensor Public IP address | TCP/3978 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx | NDR sensor Public IP address | TCP/4488 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx | NDR sensor Public IP address | TCP/8305 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx | NDR sensor Public IP address | TCP/18191 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx | NDR sensor Public IP address | TCP/18192 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx | NDR sensor Public IP address | TCP/18208 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx | NDR sensor Public IP address | TCP/18209 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx | NDR sensor Public IP address | TCP/18211 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx | NDR sensor Public IP address | TCP/28443 | To access NDR sensor from LMNTRIX XDR |
Inbound | xxx.xxx.xxx.xxx | NDR sensor Public IP address | ICMP | To access NDR sensor from LMNTRIX XDR |
Outbound | NDR sensor IP address | 35.175.38.253 | TCP/257 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | 35.175.38.253 | TCP/389 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | 35.175.38.253 | TCP/443 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | 35.175.38.253 | TCP/3978 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | 35.175.38.253 | TCP/8081 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | 35.175.38.253 | TCP/8305 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | 35.175.38.253 | TCP/8446 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | 35.175.38.253 | TCP/9090 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | 35.175.38.253 | TCP/18191 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | 35.175.38.253 | TCP/18210 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | 35.175.38.253 | TCP/18264 | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | 35.175.38.253 | ICMP | To access LMNTRIX XDR from NDR sensor |
Outbound | NDR sensor IP address | 34.192.245.94 | TCP/5000 | To access LMNTRIX XDR from NDR sensor |
Note: xxx.xxx.xxx.xxx: request IP from LMNTRIX
What is the NDR sensor performance impact on our network?
All events generated by the ten (10) NDR engines are sent to the LMNTRIX XDR using an API where they are automatically validated and turned into incidents where applicable.
There is no concept of packet capture or connection log in the NDR sensor. All events are exclusively threat related and they are meta data only (like an IDS alert). As such the volume of threat data passed from the sensor to the XDR platform is minimal and has inconsequential impact on the Customer(s) Internet connection.
The LMNTRIX NDR service does not retain any events or logs. The LMNTRIX XDR receives meta data from the sensors which are automatically validated by the XDR and if deemed a threat they are contained. If unsure, alerts are converted into incidents where an intrusion analyst conducts further investigation including endpoint analysis before containment and remediation actions take place.
LMNTRIX NDR is not a log management nor a compliance solution as we do not collect or retain any logs.
How does the NDR sensor detect encrypted attacks
The use of Secure Sockets Layer (SSL) or Transport Layer Security (TLS) encryption for Internet and enterprise traffic is growing steadily. Modern applications that use SSL communications by default – such as SharePoint, Exchange, WebEx, Salesforce.com and Google Apps – are commonplace and rapidly growing. Even hosted and mobile email applications such as Gmail, Yahoo and Zimbra utilize SSL encryption by default in today’s workplace environments.
LMNTRIX highly recommends clients to complete their visibility into the encrypted SSL-based traffic with the use of either dedicated appliances or by turning on the SSL Inspection feature of their existing Firewalls.
A holistic encrypted traffic management strategy that considers the various division needs, policies to be established, regulatory compliance requirements, and data privacy mandates is essential for all clients.
The NDR sensor cannot natively detect threats within encrypted traffic and instead it relies on external solutions to deliver decrypted content of SSL flows. This enables LMNTRIX to deliver the necessary visibility into both SSL and non-SSL network traffic.
Supported 3rd party SSL decryption solutions to manage encrypted traffic include those from Garland Technology, Blue Coat (SSL Visibility Appliance and ProxySG solution), Radware (Content Inspection Director (CID) and AppXcel), A10 Networks (Thunder SSLi) and Gagamon (GigaSMART).
Some NetGen Firewall vendors such as Palo Alto Networks support SSL inspection and the ability forward on the clear SSL flows off box to a 3rd party solution such as the LMNTRIX NDR sensor.
What are the LMNTRIX responsibilities as it relates to the operation of the LMNTRIX NDR?
The following provides a list of LMNTRIX responsibilities:
- Provide a license to use the LMNTRIX NDR service consistent with the parameters of your purchase.
- If applicable, LMNTRIX authorized partner will provide some of the hardware components required to implement the service.
- Configuration of the NDR sensor ready for deployment by LMNTRIX authorized channel partner or Customer
- Provide remote assistance for implementing the Service. Implementations will need to be scheduled through an assigned project manager.
- Establishing management connectivity between the NDR sensor and the LMNTRIX XDR.
- Fine Tuning the policies of various Engines to reduce false positives.
- Perform all the required maintenance of the software running on the NDR sensor.
- Perform remote health monitoring of Service components that are deployed in your environment.
- Provide 24-hour access to our Cyber Defense Center (“CDC”) so that you may ask questions related to the Service. While LMNTRIX will do our best to answer your questions immediately, some inquiries will result in a ticket for the Senior Intrusion Analyst Team which will be addressed during LMNTRIX’ normal business hours, Monday through Friday, 8:00-5:00 U.S. Eastern Standard Time excluding U.S. holidays (“Normal Business Hours”).
What are client responsibilities as it relates to the operation of the LMNTRIX NDR?
The following provides a list of Client responsibilities:
- Providing an installation environment as required for the Customer-controlled components of the Service. This may include, but is not necessarily limited to, one or more of the following: rack space, power, cooling, network connectivity, a provisioned cloud environment, virtual machine licenses, and hardware to support a virtual sensor.
- Procurement of sensor hardware as per throughput requirements and number of network segments to be mirrored. (Hardware specifications need to be validated by LMNTRIX).
- Locating strategic areas for capturing network traffic to deploy the sensor(s).
- Allotment of private IP address for the NDR sensor management interface for bi-directional communication with the LMNTRIX XDR and LMNTRIX specified 3rd party vendor threat update clouds. Provide default gateway details for the NDR sensor to connect to the LMNTRIX XDR, the Internet and for AD integration.
- Create an access rule on Perimeter firewall(s) for allowing bi-directional access to sensor private IP address.
- Identifying the specific systems or Internet Protocol (“IP”) address ranges that are to be monitored, and providing updates to LMNTRIX when changes to systems that are to be monitored occur.
- Configuring SPAN port or TAP where SPAN is not available.
- Ensuring that the NDR subscription covers the corresponding network throughput.
What are the NDR sensor threat detection engines?
The NDR sensor employs ten (10) threat detection engines. These are:
What is the LMNTRIX NDR Context Awareness Engine?
Context awareness engine removes the traffic origin anonymity by mapping the IP addresses to user’s identities. This helps deliver context to the CDC based on identity instead of only IP addresses. When the Context Awareness Engine identifies a source and destination, it shows the IP address of the user or machine with a name.
Context Awareness Engine gets identity data seamlessly from Microsoft Active Directory using AD Query. It works based on querying the Active Directory Security Event logs and extracting the user and machine mapping to the network address from them.
The NDR sensor can be integrated with AD server using either AD administrator or non-AD administrator credentials.
Below procedure describes on how to integrate AD Using Context Awareness AD Query without Active Directory Administrator privileges on Windows Server 2008 and above
AD Query uses Windows Management Instrumentation (WMI) to query Active Directory Domain Controllers for the Security Event logs. To handle the remote calls to the Domain Controllers, AD Query uses Distributed COM (DCOM) technology. In order to connect to a remote computer using WMI, WMI permissions should be granted, and DCOM settings and WMI namespace security settings should enable the connection. After a user/group can connect to the Domain Controller using WMI, it should have the permissions to read the Security Event logs.
There are four main stages:
- Creating a user/group and granting it DCOM permissions.
- Giving the user/group WMI permissions.
- Adding read permissions to the Security Event logs.
- Create a user with Distributed COM and Event reading permissions
- Create a domain user (or use an existing one).
- Add this user to the built-in domain groups: Distributed COM Users, Event Log Readers, and Server Operators.
- Make sure that DCOM remote launch activation permissions and remote access permissions are granted for the Distributed COM Users group (as described in Securing a Remote WMI Connection)):
- Make sure the user is a member of the following groups:
- Distributed COM Users
- Domain Users
- Event Log Readers
- Server Operators
- Grant the user WMI permissions
Note: This step should be performed on each Domain Controller.
- Run Windows Management Instrumentation (WMI) console:
Go to Start menu – click on Run… – type wmimgmt.msc – click on OK/press Enter.
A.Right-click on WMI Control – click on Properties.
B. Go to the Security tab – expand Root.
C. Select CIMV2 – click on Security button.
D. Add the domain user that you have created to work with AD Query.
Grant him the Remote Enable permission.
E. Click on Advanced button.
F. Make sure that the permissions for the domain user apply to This namespace and subnamespaces.
G. Click on OK and close the dialogs.
4. Restart WMI service
Note: This step should be performed on each Domain Controller.
Run the Windows Services Manager:
Go to Start menu – click on Run… – type services.msc – click on OK/press Enter.
- Locate the Windows Management Instrumentation service and restart (right-click on the service – click on Restart).
Client Responsibilities:
- Enable the Network connectivity between NDR sensor and AD Server.
- Providing AD service account details for NDR sensor integration with AD server.
What is the LMNTRIX NDR Data Leakage Detection Engine?
The Data Leakage Detection Engine identifies, monitors and detects data transfer through deep content inspection and analysis of transaction parameters such as source, destination, data object and protocol. The intent of the Data Leakage Detection Engine is to detect the unauthorized transmission of confidential information to and from the client network(s).
The Data Leakage Detection Engine captures original data that caused a rule match, including the body of the transmission and attached files. The policy is defined by LMNTRIX to match the data that should be detected from transmission, based on customer’s data policy. A set of defined data types recognizes sensitive forms, templates, and data to be detected. The policy is fine-tuned continuously by LMNTRIX to convert the confidentiality and integrity guidelines of the customer’s organization into automated rules. New data types are created to match the customer specific data monitoring requirements.
Even without any data leakage policies defined by the client, the Data Leakage Detection Engine by default uses pre-defined Data Types and rules developed by LMNTRIX to provide advanced Data Leakage Detection capability. The NDR sensor monitors all the traffic containing data and being sent through supported protocols. This includes users sending data via a HTTP proxy or a mail server, the Data Leakage Engine monitors the data before it leaves the organization. The Data Leakage Engine scans the traffic, including email attachments, for data that should be protected from being sent outside the organization. This data is recognized by protocol, source, destination, and complex Data Type representations.
The Data Leakage Detection Engine captures traffic and scans it against the Data Leakage Detection policy. If the data in the traffic matches a rule in the policy, an incident is logged and a ticket automatically generated on the LMNTRIX XDR.
LMNTRIX Responsibilities:
- CDC to configure and fine tune the Data Leakage Detection Policy.
Client Responsibilities:
- Specify any key words and Data types to monitor for data leak detection.
- Provide Email address domains list.
- Provide list of internal networks or hosts.
What is the LMNTRIX NDR Web Security Engine?
Today, the businesses struggle to keep up with the security challenges because of the wide adoption of social media and web applications by the people. The usage of internet applications creates a new set of challenges such as Malware threats, Bandwidth hogging and a Loss of Productivity. As with internet applications, access to the non-work related website browsing can open networks to a variety of security threats and have a negative effect on employee productivity.
Web Security Engine provides detection capabilities by using the Granular Application Control, Largest Application Library, by detecting the employee’s internet access to inappropriate and illicit websites, by detecting bandwidth issues and it also helps in decreasing the legal liability and improves organizational security.
The LMNTRIX CDC constantly fine tunes the Web Security policy to match the customer’s environment. Traffic that matches the active pre-defined policy creates an event which further creates an incident on the LMNTRIX XDR.
LMNTRIX Responsibilities:
- CDC to configure and fine tune the Web Security Engine Policy.
Client Responsibilities:
- Specify any custom URL and application categories to monitor.
What is the LMNTRIX NDR Intrusion & Web Application Detection Engines?
The Intrusion & Web Application Detection Engines analyse traffic contents to find potential risks to the customer’s network. This engine provides, detection of specific known exploits; detection of vulnerabilities including both known and unknown exploit tools; detection of protocol misuse which in many cases indicates malicious activity or potential threat; detection of outbound malware communications, detection of tunneling attempts; detection of applications which are bandwidth consuming or may cause security threats to the network such as peer to peer and Instant Messaging applications.
The Intrusion & Web Application Detection Engines constantly update the library of detections to stay ahead of emerging threats. During service inception, detections are activated as per Intrusion & Web Application Detection policy to allow processes to focus on handling the most important traffic and to report on only the most concerning threats. The LMNTRIX CDC constantly fine tunes the policies which activate only the detections that are tuned to match the customer asset type on each segment. For example, a segment of Windows machines do not require monitoring for Mac or Unix based threats. This ensures that we detect only the attacks that most threaten the customer’s network and help reduce false positives. Furthermore, Intrusion & Web Application Detection profiles enable LMNTRIX to configure a set of detections per NDR sensor. Detections are activated with Medium or Higher severity level, Medium or lower performance impact and Medium or higher confidence level.
Exceptions are configured on the NDR sensor for all the traffic monitored by the sensor or at a specific detection level, to detect certain traffic from being identified by the Intrusion & Web Application Detection policies or specific detection. Intrusion & Web Application Detection signatures are updated hourly using an automated schedule. Traffic that matches the active pre-defined signatures creates an event which further creates an incident on the LMNTRIX XDR.
LMNTRIX Responsibilities:
- CDC to configure and fine tune the Intrusion & Web Application Detection Engine Policies.
Client Responsibilities:
- Specify internally hosted applications.
- Specify the DNS servers, SNMP server, NIS servers, LDAP Servers, HTTP Proxy servers, Anti-Virus definition servers, Mail relay server IP addresses and Vulnerability scanner IP addresses.
What is the LMNTRIX NDR Emulation Engine (sandbox)?
The Emulation Engine provides the NDR sensor with pre-infection defense approach. It detects unknown malware, targeted attacks and zero-day attacks. Cyber-threats continue to increase and now it is easier for criminals to create new malware that can easily bypass existing protections. Cyber criminals can change the malware signature and make it virtually impossible for signature based products to protect networks against infection. Emulation Engine can detect new malware and zero-day vulnerabilities and targeted attacks.
Emulation Engine gives networks the necessary detection capabilities against unknown threats in files that are downloaded from the internet or attached to emails. Emulation is being performed by opening files on more than one virtual computer with different operating system environments. The virtual computers are closely monitored for unusual and malicious behavior, such as an attempt to change registry keys or run unauthorized process. Emulation can be conducted on the LMNTRIX Cloud or on the NDR sensor. However, when conducted on the cloud, CPU level emulation (not available on the on-premise sensor) is able to detect far many more advanced threats not possible by the standalone NDR sensor. Furthermore, if on premise emulation is necessary then LMNTRIX highly recommends the use of a dedicated appliance for the Emulation Engine, to help minimize the performance impact on the NDR sensor.
When the analysis is conducted on the LMNTRIX Cloud, all the communication between the NDR sensor and the LMNTRIX Cloud is secured using SSL encryption.
What is the LMNTRIX NDR Anti-Malware Engine?
The Anti-Malware Engine provides the NDR sensor with pre-infection defense approach where it helps in detecting known viruses and file transfers. Malware is a major threat to network operations that has become increasingly dangerous and sophisticated. The Anti-Malware Engine scans incoming and outgoing files to detect threats such as worms and Trojans. It also delivers pre-infection detection capability from malware contained within files.
The Anti-Malware Engine detects infections from incoming malicious file types such as Word, Power Point, Excel and Adobe). Incoming files are classified on the NDR sensor and compared against the known malicious files. The Anti-Malware Engine also detects malware downloaded from the internet by monitoring access to the sites that are known to be connected to malware. Accessed URLs are checked by the NDR sensor caching mechanisms or sent to the cloud repository to determine if they are permissible or not.
Detections are activated with Medium or Higher severity level, Medium or lower performance impact and Medium or higher confidence level. The traffic which matches the pre-defined Anti-Malware criteria is immediately logged and incidents generated in the CDC ticketing system.
What is the LMNTRIX NDR Bot Detection Engine?
The Bot Detection Engine provides the NDR sensor with post-infection bot detection approach. A Bot is a malicious software that can invade the endpoint machine. There are many infection methods such as opening attachments that exploit a vulnerability and accessing a web site that results in a malicious download.
When a bot infects a computer, it takes control over the computer and neutralizes its Anti-Virus defenses. Bots are difficult to detect since they hide within the computer and change the way they appear to Anti-Virus software. It then connects to a Command and control (C&C) center for instructions from cyber criminals. The cyber criminals or bot herders, can remotely control it and instruct it to execute illegal activities without the owner’s knowledge. A single bot can create multiple threats. Bots are often used as tools in attacks known as Advanced Persistent Threats (APT) where cyber criminals pinpoint individuals or Organizations for attack. A botnet is a collection of compromised computers.
The Bot Detection Engine identifies infected machines in the organization by analyzing the network traffic using the inbuilt threat engine. It uses the cloud repository to receive updates and queries it for classification of unidentified IPs and URLs. It detects bot communication to C&C sites and alerts if the sensitive information is stolen or sent out of the organization.
The Bot Detection Engine identifies bot infected computers by correlating multiple detection methods such as by identifying the command and control addresses used by criminals to control bots, by identifying the communication patterns used by each botnet family, by identifying bot behavior such as detecting attack types, such as Spam (leveraging outbound mail analysis) and Click fraud, as well as anomalies (irregular ports, protocols).
Following the discovery of a bot infected machine, the Bot Detection Engine logs the event and an incident is automatically generated on the LMNTRIX XDR for further analysis by the CDC.
What is the LMNTRIX NDR Email Security Engine?
Email Security Engine detects wide variety of virus and malware threats delivered through mail. It offers antivirus detection with both zero-hour and signature based detection. It also offers Email IDS detection against Denial of Service (DoS) and buffer over-flow attacks.
Mail anti-malware detects against a wide range of viruses and malware and includes scans of message content and attachments. Email Security Engine includes a highly-rated anti-malware engine that scans POP3 and SMTP mail protocols. This layer of detection detects a wide range of known virus and malware attacks, and is at the core of the anti-malware defense. The Email Security Engine utilizes Email IDS to effectively detect attacks targeting the messaging infrastructure. Such attacks aim to gain access to the protected network, bring down a piece of the messaging infrastructure, or utilize the messaging infrastructure as a resource for launching new attacks.
What is the LMNTRIX NDR Anti-Spam Engine?
The relentless and unprecedented growth in unwanted email poses an unexpected security threat to the network. As the amount of resources allocated to handling unsolicited emails increases from year to year, employees waste more and more time sorting through unsolicited bulk email commonly known as spam. The Anti-Spam Engine allows LMNTRIX to detect spam that was missed by the clients Mail Security Gateway solution and has now reached the customer’s network.
Anti-Spam Engine identifies spam by analyzing known and emerging distribution patterns. It’s strength lies within its ability to avoid searching for key words and phrases that might classify a legitimate email as spam and instead of focusing on other message characteristics, this method offers high spam detection rate with a low number of false positives. To preserve the personal privacy and business confidentiality, only selected characteristics are extracted from the message envelope, headers and body. Hashed values of these message characteristics are sent to a Detection center cloud for pattern analysis. The Detection center cloud identifies spam outbreaks in any language, message format, or encoding type.
The Anti-Spam Engine performs detection based on features such as Content based Anti-Spam, Mail Anti-Virus, IP reputation Anti-Spam, Block List anti-spam, Zero-hour malware protection and IDS.
Once identified the network spam generating machine, events are logged and followed by the automatic creation of an incident ticket on the LMNTRIX XDR.
What is the LMNTRIX NDR Threat Intelligence Engine?
The NDR sensor Threat Intelligence Engine integrates the LMNTRIX Threat Intelligence Platform (TIP) feed. This feed is updated hourly from the LMNTRIX XDR.
LMNTRIX Intelligence is the LMNTRIX initiative for crowd-sourcing threat intelligence. It is a community based immunity system that aggregates over 300 threat feeds into a single feed and correlates it against all incoming and outgoing communication from a Client’s network seen by the NDR sensor.
Any positive hits on the Indicators of Compromise (IOCs) from the TIP automatically create an incident ticket on the LMNTRIX XDR. The ticket is validated for any false positives by the CDC before escalating to the client.
We know that every day you have everything on the line, and that with so much at risk it can seem like adversaries have all the advantages. Together we can take the power back. Where other cybersecurity providers see a vendor and a customer, we see a united team of defenders who are stronger as one.
I couldn't believe the level of detail during testing using an unannounced red team. In real-time, LMNTRIX analysts were baiting attackers and actively pursuing them in our environment-it was like something out of a movie.
Matt Kraus
IT Manager, Alliance Funding Group
LMNTRIX XDR didn't just do one thing; it covered all the bases: endpoint, network, cloud, mobile, identity, moving target defense and proactive threat hunting. To build this ourselves, we'd need 50 different products, and then we'd need to find security analysts capable of managing them all. The hyper-converged and holistic approach that LMNTRIX takes is a real game changer in my opinion.
Kim Green
CISO, World Market
I appreciate that working with the LMNTRIX team feels collaborative, and they leverage their extensive knowledge of current trends and attack techniques to guide us effectively. With our small team, we lack the resources to constantly research emerging threats—LMNTRIX fills that gap, providing us with vital information that helps us prioritize and refine our security strategy.
Shaun Hay
Group Manager Technology and Systems
LMNTRIX seamlessly integrates with our team, making their analysts an extension of our own resources. Their deep understanding of our environment allows my internal team to focus on other essential security initiatives that drive Dentons' success.
Victor Yeo
Head of Information Security
Our approach to detection is something we take seriously. While many MDR companies can set up a SOC and connect with various technologies to pass on alerts, LMNTRIX stands out by providing the critical context we need. They bridge the gap between us and our tools, delivering insights that truly matter. It's like LMNTRIX is playing chess, while others are just playing checkers.
Eduard Pieters
Chief Information Officer
LMNTRIX stood out in our evaluation as the sole provider that developed its own sophisticated cloud detections instead of merely relying on GuardDuty as an intermediary. Unlike other vendors who claimed capability in managing our cloud alerts, LMNTRIX was the only one that substantiated its capabilities.
Integrating our SIEM with the LMNTRIX XDR platform has provided a more comprehensive view of our security events and alerts across Microsoft 365, Defender, and Azure Active Directory. This integration facilitates quicker and more precise incident responses. The streamlined workflows and reduced manual processes have freed up valuable time, allowing us to address additional security priorities.
John Smith
Director of Cybersecurity and Incident Response
