Blog post

Is Encryption an NTA / NIDS / NFT Apocalypse?

By Anton Chuvakin | November 16, 2018 | 9 Comments

securitynetwork forensicsnetworkmonitoringdetectionNTA

Here is a funny one: does pervasive traffic encryption KILL Network Traffic Analysis (NTA) dead?

Well, OK, not truly “kill it dead,” but push it back to 2002 when it was called “N-BAD” [“a coincidence? I think not”] and was solely Layer-3/flow/netflow-based. Back then, it was considered either a niche security technology or a luxury with a market of barely any millions [this of course excludes non-security focused traffic monitoring that Gartner calls NPMD].

We’ve been asking different people this question in different forms and we’ve heard very different things (all quotes below are made up, these are genericized versions of the things we’ve heard):

  1. Yes, network encryption and especially TLS 1.3 will doom content inspection. Do not buy NTA, the boxes will be doorstops soon” [some say that TLS 1.3 only kills NFT and not NTA due to making stored data decryption dramatically harder if at all possible; cert pinning makes both hard, but you can work around it]
  2. No… SSL/TLS is old hat, and much of our internal traffic (East – West) remains plaintext – so NTA will work here for many years” [a very past-looking view, but much of IT is in the past, so perhaps OK?]
  3. Well, we only do flow-based ‘NTA’ anyway because of some privacy mumbo-jumbo, so encryption does not make it any worse.” [this is a fairly sane view, but this is akin to saying “return to 2002 won’t harm us since we in fact live in 2002”]
  4. “In fact, we can analyze encrypted traffic data by using a tamed, but proprietary vendor magic unicorn or open–source (JA3)” [TRUE] and “It works as well as plaintext analysis” [100% FALSE!]

From the above list, the path #4 is the most exciting to watch, of course. I am really curious how far we can go with analytics, data science and machine learning to try to glean security-relevant insight from encrypted and shallow data.

So, what can we conclude? You can:

  • Keep fighting the MitM / decryption battles and you will win some and lose some, but will eventually lose the war. Will it be in 2021 or 2030? No idea when, but it will happen.
  • Push hard for your vendor to improve encrypted data analytics and the level of insight derived from flow-/header-level traffic data – but be aware of the hard limits of this path.
  • Accept that NTA will deliver less in the future due to disappearance of most (but not all) layer-7/content visibility.
  • Stick to the endpoint and toss your NTA out of the window (example).


Blog posts related to NTA, NDR and this research:

