A Tuesday Morning That Should Have Gone Differently
It starts with a routine alert at 7:43 AM. A single authentication failure on an edge firewall. The IDS logs it, assigns it low severity, and the alert joins a queue of 4,000 others waiting for a human to review. By noon, there have been 200 more. By Friday, an analyst reviewing weekly summaries notices the pattern — a slow, methodical probe of FortiGate management interfaces spread across a five-day window. The credentials exposed in the FortiBleed campaign, which saw authentication data for 73,932 FortiGate systems published publicly, had been tested against the organization's infrastructure one careful attempt at a time.
This scenario is not hypothetical. It describes exactly the kind of low-and-slow reconnaissance that IDS deployments routinely miss because the detection logic is calibrated for volume rather than patience. The recent FortiBleed credential exposure demonstrated that attackers do not always rush. They work within thresholds. They exploit the gap between what IDS systems are configured to flag and what actually constitutes a threat in progress.
This article addresses how to close that gap with practical configuration, smarter baselining, and detection strategies that account for the adversary's actual behavior rather than their theoretical behavior.
Understanding What Your IDS Is Designed to See
Intrusion detection systems fall into two broad categories: signature-based and anomaly-based. Signature-based systems compare traffic against known attack patterns. Anomaly-based systems establish behavioral baselines and flag deviations. Most enterprise deployments use both, but the balance matters significantly in practice.
Signature-based detection is fast and produces low false positives when the signatures are current and well-tuned. Its limitation is that it cannot detect what it has never been told to look for. The Iran-nexus threat group TAG-182, which recently deployed the MarkiRAT surveillance tool against targeted organizations, uses custom tooling specifically designed to avoid known signature sets. Groups like CL-STA-1062, which has been targeting Southeast Asian government infrastructure, operate with techniques that bypass commodity detection precisely because their tools are not widely catalogued.
Anomaly-based detection addresses this gap but introduces its own challenges. Behavioral baselines require time to build, are sensitive to seasonal and organizational changes, and can produce alert volumes that overwhelm analyst capacity. Getting the balance right requires deliberate configuration rather than accepting vendor defaults.
Placement Strategy: Where Your Sensors Actually Go
IDS sensor placement determines what your system can and cannot see. A sensor positioned only at the network perimeter misses lateral movement entirely. The sensor sees inbound and outbound traffic but is blind to an attacker who has already established a foothold and is moving east-west across internal segments.
The minimum viable placement strategy for any organization handling sensitive data or running critical infrastructure includes sensors at:
- The perimeter: Monitoring ingress and egress traffic, capturing inbound attack attempts and outbound command-and-control communications.
- Internal segment boundaries: Particularly between user networks and server infrastructure, and between IT and OT networks where applicable.
- High-value asset zones: Subnets hosting domain controllers, database servers, financial systems, and anything holding credentials or PII.
- Cloud ingress points: Where VPNs, remote access gateways, and cloud workloads connect to internal networks.
Organizations that only run perimeter sensors are making an assumption that the perimeter holds. Given the frequency of credential-based attacks, that assumption carries significant risk. The NetNut proxy network disruption earlier this year, which cut off roughly two million infected devices used to route attack traffic, illustrated how attackers use distributed infrastructure to make perimeter blocking ineffective. Traffic arrives from addresses with clean reputations, routed through compromised residential devices, and perimeter rules built on IP reputation offer limited protection.
Baselining for Real-World Networks
Building a behavioral baseline that actually reflects your environment requires more discipline than most teams apply at initial deployment. Default baselining periods of seven or fourteen days capture seasonal variation poorly and often include existing anomalous traffic from incidents already in progress.
A practical approach to building baselines works in three phases. During the first phase, spanning roughly thirty days, you observe without alerting on anomaly-based rules. You document what normal traffic volumes look like across different times of day and days of the week. You identify legitimate administrative tools that generate traffic patterns resembling attack behavior — network scanners, backup agents, patch management systems.
During the second phase, you introduce anomaly-based alerts at high thresholds, accepting that you will miss some genuine attacks while you refine what normal looks like. You adjust thresholds based on the false positive rate your team can actually investigate without alert fatigue setting in.
During the third phase, you tighten thresholds incrementally, correlating anomaly alerts with other telemetry sources to determine which signals carry genuine investigative value. This is ongoing work, not a one-time exercise.
Rule Tuning Without Creating Blind Spots
Alert fatigue is the mechanism by which IDS deployments become decorative. When analysts face thousands of low-confidence alerts daily, high-confidence alerts for genuine attacks get buried. The instinct is to suppress noisy rules, but suppression creates blind spots that attackers eventually find and exploit.
The structured approach to tuning involves categorizing rules into three groups rather than treating suppression as binary:
High-fidelity rules produce few false positives and should alert immediately with high priority. These include rules detecting known malicious payloads, exploitation attempts against specific CVEs, and protocol violations that have no legitimate use case.
Medium-fidelity rules produce moderate false positives in context but high-confidence signals when correlated with other events. These should feed into correlation logic rather than producing standalone alerts. A single authentication failure against an RDP service is medium fidelity. The same failure correlated with an external IP that has also probed ports 22, 443, and 8443 in the same hour becomes high fidelity.
Low-fidelity rules should log to a searchable index rather than generating alerts. They contribute to threat hunting workflows and post-incident analysis without creating real-time alert volume your team cannot handle.
The browser-only ransomware techniques recently documented, where attackers leverage browser storage and JavaScript execution to encrypt files accessible through web interfaces, fall into a detection category that many IDS rule sets have not yet addressed. These attacks produce minimal traditional network indicators because they operate within legitimate HTTPS sessions. Detection requires monitoring for anomalous data access patterns at the application layer, which signature-based rules alone cannot capture.
Correlation as the Multiplier
A single IDS alert rarely tells a complete story. Correlation between IDS events and other data sources is what transforms detection capability from reactive to predictive.
The practical correlation workflow starts with defining what combinations of events should produce escalated responses. Some combinations that consistently indicate genuine attacks in progress:
- IDS alert for scanning behavior from an external IP, followed within 60 minutes by an authentication attempt from the same IP against any internal service.
- IDS alert for a known vulnerability probe against a specific host, correlated with that host initiating outbound connections to non-standard ports within 30 minutes.
- Multiple low-severity IDS alerts from different internal hosts communicating to the same external IP, which may indicate command-and-control activity spreading across an already-compromised network.
- DNS queries for recently registered domains from workstations that have also triggered IDS alerts for unusual outbound traffic patterns.
The phantom squatting problem, where attackers register AI-hallucinated package names and domains to intercept supply chain dependencies, produces DNS query patterns that IDS correlation can surface. A workstation querying an unusual domain that resolves to an IP with no prior traffic history from your environment warrants investigation even if the individual IDS alert carries low severity.
Handling Encrypted Traffic Without Breaking Architecture
A practical challenge that many IDS deployment guides understate is the reality that a substantial portion of modern attack traffic arrives over encrypted channels. HTTPS, encrypted C2 protocols, and TLS-wrapped lateral movement all reduce the visibility of traditional deep packet inspection.
Several approaches address this without requiring full SSL inspection, which introduces its own security risks and operational complexity.
JA3 fingerprinting identifies TLS clients by their handshake characteristics. Malware families tend to use consistent TLS configurations that differ from legitimate browsers and applications. JA3 signatures for known malware families like those used by MarkiRAT provide detection without decrypting traffic.
Certificate analysis examines the characteristics of TLS certificates presented by external servers that internal hosts connect to. Self-signed certificates, certificates with very short validity periods, and certificates issued by unknown certificate authorities all warrant elevated scrutiny, particularly when the connecting host has already triggered other IDS events.
NetFlow and traffic metadata analysis examines communication patterns rather than content. Beaconing behavior — regular outbound connections to an external IP at consistent intervals — is visible in flow data even when the content is encrypted. Automated beaconing detection looks for the periodicity and volume consistency that characterizes C2 polling.
Response Integration: When the Alert Fires
Detection without a defined response workflow produces the same outcome as no detection at all. The value of an IDS is realized in the actions taken after the alert, not in the alert itself.
Every alert category in your IDS should map to a documented response procedure. High-fidelity alerts for known exploitation attempts should trigger automated containment actions where your architecture supports it: blocking the source IP at the perimeter, isolating the affected host at the network level, and notifying the on-call analyst simultaneously. The time between exploit attempt and successful code execution in modern attacks is often measured in seconds. Automated response at this tier is appropriate.
Medium-fidelity alerts should route to an analyst queue with a defined response time objective. The investigative workflow should be documented: which additional data sources to query, what questions to answer before escalating or closing the alert, and what constitutes sufficient evidence to move from investigation to containment.
Low-fidelity alerts should feed a threat hunting queue rather than an incident queue. Analysts reviewing these alerts are looking for patterns over time rather than responding to individual events. This is where the intelligence value of IDS logging is realized in the weeks and months after initial deployment.
Testing What You Have Deployed
IDS configurations that have never been validated against realistic attack simulations provide uncertain coverage. The gap between what the deployment documentation says should be detected and what is actually detected in practice can be substantial, particularly for deployments that have not been updated or tested since initial rollout.
Breach and attack simulation tools can replay attack techniques across the MITRE ATT&CK framework and report which IDS rules triggered and which did not. Running these simulations quarterly, and particularly after significant network changes, provides concrete evidence of detection coverage rather than assumptions about it.
Red team exercises provide a more realistic test of end-to-end detection and response capability. A red team operating with the techniques used by threat actors like CL-STA-1062 — slow reconnaissance, targeted credential use, living-off-the-land movement — will expose gaps in IDS coverage that automated simulation may miss.
Tabletop exercises test the human and process components rather than the technical ones. Presenting your team with a realistic attack scenario and walking through the detection and response workflow exposes coordination gaps, undefined escalation paths, and documentation that exists in theory but has not been internalized by the people responsible for executing it.
Keeping Detection Current in a Changing Threat Environment
The threat landscape that your IDS was configured to detect twelve months ago differs from what it faces today. Rule sets require ongoing maintenance, and the threat intelligence informing those rules needs to reflect current adversary behavior rather than historical patterns.
Subscribing to high-quality threat intelligence feeds that include indicators of compromise from recent campaigns provides signature updates ahead of the standard vendor release cycle. The MarkiRAT campaign, the FortiBleed credential exposure, and the browser-based ransomware techniques documented recently all produce indicators that can be translated into IDS rules within hours of public disclosure if your process supports rapid rule deployment.
Participating in industry threat intelligence sharing groups provides access to indicators that have not yet reached public disclosure, including IOCs from organizations that have agreed to share data from active investigations. For organizations in critical infrastructure sectors, sector-specific ISACs provide targeted intelligence relevant to your threat profile.
Reviewing and retiring rules that no longer reflect active threats is as important as adding new ones. A rule set that has grown organically over five years without pruning contains signatures for exploit techniques that have not been observed in the wild for years. These rules consume processing resources, occasionally produce false positives, and dilute the signal-to-noise ratio in your alert stream.
The Bigger Picture These Practices Support
IDS best practices do not exist in isolation. They feed into a broader security operations model where detection, investigation, and response are continuous and connected rather than episodic. The organizations that catch intrusions early share certain characteristics: they baseline carefully, they correlate across data sources, they test their assumptions, and they treat rule maintenance as ongoing operational work rather than a deployment task completed at rollout.
The current threat environment, where nation-state groups are deploying custom surveillance tools, credential databases from large-scale exposures are actively exploited, and novel attack techniques emerge faster than vendor signature updates, requires detection systems that are genuinely operational rather than nominally deployed. The configuration decisions made in the next thirty days determine whether your IDS catches the next campaign in progress or documents it in retrospect.
