Blog post

Tricky: Will UEBA and NTA Ever Merge?

By Anton Chuvakin | February 13, 2019 | 4 Comments

network forensicsnetworkdetectionNTA

Here is an obvious, but not really obvious question: will UEBA and NTA ever merge? Admittedly, normal security people who don’t care about the changing tides of vendors and markets can skip this post, because this has little to do with the operational realities of most organizations.

Specifically, if you need to collect and analyze network traffic and get usable security insights, you may not care if this is called NIDS, NTA, UEBA, NBAD or NG-WTF. You care that it does a good job at the task at hand. And this is how it should be!

But still, let’s talk categories today. What is the relation between UEBA and NTA? – “It’s complicated!” Clearly, both are examples of “analytics-heavy” or “ML-heavy” security technologies, but are their missions aligned or not?

First the simple stuff. We all see UEBA rapidly merging with SIEM. Most viable UEBA vendors have already secured their 1st class cabins on the SIEM Magic Quadrant ocean liner, while the remainder UEBAs are desperately blowing into their inflatable mattresses to chase them across the rough seas … And don’t you dare tell me my metaphors aren’t crisp enough 🙂

So, how can UEBA and NTA merge if UEBA is already merging with SIEM? Are we talking big triple-married happy family called “a cyber defense platform”? To confuse this mess even more, some SIEM vendors already have traffic analysis features that are at least decent (think “Vendor L” or ”Tool Q”). These features compete with standalone NTA players; meanwhile said SIEM vendors are building UEBA features. Argh….

On the other hand, I met somebody who thinks that “UEBA is to SIEM is what NTA is to NIDS.” Now, this can be seen in one of two ways: UEBA can be seen as a SIEM with a brain, or a brain for a SIEM. But neither is really true for NTA and NIDS … or is it? Since many NTA vendors include a signature-based NIDS engine (either in parallel or upstream from their little ML brain), perhaps “NIDS with a brain” is an apt description after all?

Digging deeper in this direction, if a traditional NIDS / NIPS sits upstream of SIEM, and no SIEM vendor – with good reasons – decided to become a NIDS vendor, is SIEM/UEBA really a logical place for NTA functions?

Another view I encountered goes like this: it is easier for a UEBA vendor to build NTA functionality than for an NTA vendor to build UEBA functionality. Think about it! To be a good UEBA, you have to master many data types/sources (many log types), and to be a good NTA, you just have to master traffic. Some of the UEBA tools today can read Bro / Zeek logs and then build ML models and other analytics on top. Does it remind you of anything? Duh, that’s what nearly every NTA vendor out there does. And this is all many of them do…

Finally, there are some vendors that look very much like a UEBA/NTA hybrids. They can do UEBA for logs, and then can do NTA on traffic, both reasonably well . Or both. For these vendors, UEBA already merged with NTA, and there is nothing to discuss (“Vendor N”, now part of “Big Vendor A” was like this).

Any wise words of advice? Yes, please ignore all that, if you are in the trenches doing useful security stuff. “KEEP CALM and WAIT FOR AI” 🙂

Blog posts related to NTA and NDR research:

Comments are closed


  • Scott Carter says:

    “To be a good UEBA, you have to master many data types/sources (many log types), and to be a good NTA, you just have to master traffic.” I would argue that NTA has a different, but equally challenging problem. How do you deploy anomaly detection or behavioral analytics in a meaningful fashion, when every network deployment provides a unique view. How does one account for NAT, Proxies, or tap placement in relation to the dns servers? How does the solution handle DHCP or rapidly changing cloud infrastructure? While SIEM’s UEBA and NTA have some common goals, I would argue that these SHOULD remain separate if you want to maintain the ability to drop NTA in without a professional services engagement as you described here…

    Then again, if you have a solution that addresses networking problems in a practical way, maybe you are actually describing NDR 😉

    • Thanks for an excellent comment! I agree that “log anomalies” (however hard) are not infrequently more glaring vs traffic. So much traffic is “really weird” but not bad, and so an NTA vendor has to work extra hard. In that sense, perhaps UEBA is easier…

  • Tom Clare says:

    A good NTA will have multiple sensors (gateway, internal, email, web, and cloud) plus cover all ports and protocols at 10G speeds to provide visibility to content and context in real-time. This includes decoding, reassembly, recursive file extraction, etc. if you can run DLP policies against the data, you know the visibility is there. Now, unlike a SIEM with logs, events, and alerts, a good NTA will record 100s of metadata attributes, both standard and enhanced, plus custom tags. The metadata can be stored inexpensively compared to full data captures and is indexed for high speed queries and hunting, plus drives ML models. Here is the difference, metadata allows you to search or hunt by author, footer, header, keyword, etc. and run ML behavior models not possible with SIEM logs, events, and alerts. For detection, you need content and context…so what is at the core of your security stack? You should be building out metadata from endpoints and network sensors.

    • Thanks for an intelligent comment here! Indeed, a good, solid NTA is also hard, especially if you a/ scale and b/ decode well and c/ go beyond shallow metadata…

      BTW, the above never claims that UEBA can run the same models, just that it is harder to run good models on 400+ log types 🙂