Network & Traffic Security: How SOC Teams Detect an Attack

Editorial Note: This article examines how network traffic visibility supports security operations, from telemetry collection and detection workflows to incident response and compliance. It focuses on practical trade-offs across organisations of different sizes, including where network-level signals help and where they need to be combined with endpoint and identity data.

Network Traffic Analysis for Security Operations: Detection, Tools, and Workflows

Two Companies, One Attack Chain: An Incident Response Timeline

02:14 UTC. A finance workstation at Atlas Commerce and an office machine in the Verdant Supply warehouse open the same spoofed purchase-order PDF within minutes of each other. An infostealer lands, pulls saved session cookies out of the browser, and gets hold of an SSO refresh token. Up to this point the two companies are in exactly the same position — a 12,000-person global retailer and an 18-person coffee subscription brand, neither meaningfully safer than the other.

The paths diverge in the next twenty-seven minutes.

At Atlas, 02:41, the NDR behavioural baseline module raises an alert: this host is making HTTPS requests to a domain registered eleven days ago, and that domain appears on no known-service list. At 02:47, Tier 2 analyst Maya Okafor picks it up. She starts in conn.log: connection opened 02:41:12, orig_bytes 1.2 KB, resp_bytes 2.4 KB, duration 0.8 seconds. Then dns.log: the query resolves, rcode_name NOERROR, to an IP registered forty-five days earlier. Finally ssl.log: server_name matches the domain, the certificate comes from an uncommon CA, and the ja3 fingerprint matches a known tool family in the internal intel store.

What strengthens the case is cadence. She stretches the timeline: the connection recurs every 47±3 seconds, and each exchange sits between 1 and 3 KB. The repeated pattern is consistent with automated beaconing, although cadence alone does not establish malicious intent.

At 03:15 she pivots to the identity side to cross-check the alert: the same token authenticated to the finance SaaS at 03:12 from an ASN that has nothing to do with the employee's usual egress. Credential abuse plus a compromised host — the evidence is now strong enough to escalate the incident. At 03:20 the host is isolated, the token revoked, and relevant packet captures preserved for forensics. Nine hours after the initial alert, the lateral scope is confirmed and investigators have found no evidence of data leaving the network. Afterwards she turns the SNI-plus-JA3 combination into a candidate detection rule, commits it to Git, sends it through review, and only allows it to ship after replaying it against historical data in CI.

At Verdant Supply, nothing is generated at that moment. No NDR, no centralised logging, and no dedicated egress telemetry are being collected. Cloudflare's DNS Analytics does provide some visibility into DNS queries, but its retention and query limits depend on the dataset and account scope, and nobody is reviewing the available data.

Day 1, 18:30: the attacker signs in to the Shopify admin with the stolen credentials — the second admin account has no MFA, and the password was set three years earlier. Day 2, 09:40: a customer orders CSV is exported. Day 2, 11:05: it is uploaded over HTTPS to the same domain, which on the wire looks like an ordinary file upload. Day 2, 15:20: Stripe sends a risk email, and in the same hour three customers report fraudulent charges.

Day 3, 03:00 — sixty-three hours after the intrusion began — Dan Reyes learns anything happened at all. The discovery path is a customer complaint plus a payments risk email. No alert participated in any part of it. What follows is the GDPR seventy-two-hour notification window and a PCI notification process determined by transaction volume.

The post-incident review finds three gaps: egress DNS and flow logs were never collected; admin logins had no MFA and no anomalous-login alerting; and the checkout page's third-party scripts had neither an inventory nor change detection.

The difference between the two timelines comes down to one question: at that moment, was anyone able to see that traffic? What follows is a breakdown of what "seeing" is made of, in what order it gets built, and how much of it the 2026 tooling landscape has already changed.

Why the Network Layer Still Matters When You Already Have EDR and Identity Controls

Endpoint detection covers machines with an agent on them. Identity controls cover logins that pass through SSO. With both done properly, four categories of activity still sit outside the frame.

