Leadership Compass

Network Detection & Response (NDR)

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.

John Tolbert


1 Introduction / Executive Summary

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 Detection & Response (EPDR), 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 Protection (EPP) has largely merged with Endpoint Detection and Response (EDR), which 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 (those which were previously unseen in the wild), that may give them the advantage of not being detected by EPDR agents. In the last couple of years, cybercriminal groups have begun to use APT strategies and tactics against their victims: gaining access to resources, siphoning out data, then detonating ransomware.

Enter NDR as an additional tool to discover hitherto unknown compromises. Since data exfiltration is usually an objective of attackers, even in contemporary ransomware cases executed by cybercriminal units, 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 provide visibility in OT/ICS/IIoT environments where it may not be possible to implement endpoint agent-based solutions. Enterprises often separate OT/ICS and IIoT 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.

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 both real-time and later forensic 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 (and most do), 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 coverage.

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 or virtual appliances your organization needs and where they should be placed depends on your architecture. Proper design of NDR deployments is necessary to monitor 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 or anomalies in traffic patterns; while supervised ML models categorize possible threats among the outliers, classify malicious activities, domains, and other attributes. Supervised ML is more commonly used by vendors for Encrypted Traffic Analysis. Deep Learning (DL) algorithms and detection models utilize variations of neural networks and are the latest generation of AI/ML technology as applied to the cybersecurity space. Some NDR vendors use DL for Encrypted Traffic Analysis. The most effective solutions utilize several layers of ML-and DL-enhanced processing of all traffic at line speed. Vendor products in this segment typically advertise 10 – 200 Gbps throughput on network sensors, and 1 Gbps for IaaS traffic scanning.

How NDR Works
Figure 10: How NDR Works

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.

There are several 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 Detection & Response (EPDR) 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 NDR is a needed complement to EPDR and other security solutions:

  1. BYOD bypass: In permissive environments, some users may bring in infected devices and not know it because their machines do not have EPDR agents. Business partners and contractors may use their own devices, which may be beyond the control of the hosting organization.
  2. 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. Ultimately, it is not logically possible to design an anti-malware solution that can detect malicious code with 100% accuracy all the time.
  3. Non-traditional endpoints: Many IoT and IIoT devices can’t run EPDR. Operating systems may not support EPDR 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.
  4. Endpoint that cannot run agents: 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 security 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.
  5. Attack coverups: 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.

Organizations today increasingly use the cloud, and key resources may be located in IaaS or in SaaS. Thus, NDR solutions need visibility of cloud environments. Hybrid architectures are common, so many NDR customers need coverage for hybrid architectures.

Even though endpoint-based solutions may not have visibility of all malicious activities, malware 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. Therefore, NDR sensors need to be strategically placed at optimum intersections within computing environments.

NDR Deployments
Figure 11: NDR Deployments

1.1 Highlights

The Top Ten findings in this Leadership Compass on Network Detection & Response solutions are:

  • The NDR market continues to grow because customers do find value in modern ML-enhanced detection models over legacy IDS/IPS solutions.
  • NDR and EPDR cover different kinds of environments, and both are needed in many kinds of organizations. Either type of solution alone may miss anomalies and thus signs of attacks.
  • The future of NDR will be XDR, which is NDR + EPDR + User Behavioral Analysis (UBA) + Distributed Deception Platforms (DDP) + Cloud Workload Protection Platforms (CWPP). This market-wide union of product types is probably 3-5 years out, although some vendors have already begun to acquire and consolidate these products.
  • Two major deployment paradigms exist in the NDR world: in-line sensors and passive sensors. In-line sensors offer direct response capabilities, while passive sensors rely on integrations. Both types of solutions continue to gain market share.
  • Operational Technology Security and Industrial Controls Security are use cases that can be well-served by NDR. A majority of vendors in this report offer varying degrees of coverage for these environments.
  • The Response part of NDR is becoming more widely utilized. Early adopters of NDR saw benefits from increased visibility and the ability to detect malicious activities, but many were not ready to allow automated responses. This may have been due to customers not fully trusting the solutions to take actions autonomously, such as shutting down connections and isolating hosts. Some may have felt like the risk of false positives negatively impacting productivity to have been too great. However, with the proliferation of ransomware, more NDR customers are opting to automatically mitigate damage.
  • NDR as a managed service is rising. Some vendors offer managed detection and response services, and more MSSPs have NDR as part of their portfolio. NDR as part of an overall MDR (not just EDR) will be appealing to SMBs and some enterprises that need the functionality but do not have the expertise to deploy and maintain it.
  • The product leaders in NDR are Arista Networks, Broadcom, Check Point, Cisco, ExtraHop, Fidelis Cybersecurity, Gurucul, NetWitness (RSA), and VMware.
  • The innovation leaders in NDR are Arista Networks, Broadcom, Check Point, Cisco, ExtraHop, Fidelis Cybersecurity, Gurucul, and VMware.
  • The market leaders in NDR are Arista Networks, Broadcom, Check Point, Cisco, ExtraHop, FireEye, NetWitness (RSA), and VMware.

1.2 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 and reducing Mean-Time-To-Detect (MTTD) time, adversary dwell time, Mean-Time-To-Respond (MTTR), and data loss from attacks.

There is a good deal of variety in the types of vendors and their products in this market. On one end of the spectrum we find mid-stage startups, progressing through larger, more well-established cybersecurity 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 generally 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. Encrypted Traffic Analysis (ETA) is of particular importance, since the majority of network traffic, both internal to organizations and on the Internet, is encrypted. TLS 1.3 is becoming more widely utilized, which can make ETA more difficult.

