Security

Network Security Monitoring — What to Collect, Where, and How to Act on It

J Jaspreet Singh July 24, 2025 6 min read
Animated diagram for Network Security Monitoring, showing traffic arriving at a policy wall where two flows are allowed through and two are dropped at the boundary

Network Security Monitoring (NSM) is the practice of collecting network data, analysing it for signs of compromise, and acting on what you find. It rests on a blunt assumption: prevention eventually fails. Something will get in. NSM exists to shorten the gap between that happening and you knowing about it.

That gap is the metric that matters. Industry breach reports consistently put median attacker dwell time in weeks or months, and the difference between an incident and a disaster is usually how long they had before anyone noticed.

What NSM Is Not

  • Not network performance monitoring. SNMP polling and uptime graphs answer “is it working”, not “is something wrong with what is crossing it”.
  • Not a firewall. Firewalls enforce policy. NSM observes what happened after policy was applied.
  • Not a product you buy. Sensors and a SIEM are components. NSM is the collection, detection and response loop around them.

The Data Sources, Compared

SourceWhat it gives youStorage costRetention that is realistic
Full packet captureEverything, byte for byte. Definitive during an investigation.EnormousHours to days
Session / transaction logs (Zeek)Who talked to whom, when, over what protocol, how much, plus protocol detail like HTTP hosts, DNS queries, TLS certificatesLowMonths to years
Flow data (NetFlow, IPFIX, sFlow)Connection metadata only, addresses, ports, bytes, timingVery lowYears
Alert data (IDS)Signature and anomaly hitsLowYears
Device and host logsAuthentication, firewall decisions, process activityModerateMonths to years

The instinct is to reach for full packet capture. The better first investment is session logs. They cost a fraction of the storage, survive encryption (you still see who connected to what, for how long, with which certificate), and answer the question you will actually ask six weeks later: what else did this host talk to?

Sensor Placement

A sensor only sees traffic that crosses it. Placement determines what you can detect at all.

  • Internet egress, the highest-value single position. Command-and-control beaconing and data exfiltration must cross it, and unlike ingress it is not buried under internet background scanning.
  • Inside the perimeter firewall, shows what was permitted, not what was already blocked.
  • DMZ, your most-attacked assets.
  • Between server VLANs (east-west), where lateral movement happens, and the position most organisations lack.
  • VPN and remote-access concentrator, remote sessions bypass much of the physical topology.

Getting traffic to the sensor

Switch(config)# monitor session 1 source vlan 10 , 20 both
Switch(config)# monitor session 1 destination interface GigabitEthernet0/24

SPAN is free but oversubscribes easily, mirroring several gigabit ports into one silently discards the excess. A hardware TAP is lossless and fails open. Anywhere the evidence needs to be complete, use a TAP.

What to Actually Look For

Rather than trying to detect every technique, cover the behaviours an attacker cannot avoid:

BehaviourWhat it looks like in the data
BeaconingRegular, low-volume connections to the same destination at a consistent interval. Jitter makes it harder to see but the periodicity usually survives.
ExfiltrationOutbound volume far exceeding inbound on a host that normally does the reverse; large transfers to storage or paste services; long-lived encrypted sessions at unusual hours.
DNS tunnellingHigh query volume to one domain, long or high-entropy subdomains, unusual record types such as TXT or NULL.
Lateral movementA workstation connecting to other workstations on SMB or RDP; one host authenticating to many.
ScanningOne source touching many destinations or many ports in a short window.
New or rare destinationsFirst-time connections to newly registered domains or countries you have no business relationship with.
Protocol on the wrong portSSH on 443, HTTP on 8443, visible to application identification, invisible to port-based rules.
Certificate anomaliesSelf-signed certificates, mismatched SNI, or JA3 fingerprints associated with known tooling.

Note that most of these survive TLS. You do not need to decrypt traffic to notice that a workstation contacts one host every 47 seconds, all day, and has done so since Tuesday.