The first is agentless assets: printers, POS terminals, badge readers, boxes running legacy operating systems, contractor laptops plugged in temporarily, warehouse scanners. These often cannot run EDR and never touch the corporate IdP, yet they share a network with systems that matter. The second is lateral movement: once a host holds credentials, it probes, enumerates, and hops across the internal network, and the endpoint view shows only local process behaviour — not who it is talking to. The third is cloud-internal traffic: service-to-service calls inside a VPC, cross-subnet access, bulk reads from object storage, none of which endpoint agents typically cover.

The fourth deserves its own paragraph: abuse under legitimate authentication. After credentials are stolen, a login may succeed using a valid account, and the resulting activity can resemble normal use. Identity logs may show a successful authentication without revealing whether the session is being misused. Traffic cadence, destination reputation, connection patterns, and data volume can provide additional evidence — which is precisely the kind of signal Maya's 47-second beacon illustrates.

The value of this layer compresses into one line: endpoints tell you what happened on a machine, the network tells you who that machine is talking to. An attacker can scrub a host, but they have to communicate, and communication is itself a trace.

Network Telemetry Tiers: Flows, Packets, DNS, and TLS Metadata

The first decision about visibility has little to do with products. It is about what each tier captures and how long you keep it.

Tier	Representative tech	What it shows	What it misses	Cost and retention reality
L1 Flow records	NetFlow / IPFIX, cloud flow logs (VPC Flow Logs, etc.)	Who talks to whom, ports, byte counts, duration, allow/deny outcome	Payload, protocol semantics; some implementations omit name resolution	Cheapest, suited to long retention; fields and sampling rate set the analytical ceiling
L2 Protocol metadata	Zeek (`conn`/`dns`/`http`/`ssl`), Suricata alerts	Domains, URLs, certificates and issuers, JA3/JA3S fingerprints, connection cadence, request structure	Plaintext of encrypted payloads	Moderate; structured data retains well long-term and is the primary signal source in an encrypted era
L3 Full packet capture	Arkime, Malcolm and similar	Complete sessions, replayable for forensics and offline re-analysis	Content limited by encryption	Expensive storage; typically rolling daily plus selective long-term archive
L4 Selective decryption	TLS decryption / inspection	Plaintext content, strongest detection	—	Performance overhead plus privacy and compliance friction; usually enabled for narrow traffic only

L2 is a load-bearing tier. Without decrypting payloads, certificate metadata, available SNI, TLS fingerprints, DNS queries and resolutions, and connection timing can provide valuable evidence of C2 beaconing and staging activity. These signals are not conclusive on their own: legitimate software can produce periodic connections, fingerprints can be shared or changed, and encrypted client hello (ECH) can hide the server name. The Atlas alert is therefore best understood as a metadata-led detection supported by behavioural analysis, not as proof that L2 telemetry can identify most C2 activity in every environment.

Cloud flow log blind spots belong in the design, otherwise teams end up with the illusion that "flow logs are enabled." AWS VPC Flow Logs, for example, do not record all IP traffic: traffic to the Amazon DNS resolver, DHCP, ARP, and access to the instance metadata address 169.254.169.254 fall outside the record; configuration and fields cannot be modified after creation, so changes require deleting and recreating; and aggregation intervals on Nitro instances are fixed at no more than one minute. The sane sequence is to define the question first, then work backwards to the fields required to answer it.

Container environments may need an additional host-side or workload-aware telemetry layer. Short-lived workloads and dynamic scheduling can make static capture configurations harder to maintain. Depending on the platform and required visibility, eBPF-based host telemetry, cloud-native flow logs, or appropriately configured traffic mirroring can each contribute useful signals.

For teams with a limited budget but someone willing to operate it, the open-source route is a credible middle option. Malcolm, maintained by CISA, pipes PCAP, Zeek logs, and Suricata alerts through Logstash into OpenSearch and pairs Arkime for packet-level retrieval; AWS publishes deployment guidance for it. It delivers L2 and L3 in one move at a cost far below commercial NDR, with the trade being sustained human effort.

Two Scales, Two Realities: Enterprise SOC vs. an 18-Person DTC Brand

