Skip to content

Understanding NTA

Network Traffic Analysis (NTA) examines how devices communicate across a network. It helps teams understand normal activity, investigate unusual behaviour, troubleshoot problems, and identify potential threats.

What you will learn

By the end, you should be able to explain the main forms of network evidence, trace the NTA data path, investigate unusual communication, and choose a suitable analysis tool.

What is NTA?

Core concept

NTA collects evidence about communications between systems. It shows which devices communicated, when, where, using which services, and how much data was transferred. Some collection methods also expose protocol activity or packet contents.

WhoWhenWhereServiceVolumeContent

Keep in mind: Unusual traffic is not automatically malicious. Effective analysis depends on reliable collection, useful context, and analysts who test possible explanations.

What NTA is not

NTAExplore communication behaviour and network evidence
Packet capturePreserve packet-level evidence
FirewallApply access-control decisions
IDS / IPSDetect or block activity using rules and analytics
NDRCombine NTA with detection, workflow, and response

A bounded view

NTA cannot recover encrypted content or replace endpoint, identity, application, and cloud telemetry. Sensor placement also determines which communications are visible.

Why NTA matters

Investigate activity

Trace systems, destinations, services, timing, and volume to understand what happened.

Reveal hidden patterns

Connect small events that appear harmless individually or do not match a known signature.

Troubleshoot faster

Identify unexpected communication paths, failures, and changes in network behaviour.

How NTA works

NTA turns observed traffic into evidence that analysts can search and inspect. The available detail depends on how the traffic is collected and processed.

Packets, flows, and metadata

Packets and PCAP

A packet is a unit of network data. A packet capture (PCAP) preserves addressing information and, when unencrypted, transferred content. It provides detailed evidence but requires significant storage and careful handling.

Best for: Detailed investigation and troubleshooting

Flows

A flow record summarises who communicated, the services used, connection duration, and the amount of data transferred.

Best for: Relationships, trends, and traffic volume

Protocol metadata

Protocol metadata records activity such as a web request, domain-name lookup, encrypted session, or observed file without storing every packet.

Best for: Searching large amounts of activity and identifying behaviour

Flows are a specialised form of network metadata, so these evidence types can overlap. In general, greater detail requires more storage, processing, access control, and analyst effort.

NTA and IDS/IPS

Network Traffic AnalysisExplore and investigate
IDS / IPSDetect and enforce
FocusBehaviour, relationships, volume, and network activity
FocusSignatures, rules, policies, and detection analytics
OutcomeInvestigation leads and unusual activity without a known pattern
OutcomeAlerts and, when inline, prevention actions
ValidationEvidence requires analyst interpretation
ValidationDetection results and actions still require validation

Use them together

An IDS or IPS can begin an NTA investigation, while NTA may reveal behaviour that no existing rule detected. One provides a detection signal; the other helps analysts explore the supporting network evidence.

Where visibility comes from

Network trafficUsers, servers, cloud, and devices
Traffic copyA physical or software-based copy of network activity
SensorCollect, understand, and summarise
PCAP Flows Metadata

Traffic can reach an analysis system through packet copies from network TAPs, switch mirror ports, or cloud mirroring; through conversation summaries such as NetFlow or IPFIX; or from an existing PCAP or software running on a host.

The collection point decides what activity is visible. The sensor reads and summarises the traffic. The analysis platform stores the results and lets analysts search them.

Visibility is bounded

A sensor sees only traffic sent to it. Different network paths may reveal only half a conversation, while encryption, remote users, cloud services, and collection capacity can further limit visibility.

Analysis workflow

  1. CaptureReceive packets or connection summaries from the selected parts of the network.Confirm data is arriving
  2. InterpretIdentify protocols, extract useful fields, and combine related packets into network conversations.Build connection context
  3. Enrich and storeAdd device, user, location, reputation, and ownership context, then retain searchable evidence.Identify who and what is involved
  4. Detect and huntCompare activity with expected destinations, timing, volume, and relationships to identify behaviour worth exploring.Find a reason to investigate
  5. InvestigateCheck possible explanations using other evidence and nearby activity.Decide what likely happened
  6. Respond and improveEscalate supported findings, preserve useful evidence, and improve collection and detections.Apply what the team learned

Try a network investigation

Use the simplified Wireshark interface to inspect a packet capture. Select the HTTP request that deserves attention, follow its stream, decode the submitted data, and decide what the evidence supports.

Try it: follow the network evidence

Complete four steps to identify the unusual request, inspect its content, and choose the conclusion justified by the available evidence. Look at the destination, request method, and payload together rather than relying on a single indicator.

incident-traffic.pcapng Wireshark Training simulation
4 displayed
Step 1 of 4 Select the HTTP request with an unusual destination or payload.
No packet selected Choose a row to inspect its network details.
0/4 Start with the packet list Select the request that stands out, then follow the evidence one step at a time.
Exercise debrief

Frame 44 deserves attention because it combines an unfamiliar destination, a POST request, and an encoded payload. Base64 is an encoding method, not encryption or proof of malicious activity. The decoded download command is a strong reason to escalate, but endpoint, identity, and surrounding network evidence are still needed to confirm execution, ownership, and scope.

What makes NTA useful

Start with an evidence question

Can we identify a workstation making periodic connections to a new external destination?

  1. 1Choose evidenceDecide whether packets, flows, or protocol metadata can answer the question.
  2. 2Place collectionSelect points that can observe the required communication.
  3. 3Verify qualityCheck coverage, timestamps, packet loss, and parsing.
  4. 4Test and improveRun the investigation and refine collection, detections, and retention.

Common investigation signals

New relationshipsUnusual timing or volumeRepeated connectionsUnexpected protocol useKnown threat indicators

Interpret findings carefully: encryption, sensor placement, packet loss, shared addresses, and missing endpoint or identity context can limit what the evidence proves.

Operate collection responsibly

Monitor collection health and timestamps. PCAP may contain sensitive data and grows quickly, so limit collection, access, and retention to what is authorised and useful.

Network analysis tools in this kit

These tools are complementary rather than interchangeable.

Zui is not simply a graphical front end for Zeek: it can explore Zeek logs and other supported structured data. None of these tools alone provides the complete collection, alerting, case-management, and response workflow of a broader network security monitoring or NDR platform.

Continue learning