A Practical Stack

LayerJobCommon tools
CaptureGet traffic off the wireTAP, SPAN, NetFlow export
Protocol analysisTurn packets into session recordsZeek
Signature detectionMatch known-bad patternsSuricata, Snort
Aggregation and correlationJoin network, host and identity eventsSIEM, Elastic, Splunk, Wazuh, OpenSearch
EnrichmentAdd asset, user and threat-intel contextCMDB, directory, intel feeds
ResponseContain, investigate, remediateSOAR, or a documented runbook

Security Onion bundles most of the open-source pieces if you want a working system without integrating each component yourself.

Getting It Working Rather Than Just Installed

  1. Know your assets first. An alert on 10.20.4.17 is meaningless without knowing what that is and who owns it. Asset inventory is a prerequisite, not a nice-to-have.
  2. Start at egress. One well-placed sensor there beats five badly placed ones.
  3. Collect session logs before packets. Cheaper, longer retention, more useful in practice.
  4. Baseline before alerting. Run in observe-only mode for several weeks. You will find things you did not know were on the network.
  5. Tune relentlessly. An analyst who ignores the console because it cries wolf is worse than no console.
  6. Write the response before the alert fires. Each detection needs a documented action, or it is just a notification.
  7. Synchronise time. NTP across every device. Correlating logs with skewed clocks is close to impossible.
  8. Test it. Generate benign traffic that should trigger a rule and confirm it appears end to end. Silent sensor failure is common and, by definition, quiet.

Measuring Whether It Works

  • Mean time to detect, the number NSM exists to reduce.
  • Mean time to respond, detection without response changes nothing.
  • Alert-to-incident ratio, thousands of alerts producing no incidents means the tuning is wrong.
  • Coverage, what percentage of network segments have a sensor. Usually the most uncomfortable metric.
  • Detection gaps found in exercises, purple-team work reveals what the stack silently misses.

How It Relates to the Rest of Your Controls

NSM is the detective layer. It assumes the preventive layers, firewalls, segmentation, ACLs, port security, are in place and will occasionally be bypassed. It pairs naturally with a Zero Trust approach, where the assumption of breach is explicit in the architecture. Full picture in the network security guide.

Frequently Asked Questions

What is the difference between network monitoring and network security monitoring?

Network monitoring watches availability and performance, is the link up, is latency acceptable. NSM watches for evidence of compromise in the traffic itself. Different data, different questions, usually different teams.

Do I need full packet capture?

Not to start. Session logs and flow data answer most investigative questions at a fraction of the cost. Add rolling full capture at your highest-value chokepoint once the basics are running, with retention measured in days.

Can NSM work if all traffic is encrypted?

Yes, with reduced depth. Metadata, endpoints, timing, volume, certificates, JA3 fingerprints, SNI, DNS queries, reveals beaconing, exfiltration and scanning without any payload visibility. Selective TLS inspection at the egress point adds payload depth where privacy and legal constraints permit.

How long should logs be retained?

Longer than your likely dwell time. Given that intrusions are frequently discovered months later, session and flow logs held for under 90 days often cannot answer the questions an investigation asks. Twelve months is a reasonable target for metadata.

Is a SIEM the same as NSM?

No. A SIEM aggregates and correlates events from many sources; NSM is specifically the network-derived portion of that, plus the collection and response practice around it. A SIEM with no network telemetry has a substantial blind spot.

Where do I get the most value from one sensor?

Internet egress. Every command-and-control channel and every exfiltration attempt has to cross it, and it is far less noisy than the ingress side.

JA
Written by

Jaspreet Singh

Hey! I'm Jaspreet Singh and I completed a degree in Bachelor of Computer Applications. I have 7+ years of experience in the Network & Security Domain as well as the Cloud Infra Domain. So I love to explore my technical knowledge with you.

Leave a Reply

Your email address will not be published. Required fields are marked *