Network traffic analysis
Capturing the packets a machine sends and receives, and reading them to find out what its software is actually doing. The oldest form of security visibility there is, and the one that answers a question no log can: not what a program reports doing, but what it put on the wire.
The practice has three steps, and every tool differs mainly in where it stands for the first.
- Get a copy of the traffic. A tap or SPAN port on a switch, a proxy the traffic is pointed through, or — the case pcapdroid documents — an endpoint agent the operating system hands packets to. On Android that vantage point is normally reserved for root; PCAPdroid takes it by registering as a VPN service and routing the packets onward itself.
- Identify what it is. IP and port stopped naming services a long time ago. Deep-packet inspection libraries (nDPI, from ntop, is the one PCAPdroid embeds) classify a flow by its behaviour and content, so a connection becomes a named service rather than an address.
- Read the contents, if you can. Modern traffic is encrypted, so the metadata layer — SNI, DNS queries, destination, timing, volume — is often all there is without deliberate interception.
The encryption problem, and what it does to the discipline
Traffic analysis was built when payloads were readable. They mostly are not now, which splits the discipline in two.
Metadata-only analysis takes what TLS leaves exposed: which host a connection asked for, how much was sent, when, and how often. It needs no credentials and no cooperation from the software being watched, and it is frequently enough — an app phoning a third-party analytics domain is visible without one decrypted byte.
Interception puts a proxy in the middle holding a certificate the client trusts, which is the same manoeuvre an attacker performs and is distinguished from it only by who consented. pcapdroid‘s mitmproxy addon is this, on a device its user owns. The corporate version is a TLS inspection appliance, and the argument about whether either is acceptable is about consent and reach, not about the mechanism, which is identical.
The rest of this spoke treats transport encryption as something to strengthen — mTLS as a credential, certificates as infrastructure. Traffic analysis is where the defender’s two interests collide: the encryption that protects the connection also blinds the person responsible for the endpoint.
Where it sits among the other layers
Traffic analysis feeds detection rather than replacing it. A SOC consumes flow data as one telemetry source among logs and endpoint agents; hardening reduces what can talk in the first place; zero-trust argues the network position should confer nothing, which is an argument about authorization and leaves the observation problem exactly where it was. Knowing what a machine talks to is upstream of all of them and is not itself a control — nothing is blocked until someone decides to block it, which is why capture tools grow firewalls, as PCAPdroid did.
The evidence in this spoke is thin: one endpoint tool, no network-scale source, and nothing on the detection side that uses flow data. Enterprise NTA/NDR platforms, Zeek, and the metadata-versus-payload argument at organizational scale are all unsourced.
Related
pcapdroid · wireshark · security-operations-center · system-hardening · mutual-tls · zero-trust · defensive-security