The tiering above is universal. Inside a real organisation it gets reshaped by three constraints: whether dedicated staff exist, whether capability can be outsourced, and where compliance pressure originates.

On the enterprise side the reality is ample headcount and an overload of choices. Visibility typically combines full-site traffic mirroring or cloud flow logs with Zeek-style metadata; detection sits with NDR/NTA plus SIEM correlation; retrieval and forensics rely on long retention plus packet-level search; response introduces orchestration while keeping human confirmation on high-blast-radius actions. What distinguishes vendors is deployment shape rather than ranking: Corelight follows the Zeek metadata route with highly customisable detection logic; ExtraHop centres on traffic analysis for behavioural modelling; Vectra emphasises sensors inside the VPC with no endpoint agent dependency, which maps directly onto the third blind spot above; Darktrace takes an unsupervised behavioural baseline approach. The same product in a continuously tuned environment and in a "installed and left alone" environment can differ by an order of magnitude — a statement closer to the truth than any comparative review.

The real enterprise risk is ordering. Telemetry coverage precedes detection rules, and detection rules precede automated response. Skipping straight to an orchestration platform means the platform ingests low-quality input and produces more alerts requiring human adjudication, while analyst hours go to confirming false positives.

On the small-team side the constraint inverts: dedicated detection engineering may not be available, so the strategy has to trade platform-native capability for headcount. A sensible starting order is to enable and centralise the most useful edge, cloud, and identity logs; configure MFA and available anomalous-login alerts; and address checkout-page script risks where relevant. A managed service can be evaluated in parallel if the business lacks the capacity to monitor and respond to incidents, provided the provider's scope and data access are clearly defined.

Three things need confirming before signing with a managed provider: whether it includes investigation and remediation rather than alert forwarding alone, whether it runs 24×7, and whether logs and forensic data are delivered to the customer. MSSP commonly refers to managed security services such as monitoring, technology administration, and alert handling, while MDR typically places greater emphasis on threat detection, investigation, and response. Actual service boundaries vary by provider and contract, so buyers should verify monitoring hours, escalation, containment authority, investigation depth, and data ownership rather than rely on the service label alone. The third point matters most — without data delivery there is no post-incident review and no way to self-evidence compliance.

Edge platforms can provide useful visibility without a full enterprise security stack. Cloudflare offers DNS Analytics and Security Analytics, while client-side script monitoring is available through its Client-Side Security capabilities. Feature availability, query windows, and retention vary by dataset, account scope, and plan; these details should be checked against current product documentation before deployment. Verdant Supply's problem was not simply the absence of data — it was the lack of a process for reviewing available signals and retaining the evidence needed for an investigation. "Collected" and "operationally visible" are two different things, and that distinction matters more than any single product recommendation.

Both scales share one ordering test. Try to answer three questions: which external domains has this host contacted in the past thirty days? Is there periodic beaconing outside working hours? Is there outbound traffic or DNS query volume at an anomalous scale? If any one of the three cannot be answered, fix collection first. Buying detection products into an environment with incomplete collection buys a nicer presentation of the data you already have.

Operating Discipline: What Separates a Working Deployment from Shelfware

Where identical tooling produces wildly different outcomes comes down to a handful of disciplines.

Baseline before rules. Without thirty days of normal state, every "anomalous" judgement is a guess. Maya can recognise a 47-second cadence as wrong only because the system knows what that host's connections normally look like.

Do the retention maths first. Use rolling storage for full packet capture, retain protocol metadata according to investigation and compliance needs, and preserve notable events for deeper analysis. Retention should be derived from specific business, contractual, and regulatory requirements rather than a universal default: where a twelve-month lookback is required, confirm which data sources and evidence types must be available for that period. Full packet capture can be retained in tiers, balancing investigative value, storage cost, privacy, and access controls. Log bills consuming a substantial share of the security budget is not unusual.

Measure quality, not volume. Track alert precision, true-positive detection rate, MTTD/MTTR, and rule coverage against ATT&CK techniques. "Blocks" is a flawed metric because it rewards false positives at the same time: a SIEM producing thousands of alerts a day with a high false-positive rate trains analysts to click dismiss by reflex, which is more dangerous than having fewer alerts.

