Monitor all network communications
Automatically identify and catalog every connected device
Identify unknown threats and zero-day attacks
Detect threats in minutes, not months with real-time network analysis and AI-powered behavioral detection.
Autonomous response capabilities contain threats instantly, preventing lateral movement and data exfiltration.
Gain 100% network visibility with comprehensive traffic analysis and device discovery across all environments.
Unified XDR platform eliminates the need for multiple point solutions and reduces operational complexity.
Intelligent prioritization and automated response free up security teams to focus on strategic initiatives.
On-Premise: Physical and virtual appliances
Cloud-Native: AWS, Azure, Google Cloud Platform
Hybrid: Seamless integration across environments
Edge: Distributed deployment for remote locations
Agentless
Throughput: Up to 100+ Gbps network analysis
Latency: Sub-second threat detection and response
Scalability: Elastic cloud architecture
Storage: Configurable data retention policies
SIEM/SOAR: Splunk, QRadar, Phantom, Demisto
Security Tools: CrowdStrike, Microsoft Defender, Palo Alto Networks
IT Systems: Active Directory, ServiceNow, Slack
Threat Intelligence: Multiple commercial and open-source feeds
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 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.
LMNTRIX NDR provides the following advanced malware detection capabilities:
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.
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:
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.
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:
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.
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:
Direction | Source | Destination | Service/Port | Remarks |
Outbound | NDR sensor IP address | Any | http(80), https(443) | To enable the internet access for NDR sensor |
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
Below are the pre-requisites for establishing communication between LMNTRIX XDR and the LMNTRIX NDR sensor without VPN:
Direction | Source | Destination | Service/Port | Remarks |
Outbound | NDR sensor IP address | Any | http(80), https(443) | To enable the internet access for NDR sensor |
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
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.
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.
The following provides a list of LMNTRIX responsibilities:
The following provides a list of Client responsibilities:
The NDR sensor employs ten (10) threat detection engines. These are:
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:
Note: This step should be performed on each Domain Controller.
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.
Client Responsibilities:
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:
Client Responsibilities:
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:
Client Responsibilities:
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:
Client Responsibilities:
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.
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.
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.
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.
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.
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.
and that means XDR
The choice is yours: see LMNTRIX in an on demand demo or set up a customized demo or request a quote.