An unfamiliar connection is not automatically an incident. Operating systems regularly contact update servers, time services, certificate authorities, and cloud platforms. Traffic becomes suspicious when it meaningfully differs from the normal pattern for a device, user, service, or network segment and cannot be explained by an approved change.
Useful monitoring begins with that distinction. The aim is not to inspect every packet indefinitely or assume every alert is malicious. It is to build enough visibility to spot unusual behavior early, investigate it with evidence, and reduce avoidable alerts over time.
Establish what “normal” means first
Without a baseline, traffic monitoring produces a noisy list of IP addresses, ports, domain names, byte counts, and timestamps. A baseline supplies the missing context. It documents typical behavior over a representative period, including weekdays, weekends, maintenance windows, backups, and expected bursts of activity.
In a small environment, a baseline can start as a simple inventory:
- Known devices and their owners or roles
- Expected services, such as DNS, web browsing, email, source control, backups, and VPN access
- Normal destinations for business applications and operating-system updates
- Usual protocols and ports for internally hosted services
- Typical upload and download volumes by device category
- Expected activity hours for servers, workstations, and automated jobs
A development workstation may legitimately connect to package registries and code-hosting services over encrypted channels. A database server should usually communicate with a much smaller set of application servers and backup systems. The same destination may be routine for one role and suspicious for another.
Choose the right visibility sources
No single source provides every detail needed for an investigation. Use a combination that fits the network’s size and sensitivity. Collect only data needed for legitimate security and operational work, and make sure monitoring complies with organizational policy, local law, and privacy requirements.
Flow records: broad and efficient
Flow data summarizes network conversations instead of retaining packet contents. Common fields include source and destination addresses, ports, protocol, start and end times, packet counts, and byte counts. NetFlow, IPFIX, and sFlow are common flow-record approaches.
Flows are often a practical starting point because they scale well and expose patterns: a workstation sending an unusually large amount of data outward, a server contacting a new country or provider, or a device opening connections to many internal systems. Their main limitation is that they rarely show what the traffic contained.
DNS logs: valuable context for destinations
DNS logs show which names devices attempted to resolve. They can link an unfamiliar IP address to a domain, reveal sudden use of previously unseen domains, and highlight repeated failed lookups. Encrypted DNS, cached results, hard-coded IP addresses, and content delivery networks can all limit what DNS records reveal.
Firewall, proxy, and VPN logs
Perimeter systems often provide the clearest record of inbound and outbound access decisions. Firewall logs show allowed and denied connections. Web proxies may record URLs or domain categories, while VPN logs can connect remote access to authenticated users and source addresses.
Time synchronization across these systems matters. If timestamps drift, event correlation quickly becomes unreliable.
Packet capture: detailed but selective
Packet capture records individual packets and can provide deep forensic evidence when it is authorized and handled carefully. Captures may contain credentials, personal data, and application content, so use short retention periods, restricted access, and targeted collection rules. A brief capture around a suspected event is often safer and more practical than retaining all traffic continuously.
Tools such as Wireshark and tcpdump are appropriate for troubleshooting systems you own or an approved lab. Work from a defined hypothesis—for example, checking whether a test server is contacting its approved update endpoint—rather than collecting traffic indiscriminately from networks you do not administer.
Define anomalies that matter
Useful detections are tied to behavior and asset roles, not simply a long list of supposedly malicious addresses. Begin with a small set of high-signal conditions, then tune them against known operational activity.
| Pattern | Why it may matter | Common benign explanation |
|---|---|---|
| Large outbound transfer from a workstation | May indicate unintended data exposure or an unauthorized sync tool | Approved backup, video upload, or cloud-drive synchronization |
| New external destination for a sensitive server | Servers often have narrow communication requirements | Vendor update service, certificate renewal, or changed CDN address |
| Connections at unusual times | Can expose unexpected automation or remote activity | Scheduled patching, backup, or a staff member working remotely |
| Repeated connection failures | May signal a broken configuration or unwanted probing | Expired credentials, an offline service, or a mistyped endpoint |
| One host contacting many internal peers | Can indicate discovery-like behavior or a misconfigured application | Asset management, monitoring, or a deployment system |
| Regular small encrypted connections to an unknown host | Periodic communication deserves validation against asset context | Telemetry, software updates, or a legitimate SaaS client |
A pattern becomes more significant when several signals line up. A new domain by itself may be harmless. A new domain contacted by a finance workstation outside normal hours, followed by an unusually large outbound transfer, warrants faster investigation.
Build a safe monitoring workflow
- Inventory assets and owners. Assign names and roles to important systems. An alert for “10.0.2.17” is far less useful than one that identifies a payroll application server.
- Centralize logs. Send firewall, DNS, VPN, endpoint, and flow records to a protected logging platform. Restrict who can alter retention settings or delete records.
- Normalize time and fields. Use a reliable time source and retain consistent fields such as device name, user identity where appropriate, source, destination, protocol, bytes, and action.
- Create a baseline period. Review several normal operating cycles. Record approved services and recurring jobs so they do not generate the same avoidable alerts repeatedly.
- Write narrow detections. Start with rules that reflect your environment: a server communicating outside its allowlist, a large new outbound transfer, or an administrative system accessed from an unexpected network.
- Document triage steps. Every alert needs an owner, severity criteria, evidence to collect, and an escalation path. A detection without a response process soon becomes background noise.
- Review and tune. After each investigation, update the baseline with verified legitimate behavior. Do not broadly suppress a rule simply because one alert turned out to be harmless.
Investigate an alert without jumping to conclusions
Preserve the available evidence first: relevant log entries, timestamps, flow records, alert metadata, and, where policy permits, a targeted packet capture. Then ask focused questions. Which asset initiated the connection? What software or process was responsible? Is the destination associated with an approved vendor? Did a scheduled change, deployment, or update happen at the same time? Are other devices showing the same pattern?
Correlate network observations with endpoint and identity logs. A workstation contacting an unfamiliar service may be explained by a browser extension, a newly installed application, or a developer tool. Endpoint process telemetry can separate those cases from activity with no clear explanation. Do not block a destination solely because it is unfamiliar if doing so might interrupt critical operations; when time permits, confirm the decision with the system owner.
Reduce false positives without losing visibility
False positives are normal, particularly when a monitoring program is new. The answer is better context, not silence. Tag devices by role, maintain allowlists for documented service dependencies, and define maintenance windows. A scheduled database backup that transfers large files every night should be recognized as expected behavior, while the same transfer from an employee laptop should still be reviewed.
Set thresholds with care. A fixed alert for “more than 1 GB” may miss meaningful activity on a high-volume server while generating too many alerts for a lightweight kiosk. Relative thresholds are often more useful: compare a device’s current transfer volume with its own recent history, then account for known events such as releases or backups.
Protect the monitoring system itself
Network telemetry can be sensitive because it exposes internal services, browsing patterns, device names, and communication relationships. Apply least privilege to dashboards and raw logs, encrypt data in transit and at rest, define retention periods, and audit administrative access. Keep collectors and analysis platforms patched; an exposed logging system can become a valuable target.
For a practical first deployment, choose one critical server and record its expected outbound destinations for a week. Create an alert for any new external destination that includes the server name, destination, port, byte count, and first-seen time. Test it during an approved maintenance change. This small exercise checks both the detection and the human process required to handle the alert.