Feed change events into the analysis context. Releases, cloud configuration changes, new SaaS onboarding, and firewall rule edits all break baselines. If a new customer-service script ships on a Tuesday, the egress profile shifts; without change context, genuine anomalies get buried in noise while routine changes get flagged.

Keep the chain of custody. Who collected what, when, with hashes, storage location, and onward handling. Once scenario B enters notification and potential dispute, the completeness of that chain determines whether the conclusion holds up.

Write the encryption trade-off into policy. Default to the metadata path, enable decryption only for necessary traffic, and record scope, justification, and approver.

Verify continuously. Use atomic tests and purple-team exercises to confirm controls actually fire. An annual penetration test satisfies a compliance checkbox; it does not substitute for ongoing validation.

The Regulatory Clock: NIS2, DORA, CRA, GDPR, and PCI DSS in Practice

Regulation matters here less as paperwork than as an external countdown that forces certain actions to run in parallel rather than in sequence.

For entities within scope, NIS2 establishes a staged reporting process for significant incidents: an early warning within twenty-four hours of becoming aware of the incident, an incident notification within seventy-two hours, and a final report generally within one month of the incident notification. Applicability depends on the entity's sector, size, national implementation, and any relevant exceptions; the employee and turnover thresholds are not a universal test that can be applied without checking those conditions. The practical meaning of the twenty-four-hour mark is that incident response, evidence preservation, and legal assessment may need to begin in parallel rather than wait for a complete investigation. Under GDPR, a controller must generally notify the competent supervisory authority within seventy-two hours of becoming aware of a personal data breach where the breach is not unlikely to result in a risk to individuals' rights and freedoms. Verdant Supply's sixty-three hours to discovery would leave little time for assessment and notification if the relevant reporting obligations applied.

DORA has applied since 17 January 2025, imposing ICT third-party risk management and resilience testing requirements on financial entities; contracts need to specify vendor incident-notification timelines and obligations to cooperate with logging and forensics. The Cyber Resilience Act entered into force on 10 December 2024, with vulnerability and incident reporting obligations applying from 11 September 2026 and full application from 11 December 2027 — teams shipping products with digital elements need vulnerability handling and reporting processes in place ahead of that.

Two PCI DSS v4.0.1 requirements are particularly relevant to in-scope e-commerce environments. Requirement 6.4.3 addresses the authorisation, integrity, and inventory of scripts loaded and executed in consumers' browsers on payment pages, including documented justification for each script. Requirement 11.6.1 addresses detection of unauthorised changes to payment-page content and relevant HTTP headers, at least once every seven days or at a frequency established through the applicable targeted risk analysis. Their precise application depends on the entity's payment-page architecture, validation method, and scope. These controls address risks such as e-skimming through unauthorised or compromised third-party scripts.

For a small team, the practical effect is to first establish which scope it falls into, then separate mandatory controls from nice-to-haves. Get the scope wrong and the investment direction follows it off course.

AI in the Traffic Layer: What It Takes Over, What It Leaves Behind

Between late 2025 and 2026, the most visible change in this layer is the automation of triage.

Alert triage and enrichment are usable today. CrowdStrike's Charlotte AI provides agentic triage and response workflows; Microsoft Security Copilot ships agents for phishing triage, alert triage, and conditional access optimisation; platforms such as Splunk and Tines handle orchestration. Between them they absorb the repetitive "classify — enrich — preliminary verdict — recommended action" sequence, leaving humans to review and to make high-risk calls. Vendor-published effectiveness figures (triage accuracy, hours saved per week) are vendor-reported, typically benchmarked against the vendor's own experts, and deserve a discount when read; the reduction in Tier 1 repetitive work itself is real.

Natural-language querying and query-language translation lower the cross-platform barrier: asking "which external domains has this host contacted in the past seven days" in plain English, or converting between SPL, KQL, and cloud query dialects, helps newcomers and multi-platform environments alike. On detection, models can draft Sigma rules from ATT&CK techniques, propose narrowing conditions based on false-positive samples, and generate test cases — output that must be human-reviewed and regression-tested before production. On documentation, timeline reconstruction, draft incident reports, notification drafts for management and regulators, and multilingual translation remove the most labour-intensive writing, which is exactly what the twenty-four and seventy-two-hour windows need. On vulnerabilities, combining KEV, EPSS, asset exposure, and reachability compresses tens of thousands of CVEs into the few dozen that genuinely require remediation.

