The Uncomfortable Starting Point
Most organizations configure their intrusion detection systems during a calmer moment, after a vendor demo, after a compliance audit, or after a near-miss incident that shook the team briefly. The IDS gets deployed, rules get imported from a default signature pack, and the system starts producing alerts. From that point forward, many teams treat alert volume as a proxy for security coverage. If the system is firing, it must be working.
That assumption is precisely how modern attackers stay inside enterprise networks for weeks before anyone notices. The FortiBleed credential leak, which exposed VPN credentials for more than 73,000 Fortinet devices, is a sharp illustration of this problem. Attackers who used those credentials did not trigger intrusion alerts in many environments because they authenticated legitimately. The IDS was watching for malicious packets. The attacker arrived with a valid key.
This article addresses what intrusion detection systems actually need to do in 2024, given attacker behaviors that have evolved well past what default signature packs were designed to catch. The goal is a practical playbook, not a philosophical argument about detection philosophy.
Understanding What Attackers Are Actually Doing Now
Before tuning any IDS, security teams need an accurate picture of current attacker behavior. Two trends from recent months are directly relevant to how IDS deployments should be structured.
The first is credential-based lateral movement. The sweeping credential-harvesting campaign that compromised more than 30,000 Fortinet devices showed attackers moving laterally using stolen VPN and administrative credentials. No exploit required. No malformed packet. The network traffic looks like authorized access because technically it is. Signature-based detection alone produces nothing useful here.
The second is session-based attacks that bypass password theft entirely. The EvilTokens phishing technique targets session tokens rather than credentials, meaning multi-factor authentication provides no protection at the point of interception. An attacker using a stolen session token generates traffic that is indistinguishable from legitimate user activity at the packet level. Your IDS needs behavioral context, not just signatures, to catch this class of attack.
Ransomware groups are also exploiting behavioral blind spots by operating slowly and quietly during the reconnaissance and staging phases, reserving conspicuous activity for the encryption phase when detection does you the least good. By the time a ransomware IDS alert fires, the dwell time may already be measured in weeks.
Signature Coverage Is a Floor, Not a Ceiling
Signature-based detection remains valuable. It catches known malware callbacks, exploit attempts against patched vulnerabilities, and reconnaissance patterns that attackers use repeatedly. But treating signatures as the primary detection mechanism leaves enormous gaps for exactly the attacks making headlines right now.
A well-maintained IDS deployment treats signature coverage as the baseline and builds behavioral detection on top of it. That means several concrete things in practice.
First, your signature set needs active curation, not just vendor updates. Default rulesets contain thousands of signatures, many of which generate noise against your specific environment without producing actionable intelligence. Audit your active signatures quarterly. Identify which rules have never fired in six months and whether that reflects genuine security or a misconfigured sensor. Identify which rules fire constantly and whether those alerts are being acted on or silently ignored.
Second, supplement signatures with protocol anomaly detection. This catches attackers who use legitimate protocols in unusual ways, HTTP over non-standard ports, DNS queries with unusually high entropy payloads, SMB traffic from workstations that have never initiated SMB sessions before. These patterns do not require matching a known signature. They require knowing what normal looks like for your environment.
Third, map your signature coverage to the MITRE ATT&CK framework. This exercise reliably surfaces gaps. Most default signature packs have strong coverage for initial access techniques and weak coverage for persistence, privilege escalation, and lateral movement. Those later stages are precisely where attackers spend most of their time after the initial breach.
Sensor Placement That Actually Reflects Attack Paths
Where you put your sensors determines what you can see. Many IDS deployments concentrate sensors at the network perimeter and treat internal east-west traffic as implicitly trusted. This architecture reflects a threat model that attackers abandoned years ago.
Modern intrusion paths follow a consistent pattern: gain access through a perimeter control, establish a foothold on one internal system, then move laterally to higher-value targets. The lateral movement phase generates traffic that your perimeter sensors never see because it never crosses the perimeter. It crosses internal segment boundaries, moves between workstations and servers, uses administrative protocols that your perimeter rules were not designed to inspect.
Practical sensor placement should include coverage at these specific points.
- Internal segment boundaries: Sensors between user workstation segments and server segments catch lateral movement that perimeter sensors miss entirely.
- Database and application server egress: Unusual outbound connections from servers that do not normally initiate external traffic are a reliable signal of data staging or command-and-control activity.
- Active Directory and identity infrastructure: Reconnaissance against domain controllers generates distinctive traffic patterns. Kerberoasting, AS-REP roasting, and DCSync attacks all have detectable network signatures when sensors are positioned to see the traffic.
- Cloud workload integration: Container environments and cloud-native workloads often exist outside the visibility of on-premises IDS sensors. Container security tooling needs to feed into the same detection pipeline, not operate as a siloed system.
Encrypted traffic presents a specific placement challenge. When most east-west traffic is TLS-encrypted, network-based signatures lose effectiveness. The practical response is a combination of metadata analysis (connection frequency, data volume, timing patterns, certificate characteristics) and host-based IDS agents that can inspect traffic before encryption or after decryption at the endpoint. Neither approach alone is sufficient for modern environments.
Building Behavioral Baselines That Actually Hold
Behavioral detection requires knowing what normal looks like. That sounds straightforward. In practice, establishing accurate baselines is where many implementations stall or produce so many false positives that analysts stop trusting the system.
Effective baseline construction has several characteristics that distinguish it from approaches that fail.
Baselines need to be scoped to specific asset categories rather than averaged across the entire environment. The network behavior of a domain controller, a developer workstation, a point-of-sale terminal, and a cloud API server have almost nothing in common. A single organizational baseline produces anomaly alerts that are technically true and operationally useless. Build baselines per asset category, and where possible per individual high-value asset.
Baselines need to account for cyclical variation. Enterprise environments have weekly patterns, monthly billing cycles, quarterly reporting periods, and annual events that all affect what normal traffic looks like. A baseline built during a slow week will produce excessive alerts during a high-activity period. Collect at least four to six weeks of data before treating any behavioral model as production-ready, and schedule model updates to refresh seasonally.
Baselines need explicit handling for change events. When a new application is deployed, when a software update changes connection patterns, or when a team moves to a new segment, the behavioral model needs to be updated. Without a process for this, legitimate infrastructure changes continuously erode confidence in behavioral alerts and teams start ignoring them, which is the outcome attackers are counting on.
Alert Triage That Stops the Noise from Burying the Signal
The most common reason IDS deployments fail is not technical. It is operational. Alert fatigue is real, and it is dangerous. An analyst team that receives ten thousand alerts per day and can meaningfully investigate fifty of them is not fifty alerts away from comprehensive detection. They are effectively flying blind while generating the appearance of security activity.
Alert prioritization needs to be built into the detection pipeline, not handled manually by analysts on each shift. Several approaches work in practice.
Contextual enrichment at the point of alert generation significantly improves triage speed and accuracy. When an alert fires, it should already contain information about whether the source IP has appeared in threat intelligence feeds, whether the destination asset is classified as high-value, whether similar alerts have fired recently for the same source, and whether the behavior is consistent with known attack chains. Analysts making triage decisions without this context spend most of their time gathering information rather than making decisions.
Correlation rules that chain related low-confidence alerts into high-confidence detections catch attacks that would individually produce only noise. A single failed authentication attempt is noise. Twenty failed authentication attempts from the same source across fifteen different accounts over four minutes is a password spray. A subsequent successful login from the same source ten minutes later is a confirmed breach in progress. The individual events are ambiguous. The chain is not.
Suppression rules for known-good behavior need active maintenance. When a monitoring tool generates the same alert every day because its traffic pattern resembles reconnaissance, adding a suppression rule is correct. But suppression rules that are never reviewed become permanent blind spots. Audit suppression rules on the same schedule as signatures. Understand why each suppression exists and whether the rationale still holds.
Responding to What the IDS Actually Finds
Detection without response planning produces reports, not security outcomes. This point is worth making clearly because many organizations treat IDS deployment as a detection problem and treat response as someone else's concern. In practice, how quickly and accurately a team responds to an IDS alert determines whether an incident is contained in minutes or discovered after the encryption starts.
Each alert category in your IDS should map to a documented response playbook before that alert type fires in production. The playbook does not need to be long, but it needs to answer specific questions: who receives the alert, what information do they need to verify it, what actions are they authorized to take without escalation, and what actions require escalation and to whom.
Automated response for specific high-confidence alert categories reduces mean time to contain significantly. An IDS alert that identifies active command-and-control beaconing from a known malware family, confirmed against multiple independent signals, is a category where automated isolation of the affected host is appropriate. The cost of a false positive isolation is an inconvenienced user. The cost of a missed true positive in that category is measured in data loss and recovery time.
For alerts that require human judgment, response time is a function of shift coverage, escalation clarity, and decision authority. Review these factors explicitly. A detection that fires at 2 AM on a Sunday and sits unreviewed until Monday morning gives attackers a sixteen-hour window with no friction. That window matters, particularly given how the Netherlands law enforcement operation that seized 800 servers and arrested two individuals for aiding cyberattacks illustrates that some attackers operate continuously across time zones.
Specific Configuration Practices Worth Implementing
The following items are concrete configuration and process changes that address the gaps most commonly found in IDS deployments during security assessments.
- Enable logging for allowed traffic on high-value segments, not just blocked or alerted traffic. Allowed traffic logs are where lateral movement and data exfiltration live. Many IDS deployments only log what they alert on, which means the baseline data needed to identify anomalies is never collected.
- Configure alerts for authentication events to high-privilege accounts from any source that has not previously authenticated to that account. This catches credential abuse, including the class of attack demonstrated in the Fortinet credential compromise campaigns, where valid credentials are used from new source addresses.
- Set up specific detection for unusual DNS behavior: high query volume from a single host, queries for domains with high entropy names, DNS queries for recently registered domains, and DNS responses with unusually short TTL values. DNS-based command-and-control continues to be effective against environments that do not specifically monitor for it.
- Implement detection for unusual service account behavior. Service accounts that suddenly initiate interactive logon sessions, access file shares they have never touched, or generate Kerberos tickets for services outside their normal scope are a reliable indicator of credential compromise or misuse.
- Review IDS coverage for AI-assisted attack tooling. The incident where attackers used Meta's AI support bot to seize Instagram accounts illustrates that AI-assisted social engineering and account takeover techniques are in active use. Behavioral detection for account takeover patterns, including session anomalies, unusual API call sequences, and access from new device fingerprints, addresses this class of attack where signature detection is entirely ineffective.
Measuring Whether Your IDS Is Actually Working
Teams that do not measure IDS effectiveness cannot improve it. Several metrics provide meaningful signal, as distinct from metrics that look good in reports without telling you anything about actual security outcomes.
Detection coverage against simulated attacks, using purple team exercises or automated breach simulation tools, tells you which attack techniques your IDS catches and which it misses. Run this at least quarterly against your current MITRE ATT&CK coverage map. Treat every technique that completes without generating an alert as a gap that needs a remediation plan.
Mean time to detect, measured from the point of initial compromise in a simulated scenario to the first alert, tells you whether your detection latency is acceptable given attacker dwell time data. The industry benchmark for mean time to detect has improved over the past several years, but many organizations still measure in days. Days of undetected access after initial compromise is enough time for most threat actors to complete their objectives.
Alert-to-investigation ratio and investigation-to-confirmed-finding ratio together tell you whether your alert quality is improving or degrading. If your team is investigating a large proportion of alerts but confirming a very small proportion as true positives, your tuning process needs attention. Conversely, if your confirmed finding rate is high but total alert volume is very low, you may be suppressing alerts that deserve investigation.
The Operational Discipline That Separates Effective from Ineffective Deployments
Technical configuration matters. Operational discipline matters more. The IDS deployments that consistently catch real attacks and minimize dwell time share a set of practices that are less about technology and more about how teams work.
They treat the IDS as a system that requires ongoing maintenance, not a product that was configured once and is now operational. Signatures age. Baselines drift. Attack techniques evolve. An IDS that was well-tuned eighteen months ago may have significant gaps today if no one has maintained it.
They conduct regular reviews of what the IDS is not seeing, not just what it is alerting on. This requires periodic threat intelligence review against current IDS coverage, tabletop exercises that walk through specific attack scenarios and ask whether the IDS would catch each stage, and honest post-incident reviews when an attack reaches a late stage before detection.
They ensure that IDS output feeds into a broader security operations process with defined accountability. An alert that fires and is never reviewed is not detection. It is the appearance of detection. The distinction matters when a breach investigation reconstructs the timeline and finds that the IDS fired at hour two and the alert sat in a queue until hour seventy-two.
The attackers making headlines right now, whether they are harvesting credentials from VPN devices at scale, hijacking sessions without touching passwords, or staging ransomware deployments across weeks of quiet reconnaissance, are not being caught by organizations that deployed an IDS and walked away. They are being caught, when they are caught, by organizations that built detection systems around how those attackers actually behave and maintained those systems as attacker behavior evolved.