Two features are not universally built-in to NDR tools: sandboxing and packet decryption. Not all vendors choose to implement these functions. Packet decryption can require a far more invasive deployment if deployed in-line, but this allows the NDR solution to essentially read all traffic as it passes by. Some vendors offer decryption in an off-line mode that doesn’t impact traffic throughput, and some products can selectively decrypt traffic based on features and policy. Sandboxing is not technically feasible unless packet decryption is in place. Products which do not have built-in sandboxes may utilize 3rd-party malware analysis services. 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. Private sector organizations that privacy regulatory compliance requirements tend to rely on ETA methods only.

Many NDR vendors argue that full packet decryption is unnecessary because they can reliably figure out if traffic is malicious based on analysis of a number of factors, such as NetFlows, TLS 1.2 handshake characteristics and certificate analysis, HASSH fingerprinting, JA3 and JA3S fingerprinting, SSL deny lists, session-specific sequencing, etc. Consequently, some vendors who specialize in Encrypted Traffic Analysis techniques may not offer packet decryption. A few 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 per product is indicated in chapter 5, but it is not a determining factor in whether or not a given vendor solution is considered NDR. Somewhat surprisingly, vendors report an increase in interest and utilization of packet decryption in conjunction with NDR deployments over the last year.

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 NDR 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. However, products without a dedicated network monitoring capability may lack full visibility into environments that do not have EDR agents installed, such as IoT, IIoT, and some ICS settings.

Thus, NDR specialist vendors are likely to grow and take on additional endpoint security features; and they are likely to be acquired by larger security vendors, particularly endpoint security companies, who are looking to expand from EDR into XDR.

1.3 Delivery Models

NDR products require an on-premises 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/TAP ports or 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 via 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.4 Required Capabilities

We are looking for comprehensive solutions that provide at least 5 of the 7 major areas of functionality areas:

  • Support for traditional office, remote access, and data center architectures (LAN/WAN and SD-WAN), across on-premises, hybrid, private cloud, and IaaS environments
  • Ability to examine encrypted common IP-based application layer traffic such as DNS, email, web, etc. for threats
  • Use of both supervised and unsupervised ML and DL techniques for anomaly detection and categorization of potential threats
  • Integration of cyber threat intelligence feeds
  • Multi-purpose enterprise management console for alerting, reporting, analysis, and threat hunting for SOCs, security analysts, and Incident Response personnel
  • Interoperability via APIs and relevant standards with other components in security architectures, particularly SIEM and SOAR
  • Support for customizable playbooks and/or other automated response mechanisms

Drilling down into more detail, this report considers and rates the following criteria:

  • Solutions which offer flexible on-premises deployment methods, including appliances, virtual appliances, and VM images to better fit into customer environments.
  • Solutions that can be deployed within Amazon AWS, Microsoft Azure, GCP, Oracle Cloud, IBM Cloud, etc.
  • Solutions which can draw from both in-vendor-network and out-of-network sources for cyber threat intelligence and effectively use that information for near real-time analysis without impeding customer business (for example, by generating high false positive rates)
  • Solutions which can build a baseline of clean, normal network activity over an introductory period and can then compare it in real-time to operational traffic at line speed
  • Solutions which can detect attackers’ lateral movement within an enterprise
  • Solutions which can detect anomalies and attacks including low-level methods such as
    • Unusual DNS queries
    • DNS tunneling and zone transfers
    • Very low volume, intermittent command & control type traffic
    • Unusual HTTP headers and SSL/TLS certificates
    • High or low volume port scanning
    • Unusual RDP traffic and/or remote file execution
    • Web shell usage
    • Network proxy bypass attempts
    • Traffic to/from unusual geo-locations
    • Large volume but slow data exfiltration attempts
    • Attempts to exploit known vulnerabilities
  • Solutions which can detect high-level attack types such as:
    • Advanced Persistent Threats by state intelligence or corporate espionage actors
    • PII data breaches
    • Pre-staging of ransomware for later detonation
    • Crypto-mining
    • Fraud
    • Botnets
  • Solutions which generate dashboards and reports for customers including the following standard types:
    • Open cases and status
    • Suspicious activities
    • Traffic volume discrepancies or deviations from norms
    • Top threats
    • Forensic investigation capabilities
    • Linked threat intelligence

Additional and related features will be considered as benefits but not absolute functional requirements in this analysis:

  • Deployment options for Industrial Controls / Industrial IoT environments, critical infrastructure computing environments, ATM networks, medical facilities, etc.
  • Protocol understanding for ICS, IIoT, and IoT environments such as BacNet, CIP, CoAP, LonTalk, ModBus, MQTT, or XMPP.
  • Packet decryption. While packet decryption may be required by a small subset of customers, in most cases analysis of TLS traffic is sufficient for identifying anomalous traffic and behavior. Packet decryption can be considered a security risk in itself by some organizations.
  • Sandbox integration, either on-premises or in cloud-hosted infrastructure, for detonation and analysis of suspicious code. Third-party malware analysis services are available, and some vendors choose to rely on external services rather than packaging a sandbox within their NDR solutions.
  • Network sandboxes which can function autonomously (without constant connection to cloud services) in cases where customers want to deploy the solution on ICS or IIoT networks.
  • NDR delivered as a service. Some organizations may choose to employ SOCaaS, MSSPs or vendor provided NDR services.
  • Extended Detection & Response (XDR) functions. XDR will be the focus of future KuppingerCole reports.
Continue reading...
Read the full report and get access to KuppingerCole Research for 4 weeks.
Start Your Free Trial
Already a subscriber? Click here to login.