Sensor Deployment Options
The Hunting Maturity Model (HMM)
- Threat hunting using historical packet data
- Incident response with full forensic replay
- Malware analysis through file extraction
- Detection of zero-day and living-off-the-land (LotL) techniques
- Compliance auditing and network policy validation
LMNTRIX Packets for AWS
- Validate or debunk alerts from other tools
- Discover attacker footholds before damage is done
- Reconstruct attacks in granular detail
- Proactively find threats without waiting for alerts
Unleash the power of full-fidelity packet forensics and transform your network into an intelligence engine with LMNTRIX Packets.
Part of the LMNTRIX XDR platform. Fully integrated. Analyst ready.
LMNTRIX Packets
What is LMNTRIX Packets?
LMNTRIX Packets is a subscription feature of LMNTRIX XDR. It provides time machine or DVR like capability for your network by recording everything using our XDR platform. LMNTRIX Packets combines unlimited visibility and the detection of slow and complex threats that develop over time, giving the LMNTRIX team the strategic advantage to hunt and investigate threats through every stage of an attack. By harnessing the power of the cloud, LMNTRIX has the unique ability to create an unlimited retention window with full-fidelity forensics, automated retrospection and advanced visualization—all with the ease and cost-savings of an on-demand deployment model.
How does LMNTRIX Packets work?
The four (4) distinct capabilities by LMNTRIX Packets are:
1) Post Breach Forensics: LMNTRIX Packets is like memory for your network. With full fidelity packet capture, optimized and stored for up to a year, you will know with absolute confidence whether or not events have impacted your environment. Our packet capture capability is offered with either full packet capture or meta data only. The service helps answer questions such as: How did they get in? What did they do and how did they get around while on our network? What Tactics, Techniques and Procedures (TTP’s) did they use? What did they access?
2) Anomaly Detection: LMNTRIX Packets is built on a foundation of deep network analysis from Packet sensors that span the ”new network”—including the data center, perimeter, core, IoT and operational technology networks as well as cloud workload networks and SaaS applications. Unlike other network traffic analysis (NTA) solutions, LMNTRIX Packets parses over four thousand protocols and processes layer 2 through layer 7 data, including performing encrypted traffic analysis with integration with our dedicated virtual TLS decryption appliance. LMNTRIX Packets uses this information to autonomously profile entities such as devices, users and applications, while also preserving these communications for historical forensics.
Extracted activity data feeds into the LMNTRIX XDR which uses a combination of detection models to uncover malicious intent. An ensemble of machine learning approaches avoid reliance on simplistic and noisy anomaly detection and unsupervised learning. LMNTRIX’s Adversarial Modelling capability enables the uncovering of even the most complex attacker tactics, techniques, and procedures (TTPs), by connecting dots across entities, time, protocols and attack stage. Finally, the platform also ingests threat intelligence indicators of compromise to detect known malware.
LMNTRIX Packets is the world’s first security expert system that can perform autonomous threat hunting and incident triage. Using a combination of artificial intelligence, open-source intelligence, and LMNTRIX’s own human expertise, LMNTRIX Packets autonomously connects the dots across the dimensions of time, entities, and protocols, enabling the solution to present end-to-end situations to our analysts rather than atomic alerts. Analysts thus see the entire scope of an attack as well as investigation and remediation options on a single screen rather than having to piece it together painstakingly themselves. Importantly, federated machine learning allows LMNTRIX customers to see these benefits while keeping their private data firmly within their infrastructure.
3) Retrospection: LMNTRIX Packets detects threats in real time and automatically replays stored packets to discover previously unknown threats. Correlates intelligence from proprietary research, machine learning and flow-based traffic algorithms as well as multiple third-party threat intelligence feeds. Real-time intelligence triggers the retrospection and continuous rescoring of historical traffic. The service help answer the question: Were we breached in the past and we didn’t know about it?
4) Proactive Threat Hunting: Our Threat Hunting service involves the proactive, stealthy, and methodical pursuit and eviction of adversaries inside your network without relying on IOCs.
Hunting within the LMNTRIX hunting platform dataset is accomplished by analyzing intrusions, reverse engineering malware, analyzing traffic generated by malware and other attacks, then selecting metadata generated by the LMNTRIX Packets based on this type of behavior. The LMNTRIX team has conducted many investigations and has created content, tactics and automation for the platform that allow an analyst to quickly navigate the dataset by combining many aspects of behavior into a single piece of metadata. This cuts down on the number of drills needed to find the sessions with the desired behavior, enhancing performance of the platform and reducing the effort needed to find malicious behavior. This has allowed LMNTRIX to discover incidents without any prior knowledge or notification that the organization was under a targeted attack. LMNTRIX has also used these methodologies and content to discovery many incidents where the attacker wasn’t even using malware, but authenticated access, also called Living off the “LANd”.
The unprecedented view into network traffic provided by LMNTRIX Packets is most effective for Incident Response capabilities but can also be used to validate the appropriate enforcement of your security policies and/or uncover areas where these policies and procedures may require improvement. LMNTRIX Packets is intended for organizations who want to uncover new malicious activity and not simply react to alerts based on known threats.
LMNTRIX Packets is not a typical network traffic based sensor, it is not an IDS/IPS or Netflow device, although some of its more basic capabilities could provide some overlap. Metadata is generated to describe a technical aspect or behavior within a network session. A session is defined as one or two related stream(s) of traffic with a requestor and, usually, a responder. These sessions are ordered by capture time and as such time is the first WHERE clause applied to the database when beginning an investigation. Knowing how the data is collected and ordered is integral to understanding how to hunt in LMNTRIX Packets.
Metadata in LMNTRIX Packets is considered indicators of an activity, not signatures like those used by traditional IDS/IPS and as such is handled differently. The logic contained in the LMNTRIX Packets parsers is far more versatile than your typical regex based signatures. The parsers, feeds and application rules that process traffic generate metadata about the structure of the data and extract values from the individual sessions that can be searched for efficiently. This differs from traditional IDS/IPS solutions in that it is possible to find new unknown malicious activity compared to only finding previously identified malicious activity. Signature-like parsers are also used, but because the parser engine is using a common scripting language, more complex logic can be used to determine a match, giving a far lower false-positive rate when used in this manner.
What are the consumption options for LMNTRIX Packets?
There are three (3) options to consider when subscribing to LMNTRIX Packets. These are:
- Packet Capture Option:
- Full Packet Capture – captures packets off the wire in their entirety. Ideal for 100% of investigations. This is a very expensive option and ideal for Enterprise clients.
- Meta Data Capture – captures only Meta data about the packets. Ideal for up to 80% of investigations. This is the most commonly used option.
- Capture Throughput:
This is the total throughout of all packets collected across the Customer’s network as seen on the LMNTRIX XDR. It includes the total throughout captured across all sensors deployed across a Customer network. We offer subscription options starting from 100Mbps to 10Gbps+.
- Data Retention Period:
- LMNTRIX XDR: Data or packets can be retained on the LMNTRIX XDR for 1, 2 or 3 months. Additional data retention is available for up to 12 months at request.
- On-Premise: Optionally, data or packets can be retained on the Customer premises for extended period, based on disk space provisioned by Customer.
What is the LMNTRIX Packets sensor deployment architecture?
The LMNTRIX Packets sensor(s) 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). Given enough processing capacity, the LMNTRIX Packets sensor can also be deployed on the same LMNTRIX NDR appliance/VM. Once deployed, the sensor is tuned to automatically connect to the LMNTRIX Cloud where it’s managed and monitored by the LMNTRIX CDC.
Are there any best practice LMNTRIX Packets sensor placement strategies?
The most important decision when deploying Sensors is locating strategic areas for capturing network traffic. Once key network segments are identified, the Sensors can be deployed and optimized to meet security and administrative needs.
One more important thing to consider while deploying Sensors is, it should be placed after the Customer’s Perimeter firewalls/Gateways, IPS’s, Email and Web security solutions (Mail Relay servers and Web Proxies) so that the Sensor can analyse traffic after it has been cleansed.
Customer’s can deploy as many sensors as they wish to help meet their segmentation and architecture requirements. For Packets, LMNTRIX does not charge based on the number of sensors deployed, but on the aggregate total throughout across all sensors.
The Sensor requires a SPAN/Mirror/Tap connection to passively capture packets as they traverse your network. It is important to capture network traffic at key network segments to fully benefit from the threat detection capabilities of the 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 LMNTRIX Packets sensor hardware requirements?
The minimum requirements for a sensor deployment are listed below:
VMware vSphere 5.1 or above
If you have a VMware virtualized environment, LMNTRIX will provide you an Open Virtualization Format (OVF) package that contains a deployable LMNTRIX virtual machine
Or
A physical server with CentOS Linux version 6.x. installed and patched.
NOTE: CentOS 6.x is required. No other version should be considered. A physical server must be dedicated for each sensor deployed.
RAM and CPU Cores
Each sensor requires resources based on the network traffic ingest rate on the configured network interface. The below chart is a guide to be used when configuring a sensor VM or physical server.
I/F Load (Mbps) | No. Cores | RAM (GB) |
160 | 4 | 12 |
240 | 6 | 18 |
320 | 8 | 24 |
400 | 8 | 30 |
480 | 10 | 36 |
560 | 12 | 42 |
640 | 12 | 48 |
720 | 14 | 54 |
800 | 16 | 60 |
880 | 16 | 66 |
960 | 18 | 72 |
1000 | 20 | 78 |
2000 | 36 | 150 |
CPU Core and RAM requirements
Disk Space
A sensor must have a local disk store for files that are extracted from network streams. These files are always stored on the sensor and stay in the local network. The sensor will delete extracted files, oldest first, when disk space is running low. The amount of disk space required is directly proportionate to the volume (Mbps) of traffic the sensor handles and the number and types of files in the network stream.
As a general rule, you should allocate as much disk space for local storage as you can. It is ideal if extracted files are stored for a five (5) day period. The below chart is a guide to be used when configuring the disk space requirements for a sensor VM or physical server.
I/F Load (Mbps) | Disk Space |
160 | 1 TB |
240 | 2 TB |
320 | 4 TB |
400 | 6 TB |
480 | 8 TB |
560 | 10 TB |
640 | N/A |
720 | N/A |
800 | N/A |
880 | N/A |
960 | N/A |
1000 | N/A |
2000 | N/A |
Sensor disk space requirements
Network Interfaces
A sensor must be configured with two (2) network interfaces (I/F). One is a management I/F used to configure, manage, and troubleshoot the sensor. The second I/F is used to capture network traffic. For a physical server sensor, this I/F is connected to a SPAN/TAP. In a VMware infrastructure, this I/F is connected to a VMware virtual switch or a SPAN/TAP. If a SPAN/TAP is used, then a port on the physical hypervisor network I/F must be available for the sensor. The network traffic capture I/F is not configured for an IP address.
The management I/F should be configured with a static IP address if possible. If this is not possible, then DHCP addressing will work, although this will require some work to “find” the host when the IP address is not known. If DHCP is configured, then it is recommended that an IP address be reserved for the I/F on the DHCP server.
SPAN / TAP
The network monitoring I/F of a sensor must be provided an access point to provide network visibility. This is most often done with a Switch Port Analyzer (SPAN) or a Test Access Port (TAP). Regardless of which technology is used, it is critically important that the device be configured properly. If not, then the sensor may “see” a large volume of redundant traffic, or it my only see half of a network conversation.
The most common network access method use is a SPAN port from a switch. The switch is configured to mirror the network traffic from one or more ports to a single port. This allows great flexibility in configuring what network traffic (vlans) are visible to the SPAN port. The network monitoring I/F on the sensor is connected to the configured SPAN port.
A network TAP is a standalone network capture device that is connected inline in a network segment to be monitored. The network monitoring port of the sensor is connected to a port on the TAP. Network TAP’s are the preferred way to connect a sensor to a network since they have greater throughput and are less complicated. The drawback is that they are expensive and you must be inline to work correctly.
LMNTRIX will help you determine the most appropriate method to connect the sensor to a SPAN or TAP depending on your network infrastructure.
How does a LMNTRIX Packets sensor communicate with LMNTRIX XDR?
In order for a sensor to communicate with the LMNTRIX XDR and access other services, firewall rules must be configured to allow the required communication. This communication will only occur from the sensor management I/F only.
The below chart lists the required ports that need to be allowed through an Internet facing firewall and web proxy server if applicable.
TCP Port | Purpose / IP Address* |
22 (SSH) | Cloud aggregator (Outbound) |
80 / 443 (HTTP / HTTPS) | Intel Feeds (Outbound) |
443 (TCP) | XDR forwarder (Outbound) |
53 (UDP/TCP) | DNS service (Internal or Outbound) |
443(HTTPS) | rabbitmq.com (Updates – Outbound) |
123 (UDP) | NTP time service (Outbound) |
3128 (TCP) | Python Pip repositories (Outbound) |
22 (SSH) | System management (Internal) |
9093 | LMNTRIX XDR |
* LMNTRIX IP addresses will be provided at provisioning time. * LMNTRIX IP addresses will be provided at provisioning time. | |
How are encrypted threats detected with LMNTRIX Packets?
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 dedicated appliances or switches.
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 LMNTRIX Packets 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 solutions to manage encrypted traffic include those from Mira Security, Blue Coat (SSL Visibility Appliance and ProxySG solution), Radware (Content Inspection Director (CID) and AppXcel), A10 Networks (Thunder SSLi) and Gagamon (GigaSMART).
What are LMNTRIX responsibilities during Packets onboarding?
The following provides a list of LMNTRIX responsibilities:
- Provide a license to use the LMNTRIX Packets 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 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.
- 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 during Packets onboarding?
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 to sensor management interface for bi-directional communication with the LMNTRIX XDR. Provide default gateway details for the sensor to connect to the LMNTRIX XDR.
- 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
- Addressing any issues associated with sensor credentials.
- Ensuring that their subscription covers their corresponding network throughput.
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
