Network Detection and Response
This report provides an overview of the market for Network Detection and Response tools (NDR) and provides you with a compass to help you to find the solution that best meets your needs. We examine the market segment, vendor service functionality, relative market share, and innovative approaches to providing NDR solutions.
Commercial, government, and non-profit organizations of all kinds increasingly find themselves under cyber-attacks these days. Ransomware, fraud, credential theft, PII theft, and intellectual property theft occur on a daily basis around the globe. IT teams mitigate the risks by employing and deploying a wide array of cybersecurity tools. Many components of security architectures are well-known: firewalls, VPNs, Endpoint Protection (EPP), Security Incident and Event Management (SIEM), etc. In the last decade, security professionals have pivoted to address how to detect attacks and other malicious activities, rather than focusing solely on prevention. SIEM and IDS (Intrusion Detection Systems) were touted as solutions for detection, but they quickly maxed out their potential usefulness and have been forced to evolve. Endpoint Detection and Response (EDR) came to the fore as a means of discovering malicious behavior on desktops, laptops, and servers.
NDR solutions are designed to help security analysts discover evidence on the network and/or in the cloud of malicious activities that are in progress or have already occurred. NDR tools are effectively “Next-Gen IDS”. One of the big differences between NDR and old IDS tools is that NDR tools use multiple Machine Learning (ML) techniques to identify normal baselines and anomalous traffic, rather than static rules or IDS signatures. Given the volumes of network connection data that must be analyzed, using ML algorithms and models is a “must” rather than a “nice-to-have”. Historically, the major drawbacks to IDS were that it was labor intensive to operate, was of limited effectiveness, and could generate high numbers of false positives.
These security tools were created to discover and remediate certain types of attacks. Advanced Persistent Threats (APTs) are often perpetrated by actors from state intelligence agencies for the purpose of gathering intelligence on foreign companies and agencies, copying intellectual property, or sabotage. APT actors may also include well-funded but unscrupulous companies and hacktivist groups. Their goals often require long-terms presence on victims’ properties, hence the use of the term “persistent”. APT groups have historically been the most likely ones to use Zero-Day exploits (previously unseen in the wild), which may give them the advantage of not being detected by EPP agents. Enter NDR as a tool of last resort to discover hitherto unknown compromises. Since data exfiltration is usually an objective, properly deployed NDR tools can be better suited at discovering lateral movement from the initial compromised device to other assets within the target organization, use of compromised privileged credentials, and data exfiltration attempts. NDR tools are also deployed to combat botnet activities and to provide visibility in IoT/OT/SCADA environments where it may not be possible to implement endpoint agent-based solutions.
NDR tools can also help discover and remediate more common types of attack such as unwanted bot activities, credential theft, and insider threats.
NDR solutions can log all activities from attached networks in a central secure location for real-time and later analysis. NDR solutions are usually implemented as a mix of appliances, virtual appliances, and IaaS VM images. Appliances and/or virtual appliances deployed on-premises must tap into physical networking gear at all relevant network control points: off switch and router span or tap ports, or off network packet brokers. For example, if your organization still has perimeters, NDR appliances need to be placed there. Vendors often talk about “north-south” (across perimeters) and “east-west” (lateral movement) deployment points. All directions need to be covered by NDR solutions for maximum effectiveness.
Alternatively, some NDR virtual appliances can be co-located with firewalls or other perimeter network devices. Other common places to deploy NDR sensors are between network segments, around IoT and/or OT and Industrial Control Systems (ICS) / SCADA networks, and around web-facing properties and Wi-Fi portals. With an irreversible Work-From-Home (WFH) trend in response to the global pandemic, NDRs should be deployed alongside VPNs. NDR VMs can be inserted into your IaaS and potentially PaaS infrastructure as well. Exactly how many appliances you need and where they should be placed depends on your architecture. Proper design of NDR deployments is necessary to capture all traffic flows.
A key differentiator for NDR technology is the employment of multiple ML algorithms in the various analysis phases. At a high level, unsupervised ML finds outliers; while supervised ML models categorize possible threats among the outliers, classify malicious activities, domains, and other attributes. Supervised ML is also used by some vendors for encrypted traffic analysis. The most effective solutions utilize several layers of ML-enhanced processing of all traffic at line speed. Vendor products in this segment typically advertise 5 – 100 Gbps throughput.
In terms of responses, NDR solutions can provide dashboards/alerts/reports, display real-time visualizations, allow drilldowns into details, enrich discoveries with threat intelligence, correlate events and provide automated analysis, halt suspicious traffic, isolate nodes, and send event data to SIEMs, SOARs, and forensic/case management applications. In cases where vendor products operate in passive mode, they direct 3rd-party security tools via APIs to execute these responses.
NDR solutions are not usually easy to operate, and in some cases require a dedicated team of one or more analysts (depending on organization size) to make the best use of the capabilities. Knowing this, many vendors provide facilities within their solutions to automate aspects of analysis, including evidence collection, correlation, remediation suggestions, and root cause analysis (RCA). Many of the vendors in the NDR space offer managed services of different types to augment the products. Additionally, many MSSPs can manage an NDR deployment and handle the threat hunting and analysis tasks on behalf of their customers.
Though many security pros tend to ignore trends that seem overhyped by vendors, there are some good reasons to consider deploying NDR. The typical capabilities outlined above can be of service in discovering malicious activity that your other security tools may have missed.
Endpoint Protection (EPP) agents are a must for every computing device that can run them. However, sometimes they may not catch every piece of malicious code. There are several reasons why this happens:
- BYOD bypass: In permissive environments, some users may not have EPP and may bring in infected devices. Business partners and contractors may use their own devices, which are typically beyond the control of the hosting organization.
- Ineffective EPP: Some EPP solutions are better at detecting and preventing malware than others. Also, EPP agents need to be updated; even those that use ML-driven heuristics and exploit prevention. If EPP solutions are weak or have outdated signatures or ML models, they are more likely to miss malware.
- Many IoT devices can’t run EPP. Operating systems may not support EPP agents but are still susceptible to hacking. In other cases, IoT devices are simply not user configurable. Enterprises with large numbers of such devices tend to isolate them onto separate VLANs. These environments need security monitoring and detection capabilities that cannot be delivered by standard endpoint security solutions.
- Some Linux and Windows computing devices have limited builds of operating systems to host specific applications and are not manageable by IT staff. For example, certain medical devices such as MRI machines can’t have 3rd-party software added without invalidating warranties and support agreements. Other examples may include Industrial Control Systems (ICS) and SCADA networks. These environments are known to be targeted by particular kinds of malicious actors and given the highly critical nature of the work they do, must be monitored and protected. As in the IoT environments case, these environments need NDR solutions because other security technologies have no visibility here.
- Advanced malware can erase application and operating system log entries and suppress security tool reporting. Unauthorized and unaudited use of compromised and privileged credentials may mask attacks. Signs of malicious activity may not make it to the SIEM from endpoints. Therefore, the only place where highly sophisticated attacks may be discovered may be at the network layer.
In most of the above IoT/OT scenarios, enterprises segregate these kinds of devices onto their own networks for containment purposes. Such network segmentation is indeed useful, and the control points between these specialized networks and general-use and back-end networks are logical places to deploy NDR sensors.
Even though endpoint-based solutions may not have visibility of all malicious activities, malware generally communicates on networks: with command and control (C2) servers, to other assets in the environment (lateral movement), to participate in botnets for fraud or DDoS attacks, or to exfiltrate data. Therefore, NDR tools can discover malicious activities that endpoint solutions and SIEMs miss.
NDR solutions can be thought of another block in the foundation of security and monitoring architecture.
1.1 Market Segment
The NDR market segment has reached a high level of maturity. Many NDR products offer a fairly complete list of features and deliver real value to their customers. These products are successful at discovering malicious activity, reducing adversary dwell time, Mean-Time-To-Respond (MTTR), and data loss from attacks.
There is some variety in the types of vendors in this market. On one end of the spectrum we find startups, progressing through larger, more well-established specialists, to some large IT security stack vendors on the other end. In some cases, the larger vendors have picked-up NDR functionality through acquisitions of smaller vendors. It may be necessary to license multiple, compartmentalized products from the large IT stack vendors in order to achieve full NDR functionality. We describe which components are necessary for each vendor in their chapter 5 entries. If this approach creates a burden on deploying organizations, it is also noted as a challenge in their chapter 5 sections.
In the case of startups and advanced NDR specialists, their products may be easier to deploy, in that, the functional components are generally contained within a smaller number of physical and logical components. For example, a dedicated NDR solution likely comes as a physical appliance, or images that can be installed as virtual appliances and in IaaS environments. The management and analyst consoles may be run on-premises or hosted by the vendor in their cloud as SaaS. If this approach makes it easier for customers to deploy, it is noted in each vendor’s chapter 5 entry.
Though the market is maturing and growing rapidly, these two fundamentally different kinds of approaches to product design appeal to different kinds of organizations. Organizations with a large investment in vendor X’s security infrastructure may tend to activate NDR functionality and/or add NDR specific modules via licensing with those vendors. Such companies may not publicly tender an RFP. Other companies may prefer to buy a dedicated NDR product from a specialist and run an RFP process that is aimed at such NDR specialists.
This divergence in the approaches taken by NDR customers leads to a lack of awareness among vendors and potential customers of which vendors are actually offering NDR solutions. As a result of this research, we found that some vendors did not know the range of competition in the NDR market. It is likely that organizations looking for NDR solutions may also not realize there are multiple product/service approaches to achieving the technical and business goals that NDR can provide, and that there are a variety of vendors in the space.
As we will see in the report, there is also diversity within the product offerings. The basic capabilities are well-met by all vendors. Analysis of real-time traffic flows against historical network connection metadata for the purpose of detecting and responding to attacks is the defining characteristic of this segment. Differentiators are vendors which offer two features especially: sandboxing and packet decryption. Not all vendors choose to implement these functions. Packet decryption requires a far more invasive deployment, allowing the NDR solution to essentially read all traffic as it passes by. Sandboxing is not technically feasible unless packet decryption is in place. Furthermore, KuppingerCole research indicates that the particular market segments that vendors choose to target often has a direct effect on the type of features available in their NDR solutions. Thus, it is likely that those vendors which target government and defense customers are the ones that have full packet decryption capabilities.
Some vendors argue that decryption is unnecessary because they can reliably figure out if traffic is malicious based on analysis of network connection metadata. Consequently, these vendors’ products do not offer packet decryption. Other vendors argue that sandboxing is not necessary because they are looking for malicious traffic, not trying to uncover the malware itself. The inclusion or exclusion of packet decryption and sandboxing is represented in this report, but it is not a determining factor in whether or not a given vendor solution is considered NDR.
The use of ML is a foundational requirement for NDR and many other security solutions today. It is simply impossible for even large teams of analysts to collect, parse, and analyze the volumes of data that NDR and other tools generate.
The market is evolving as well. While at present the scope of this report has been limited to specialty NDR products and assemblages of components from security stack vendors, increasingly we see signs that other types of security vendors are moving into NDR. Security companies that have agents on endpoints realize that by adding some functionality (code) to those agents, they can effectively turn every monitored node into an eXtended Detection & Response (XDR) fabric.
Thus, NDR specialist vendors are likely to grow and take on additional endpoint security features; and they are likely to be acquired by security vendors, particularly large endpoint security companies, who are looking to expand from EDR into XDR.
1.2 Delivery Models
NDR products require an on-premise presence for customers who have offices, data centers, factories, and other facilities with their own network infrastructure. Thus, the most common component of NDR solutions is the appliance or virtual appliance that is deployed in-line, or plugs into switch/router span ports/network packet brokers, or is deployed in IaaS. Some vendors provide separate appliances for on-premises management consoles, other vendors deliver integrated sensors and management consoles, while still others provide on-prem components but telemetry is sent to the cloud for analysis and review in a SaaS-hosted console.
Most NDR vendors offer images for common IaaS environments that allow their solutions to analyze traffic in IaaS and PaaS environments. In addition to agents that allow network metadata collection and analysis for IaaS, many NDR vendors have management consoles that they operate as SaaS for clients. Even in these cases, the data collection and analysis primarily happen on customer premises or in their clouds, since it is not feasible to transmit all packets or only metadata to the vendor cloud for examination.
Many vendors in this report offer managed NDR services, which can range from monitoring and alerting on activities that their solutions generate, to ongoing threat hunting, to full incident response options.
1.3 Required and Optional Capabilities
In this report, we are looking for comprehensive solutions that provide at least 7 of the 9 major areas of functionality detailed below. These are typically the requirements that customers pose to prospective vendors in RFPs. NDR products and services can have a wide range of functions. The major required features are:
- Full packet capture and analysis
- Use of unsupervised and supervised ML algorithms and models for detection and analysis
- Traffic metadata analysis to yield baselines
- Anomaly detection in traffic patterns
- Analysis of anomalies to detect threats
- Ability to generate automated responses based on policies or playbooks
- Integration with other security solutions such as SIEM and SOAR
- Packet decryption (optional)
- Sandbox detonation of suspicious code (optional)
Full packet capture and analysis does not necessarily mean that encrypted packets are decrypted prior to analysis. Not all NDR tools offer packet decryption. The ability to decrypt packets for full in-the-clear inspection generally requires in-line deployment of NDR sensors, with the NDR sensors essentially acting as a Man-in-the-Middle. Many NDR vendors have avoided this technical path for two major reasons: this approach makes NDR an explicit target for attackers, and not many customer organizations request it or choose to use it. Packet decryption enables collection and detonation of possible malware payloads, so vendor products that don’t decrypt don’t have sandboxes. Some organizations deploy NDR in special segmented network zones where multiple security tools have access to decrypted data. In these cases, it is possible for NDR solutions to examine all decrypted traffic without having to be set up in-line and holding the pertinent encryption keys.
In lieu of packet decryption, some vendors use the JA3 and JA3S methods of fingerprinting and analyzing SSL/TLS encrypted communications. These techniques can be useful because there are a limited number of libraries and extensions for SSL/TLS Hello processes. Researchers discovered that fingerprints or profiles could be built that would identify clients and servers. This method has been widely used in the last few years, but there are gaps. It is best-effort open source project, which is not updated as frequently as necessary. This leads to occasional new permutations of browsers, clients, and servers which are not easily identified. Also, if an attacker uses proprietary encryption libraries, it will succeed in being undetected for a while. The JA3/S method is essentially a signature detection technique, which suffers from the same kind of failure scenarios that signature-based anti-malware solutions do: new threats have not been fingerprinted, so there are no corresponding signatures to detect, thus there is an inability to detect new threats until signatures are developed.
Other vendors take a slightly different approach. Realizing some of the limitations of JA3 and JA3S, they have developed proprietary methods for analyzing encrypted traffic to determine if it is indicative of malicious behavior. In these cases, vendors do not provide a lot of technical detail on how this is done because they consider this kind of technology to be their intellectual property and competitive advantage.
NDR products that are not deployed in-line passively examine traffic flows from the span/tap ports or from network packet brokers. They do not have the built-in ability to take response actions such as isolating nodes or blocking traffic. They accomplish this by using network enforcement devices APIs (firewalls, email/web gateways, VPNs, etc.).