Comments are closed


  • Kiran Vangaveti says:

    Anton, Your observations and insights that you share in this blog are always exciting to read. Definitely agree Number 4 is where the game is right now. There is still a lot of value to be gleaned from NTA, without depending on TLS/SSL decryption. I respectfully disagree with the assumption that we are being pushed back to 2002. No we are not. The ML techniques available today were not the order of the day back then. This helps us glean information from signal intelligence techniques that can orient the defender to investigate the endpoint involved in the transactions. Yes, endpoint (EDR) is the rave, but lets not forget that security architecture is still at its best, when implemented in layers. EDR had has its challenges. DRAC, ILOs, IOTs, SCADA come to ming. It is the proper integration/amalgamation of various Defense Layers that help us be more successful.

    • Thanks for the comment. My point re: 2002 was intended to solicit the feedback of the exact type you provided. Indeed, can much improved analytics today deliver more value vs what we had 20 years ago? It seems that the answer is a “qualified YES” (not YES AS MUCH AS PLAINTEXT, but YES MORE THAN BEFORE)

    • Andrew Gish-Johnson says:

      I definitely agree with you, Kiran.

      When everything was cleartext, my toolset was extremely limited. I couldn’t process (let alone store) the data I wanted.

      My job will be harder in a fully end-to-end encrypted environment (if it ever happens), but I’ll still have plenty of capability to be stronger than I was in ‘2002’.

  • Andrew Gish-Johnson says:

    Also, how is NTA any different than EDR?

    I can’t put an EDR tool on an endpoint I don’t own in a true BYOD environment. I also can’t put an EDR tool on select systems I do own like IOS devices.

    • >how is NTA any different than EDR?

      Eh…it is kinda the opposite of it? NTA sits on the network, this is why it is seen as ideal for OT and BYOD. The whole point of NTA is that it is NOT the endpoint tech.

      • Andrew Gish-Johnson says:

        My statement was unclear. I’d meant that the challenges of NTA are pretty similar to the challenges of EDR.

        I can’t see inside encrypted communications from my NTA platform. I can see the communications and just make the best of the limited data I have.

        I can’t install my EDR tools on platforms I don’t have control of. I have to rely on compensating controls (my NTA platform) to monitor those devices.

        Anecdotally, I’m seeing more encrypted communications and more BYOD devices.

  • Considering north-south traffic, I would argue that even absent encryption, advanced adversaries have excelled at hiding their C2 signal in ever deeper and more varied fields within sprawling protocols like HTTP (or HTML (or JS)). So while encryption of north-south traffic has material impact on the ability to produce and run signatures for known C2 channels, looking for advanced attack patterns has always been more complicated. And seeing traffic in the clear has often provided only an illusion that the problem is more tractable – or has turned your NTA into a glorified EDR sandbox. So a world-class NTA shouldn’t rely on seeing the interior of north-south payloads to find advanced threats. And pedestrian threats against traditional (non-IoT) endpoints are better handled using EPP or EDR. The ML techniques available now and into the future give us a reasonable fighting chance against the threats for the simple reason that adversaries have difficulty in reversing exactly what the ML does and how it adapts to (learns from) local patterns it observes. In other words, it’s not a fixed target.

    On the east-west front, there is a lot of unencrypted stuff present today – Kerberos, SMB (still very little encrypted), RPC, etc. – but application traffic is pretty much all encrypted already and even the infrastructure protocols will eventually be encrypted (though not as quickly as some would believe). The NTA approach on east-west needs to be a hybrid one – traffic sensors process the traffic at key junction points and logs provide context (e.g. account use, auth failures, etc.) for that traffic. Why insist that an NTA only ingest packets? The best solutions are hybrids which examine traffic where possible, augmenting with logs to provide necessary context for the observed traffic and even logs for threats which won’t show up in traffic which can be easily observed (e.g. data leaking out of an organization’s S3 bucket). In other words, NTAs need to rely mainly (though not exclusively) on features extracted from observed traffic.

  • Ian Farquhar says:

    Interesting topic, Anton, and something I’ve been thinking about for some time. JA3 is an interesting approach, but I think what we will see is this:

    1. The enterprise challenge introduced by TLS 1.3 removing even the option of passive interception in environments where other controls were present will create issues, and we’ve been hearing this from a number of customers. The PFS key exchange is certainly desirable in across the Internet connections, but inside a well-controlled datacenter the need for MiTM interception of M2M traffic is ludicrous. It was disappointing, at IETF101 earlier this year, that the dual opt-in RHRD protocol was rejected from even consideration, with arguments which seemed to me to be emotional rather than technical.
    2. We will have an E-W capability to perform selecting MiTM inspection, by default off. I see this as a key required capability moving forward.
    3. Flows will be selected dynamically as “interesting.” Interesting might correspond to risk analytics (secops), corresponding to a problem under analysis (troubleshooting netops), requiring analysis for compliance (think: financial fraud detection in a FSI). These sessions will be dynamically decrypted as needed.
    4. I’m quite comfortable that we will see a full suite of stack characterization plus traffic and ciphertext-only analytics develop. I see this as a positive thing, building off JA3 (which is very basic, but a good starting point). I think this is an area ripe for R&D, so I respectfully disagree that there are “hard limits on this path”. Our friends in the intelligence agencies have been doing this with reported success for some time.