The limits are equally clear. Hallucination is a live risk: a model can classify a real threat as benign, miss a critical IOC, or recommend a remediation that widens the blast radius — so the operating rule is that AI proposes and humans conclude, AI drafts and humans sign. Missing business context causes collateral damage: automated response can lock a critical authentication path or halt a core service, and the prevailing practice is to write human-in-the-loop and "AI-caused business disruption" governance into policy, keep human confirmation on high-risk actions, and never treat "the AI did it" as an exculpatory explanation. Prompt injection is a new attack surface: instructions can hide in email bodies, page content, and log fields to induce an agent into exceeding its authority, which means agents must be governed as internal identities — least privilege, action allowlists, full audit logging. On data residency, sending logs containing PII, credentials, or source code to third-party models requires assessing DPAs, redaction, and data residency, with EU contexts especially sensitive.

Attackers are also using automation to scale phishing, reconnaissance, and vulnerability discovery. This increases the value of defensive automation, particularly for teams facing high alert volumes or limited staffing. What automation can replace most readily is repetitive throughput; consequential decisions still require appropriate human oversight, clear permissions, and tested safeguards.

Two Timelines, One Lesson

Every step of Atlas's handling had data behind it: cadence from L2 metadata, lateral scope from identity-side cross-validation, and a rule that shipped only after replay verification. Verdant Supply was missing three collection paths and two switches. For teams with dedicated staff, the order is roughly: close visibility gaps, establish baselines, set retention and cost boundaries, turn detection into code with regression testing, then validate continuously through exercises and metrics. Skip any step and you pay for it later.

For small teams without dedicated security staff, the work can be grounded item by item in published standards:

Accounts and access: minimise admin accounts, enforce MFA/passkeys, keep passwords in a manager, disallow personal email for admin registration (CIS Controls v8.1 IG1).
Asset and software inventory: including a third-party app/plugin inventory, with stale plugins removed regularly (CIS Controls v8.1 IG1).
Log centralisation and retention: centralise egress DNS, cloud flow logs, and admin login logs, with defined retention (CIS Controls v8.1 IG1).
Backup and restore testing: Maintain protected backups, consider offline or immutable copies, and regularly test restoration against documented recovery objectives (CIS Control 11, Data Recovery).
Checkout script control: script inventory, individual written authorisation, change and tamper detection (PCI DSS v4.0, 6.4.3 and 11.6.1).
Email domain security: Configure SPF and DKIM, then deploy DMARC with a policy appropriate to the domain's verified sending sources and enforcement readiness. Move toward p=reject after legitimate senders have been identified and reporting has been reviewed. These controls reduce direct domain spoofing but do not eliminate business email compromise (BEC), account takeover, or messages sent from lookalike domains.
Incident response process: build decision criteria, a decision tree, isolation authority, and forensic and notification paths per NIST SP 800-61r3 (finalised April 2025, superseding 800-61r2, restructured around the six CSF 2.0 functions).
Vendor terms: incident notification timelines, log and forensic cooperation, audit rights (CIS Control 15; financial customers additionally under DORA).

The value of this layer rests on something plain: attackers have to communicate, and communication leaves a shape. Whoever can see that traffic at the moment it happens still has nine hours. Whoever cannot receives a payments risk email sixty-three hours later.

References

AWS, 2026 VPC Flow Logs limitations https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-limitations.html
National Institute of Standards and Technology (NIST), 2025 SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile https://csrc.nist.gov/pubs/sp/800/61/r3/final
Zeek Project, 2026 Zeek Logs Documentation https://docs.zeek.org/en/current/reference/logs/index.html
PCI Security Standards Council, 2025 New Information Supplement: Payment Page Security and Preventing E-Skimming https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming

Menu