Introducing Traffic Path Analysis in NTA from 2026.4
Top Applications tells you what. Top Endpoints tells you who. Top Countries tells you where. None of them tell you how those things connect. Traffic Path Analysis, a new view in NetFlow Traffic Analyzer (NTA), is built to close that gap.
Figure 1: Five different pages, one unanswered question. Each view shows a piece of the story, but none of them show how the pieces connect.
The problem with ranking traffic one dimension at a time
Pie charts and Top XX lists are excellent at answering "what are the biggest five things in this one category?" They are not built to answer "which sources are driving traffic to which applications, and how much of it is going where?" That is a relationship question, spanning two or more dimensions at once, and a ranked list simply cannot hold that shape.
Figure 2: Three single-dimension views, three separate stories. None of them show how applications, endpoints, and countries relate to each other.
A different way to draw traffic: the flow diagram
Traffic Path Analysis renders traffic as a flow diagram, technically known as a Sankey diagram. The idea is simple:
- Each column is a dimension you already know, such as Country, Endpoint, Application, or Protocol.
- Each band flowing between two columns is a slice of traffic moving from one value to the next.
- The width of the band encodes volume, so the biggest paths are visually obvious without reading a single number.
Read left to right, and you are reading a sentence: this source, using this application, is talking to this destination. Reorder the columns, and you are asking a different question of the exact same underlying flow records.
Figure 3: Each column is a dimension, each band is a slice of traffic, and the width of the band is the volume moving between two values.
Note: Every diagram is also capped, by default to the top 25 entities per dimension, with everything past that rolled into a synthetic "Other" bucket. That keeps the chart legible, but it also means a long-tail anomaly living outside the top 25 will not show up until you either narrow the filter or widen the cap.
Figure 4: The default cap keeps the chart readable, but anything ranked below 25 disappears into Other until you filter down or raise the limit.
Direction is a decision, not a default
Because you choose the order of the columns, you are also choosing what question the diagram answers. Country on the left and Application on the right reads as "where does this traffic come from, and what is it running?" Flip them, and the same data reads as "which countries is this application reaching?" Neither order is more correct; they are different lenses on the same flow records.
Figure 5: Dragging a column changes what question the same underlying data is answering, live, without opening a new report.
Fifteen views, eight questions
Traffic Path Analysis ships with a Traffic Paths menu of predefined views. Several of them are different column orders of the same underlying question, so the fifteen menu entries collapse into eight distinct categories of problem they solve:
# | Category | What it answers |
|---|
1 | Geography by Application | Which applications are driving traffic to or from a given country? |
2 | Geography by Protocol | Which protocols are crossing a given country boundary? |
3 | East-West (internal conversations) | Is internal, endpoint-to-endpoint traffic behaving the way segmentation expects? |
4 | North-South (internal to external) | Is traffic leaving the network behaving the way egress policy expects? |
5 | Protocol, Port, and Application mismatch | Does the application riding a given protocol and port match what that combination is supposed to carry? |
6 | Unmonitored Applications Breakdown | What is the traffic NTA could not classify into a named application, and where is it going? |
7 | Usage by IP Address Group | Does the traffic mix at a given site or subnet match what that site is supposed to be doing? |
8 | Application composition | What applications make up the traffic at a given endpoint, and is anything unexpected in that mix? |
The eight sections below walk through each category with the anomaly it is built to catch.
1. Geography by Application
Shipped as: Country + Application (and its mirror, Application + Country).
Default dimensions and why it exists: Source Country, Endpoint, Application, Endpoint, Destination Country. Compliance and data-residency questions are asked in terms of countries first ("is data leaving the EU?") and applications second ("what is generating that traffic?"), so the view is built around that ordering rather than forcing you to cross-reference a Countries pie against an Applications pie by hand.
- Symptom: A compliance or data-residency review needs to know which applications are moving data across a specific national border, not just which country has the most total traffic.
- What the diagram shows: Every application's traffic broken out by which countries it is flowing between, side by side in one chart instead of two separate pies.
- The anomaly: A database or file-transfer application shows a thick band running to a country nobody on the team expected it to touch.
- Why it matters: That single band is the difference between a clean audit and a data-residency finding, and it would never have surfaced by looking at a Top Countries pie or a Top Applications pie in isolation.
Figure 6: Applications and countries in one chart. The orange band shows exactly which application is driving traffic to which country, instead of leaving that connection to guesswork.
2. Geography by Protocol
Shipped as: Country + Protocol (and its mirror, Protocol + Country).
Default dimensions and why it exists: Source Country, Endpoint, Protocol, Endpoint, Destination Country. This view swaps Application for Protocol in the same column layout as the previous category, because some cross-border traffic is worth flagging by protocol alone, before it is even classified into a named application, most notably tunneling and encapsulation protocols like GRE that security teams treat as inherently higher-risk regardless of what they carry.
- Symptom: A security review wants to know whether any tunneling or encapsulation protocol is crossing a border it should not be crossing, independent of what application, if any, that traffic has been classified as.
- What the diagram shows: Every protocol's traffic broken out by source and destination country, so an unusual protocol lights up against the countries it is actually reaching.
- The anomaly: A GRE tunnel shows a band running from a domestic endpoint straight to a country with no legitimate business relationship to that network.
- Why it matters: GRE traffic to an unexpected country is a lead worth escalating immediately, and it is buried in a flat protocol table today, not surfaced anywhere a NOC analyst is already looking.
Figure 7: Protocols and countries in one chart. The flagged GRE band traces a tunnel to a destination country that has no business reason to be receiving it.
3. East-West (internal conversations)
Shipped as: East-West Traffic.
Default dimensions and why it exists: Internal Endpoint, Internal Endpoint. Segmentation and lateral-movement questions are inherently about internal endpoints talking to other internal endpoints, with no country or external party involved, so this view strips the diagram down to just the two endpoint columns that actually matter for that question.
- Symptom: A security team wants to confirm that internal segmentation is holding, specifically that workstation-tier devices are not directly reaching database-tier or application-tier servers they have no business talking to.
- What the diagram shows: Every internal endpoint pair and how much traffic flows between them, with the normal pattern being sparse, predictable connections between adjacent tiers.
- The anomaly: A workstation on the general user segment shows a direct, sustained connection to a database server that should only ever be reached by application-tier servers.
- Why it matters: That single unexpected edge is exactly the kind of segmentation violation that ranked lists never surface, because no single-dimension Top Endpoints view distinguishes "expected tier-to-tier traffic" from "a workstation talking straight to the database."
Figure 8: East-West traffic reduced to its two relevant dimensions. The flagged connection shows a workstation reaching a tier it should never be able to reach directly.
A comparison view makes the pattern even clearer: normal East-West traffic is sparse, one-to-one pairs, while a compromised host shows a distinctive fan-in shape, many internal endpoints converging on a single target in a short window, the signature of lateral movement rather than everyday chatter.
Figure 9: Normal internal traffic is sparse and paired off. A fan-in shape, many endpoints converging on one host, is the pattern lateral movement leaves behind.
4. North-South (internal to external)
Shipped as: North-South Traffic.
Default dimensions and why it exists: Internal Endpoint, Application, External Endpoint. Egress questions need to know both what left the network and which application carried it, so this view keeps Application in the middle column between the internal and external endpoint, rather than collapsing straight from endpoint to endpoint the way the East-West view does.
- Symptom: A capacity or security review needs to know whether a saturated perimeter link is being driven by legitimate, approved traffic or by something that should not be leaving the network at that volume.
- What the diagram shows: Every internal endpoint's outbound traffic, broken out by application, and where each application's traffic is actually landing externally.
- The anomaly: An application classified as approved SaaS shows a sustained, heavy-volume band to an external endpoint, over hours rather than a brief spike, on a link that was assumed to be running backup traffic.
- Why it matters: Distinguishing a brief spike from sustained heavy volume is exactly what a saturation alert cannot tell you on its own, and this view turns "the link is full" into "this specific application, from this specific internal endpoint, is why."
Figure 10: Egress traffic broken out by application. The flagged band shows exactly which application is saturating the perimeter link, not just that the link is saturated.
A side-by-side view of the same application over time makes the difference between "typical" and "worth investigating" explicit: a labeled approved-SaaS path next to the same path relabeled as unapproved cloud storage, with a timeline showing the traffic sustained for hours rather than spiking briefly.
Figure 11: The same protocol and path, but the label and the duration are what separate ordinary egress from traffic worth escalating.
5. Protocol, Port, and Application mismatch
Shipped as: Protocol + Port + Application.
Default dimensions and why it exists: Endpoint, Protocol, Port, Application, Endpoint. Port-based evasion specifically means an application running on a port it does not normally use, so this view keeps Protocol and Port as two separate columns, distinct from the application riding on top of them, rather than folding port into the protocol label the way some legacy pages do. Keeping Port as its own column is what lets a mismatch on a specific port stand out instead of being averaged into a whole protocol's traffic.
- Symptom: A security review needs to catch traffic that is deliberately using a well-known port to disguise what it actually is, a classic evasion technique that port-only or protocol-only views cannot distinguish from legitimate traffic on that same port.
- What the diagram shows: Every protocol-and-port combination in use, and which application NTA has actually classified as running on top of it.
- The anomaly: Traffic on UDP port 22, a port associated with SSH, a TCP protocol, is classified as an unrelated application entirely, a combination that should not exist if the traffic were genuinely SSH.
- Why it matters: That kind of protocol-port-application inconsistency is a textbook sign of port-based evasion, and it is invisible to any view that only shows Port or only shows Application, because each of those looks unremarkable in isolation. It takes all three columns together to expose the mismatch.
Figure 12: Protocol, port, and application as three separate columns. The flagged path shows UDP traffic on port 22, an SSH port, classified as an unrelated application, exactly the inconsistency port-based evasion produces.
6. Unmonitored Applications Breakdown
Shipped as: Unmonitored Applications.
Default dimensions and why it exists: Internal Endpoint, Uncommon Protocol, Port, Application Candidate, External Endpoint. Classification, whether by NBAR2 or another engine, is a best-effort process, and it has known coverage gaps by vendor. This view exists specifically to surface the traffic that classification could not name, rather than silently omitting it the way a Top Applications ranking does, since a ranked list can only rank what it has a name for.
- Symptom: A Top Applications list simply drops unclassified traffic from its ranking because it has nothing to rank it by, so a growing pocket of unnamed traffic can sit invisibly outside every application-based report.
- What the diagram shows: Every flow that classification could not confidently name, broken down by the uncommon protocol and port it used and the internal and external endpoints it connected, with an "Application Candidate" label standing in for the name classification could not assign.
- The anomaly: A specific internal endpoint is running a consistent, isolated flow on an uncommon protocol and port, with a plausible candidate name like a remote-administration toolkit, to an external endpoint, and no application record explains it.
- Why it matters: Traffic with no name is not traffic with no risk, and this view is the only place that traffic surfaces at all rather than getting silently excluded from every other ranking.
Figure 13: Unclassified traffic, broken out by protocol, port, and a best-guess application candidate, instead of being silently dropped from every ranked application list.
Isolated against the noise of a full traffic diagram, that single flagged path traces cleanly from a specific internal endpoint through an uncommon protocol and port to a named candidate application and back out to an external endpoint, exactly the shape a Top Applications list would never show because it has no name to rank.
Figure 14: The same flagged path, isolated from everything around it. This is the shape unnamed traffic takes once it has somewhere to surface.
7. Usage by IP Address Group
Shipped as: Usage by IP Address Group.
Default dimensions and why it exists: Endpoint, Application, IP Address Group. IP Address Groups already map endpoints to sites or subnets, such as HQ, a branch office, or a data center, so this view puts Application in the middle to answer a site-level question directly: does the traffic mix at this site match what this site is supposed to be doing? That is a different question from ranking applications globally, because a site's expected traffic profile is specific to its role.
- Symptom: A site is expected to run a specific traffic profile based on its role, for example a data center should be dominated by backup, replication, and file-transfer traffic, and a deviation from that expected profile is worth catching before it shows up as a capacity or compliance problem.
- What the diagram shows: Every IP Address Group's traffic broken down by which applications are actually running through it, side by side with the other groups, so a mismatched mix stands out by comparison rather than in isolation.
- The anomaly: A data center IP Address Group, which should be dominated by backup, replication, and file-transfer traffic, instead shows the large majority of its traffic as streaming media, a profile that matches a branch office far more than a data center.
- Why it matters: Comparing that one Data Center column against the Web-and-Email profile of HQ and the Branch Office next to it is exactly what turns "traffic exists" into "this specific site does not match its expected role," and no single-site report shows that contrast on its own.
Figure 15: Application traffic broken out by IP Address Group. The flagged Streaming Media band into Data Center stands out immediately against HQ and Branch Office's normal profile.
A bar-chart comparison of the traffic mix makes the mismatch explicit in numbers: HQ and Branch Office both run a consistent 65/25/10 split of Web, Email, and File Transfer, while Data Center runs 93 percent Streaming Media, a profile that does not match expected data center traffic at all.
Figure 16: The same mismatch as a direct comparison. Data Center's 93 percent Streaming Media share is the number behind the flagged band in the diagram above.
8. Application composition
Shipped as: Application Breakdown.
Default dimensions and why it exists: Endpoint, Application. This is the simplest view in the set, two columns only, and that is deliberate: composition questions, what is this endpoint actually running, and is that mix drifting over time, do not need geography, protocol, or port to answer. Adding more columns would only dilute the one comparison this view exists to make.
- Symptom: A gradual composition shift is easy to miss when you are only checking a Top Applications ranking at a single point in time, because a slow-growing slice can climb the ranking for weeks before it is large enough to catch anyone's attention, and by the time it does, there is no built-in comparison against where that same slice stood a few weeks earlier.
- What the diagram shows: Every endpoint's traffic broken out by application, including a distinct "Unknown SaaS Tool" bucket for traffic that classification could not name, so the mix at each endpoint is visible as a whole rather than one ranked leader at a time.
- The anomaly: An "Unknown SaaS Tool" slice that was a thin, easily overlooked band in one snapshot has visibly grown into a much thicker band a few weeks later, without ever being large enough at any single point to top a Top Applications ranking.
- Why it matters: This view is what makes that kind of gradual, comparative drift visible at all, since a single-point-in-time ranking has no mechanism for showing "this grew" versus "this is large," and a slice that never wins the ranking outright can still be the thing worth acting on.
Figure 17: Application composition per endpoint. The Unknown SaaS Tool band is thin here, easy to overlook in a single snapshot, but it is the one worth watching over time.
Placed side by side with the same breakdown from three weeks earlier, the drift becomes unmistakable: Unknown SaaS Tool grows from a barely-visible sliver at the bottom of the list into a solid, orange-flagged band with a clear upward trend, the kind of change a single-point-in-time ranking would never show.
Figure 18: The same Unknown SaaS Tool slice, three weeks apart. Neither snapshot alone would trigger a Top Applications alert, but the comparison between them makes the growth obvious.
The bigger point
None of the data behind Traffic Path Analysis is new. Every byte, application, country, and protocol it shows was already being collected and stored in NTA. What changes is the shape you get to see it in, and the fact that you can reshape it yourself, live, by dragging a dimension from one end of the chart to the other, instead of running a new report every time the question changes.
Figure 19: The same loop runs through every use case above: reorder the dimensions, see what pattern the reordering reveals, investigate what it turns up, and reorder again if the answer raises a new question.
