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:
- Webinar Q&A from Modern Network Threat Detection and Response
- Is Encryption an NTA / NIDS / NFT Apocalypse?
- NTA: The Big Step Theory
- Network Anomaly Detection Track Record in Real Life?
- Endpoint Has Won, Why Bother With NTA? (by Augusto)
- Can We Have NDR, Please?
- NTA: The Other IDS?
- Next Research: Deception and Network Traffic Analysis
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.