The Threat Environment That Makes This Conversation Urgent
The past few months have delivered a sequence of incidents that should recalibrate how security teams think about intrusion detection. The Novo Nordisk breach exposed how software development pipelines carry risk that most IDS deployments treat as out of scope. The emergence of Xdr33, a variant of the CIA's HIVE attack kit, signals that sophisticated offensive tooling continues to leak into the hands of threat actors who know how to operate below conventional detection thresholds. The Gentlemen's EDR killer framework has demonstrated that attackers are actively targeting the very tools organizations rely on for detection. And the June 2026 Patch Tuesday broke records for volume, meaning unpatched surface area is larger than ever across enterprise environments.
Against this backdrop, intrusion detection systems (IDS) occupy a central position in most organizations' defense architecture. The practical reality is that many of those deployments are operating in ways that guarantee missed detections. This article works through what IDS best practices actually look like when applied to current threat patterns, with concrete implementation details and real-world scenarios that reflect what security teams encounter in production environments.
Understanding What Your IDS Is Actually Measuring
An IDS generates value only when it is measuring the right things in the right places. The fundamental architectural decision, whether to deploy a network-based IDS (NIDS), host-based IDS (HIDS), or a hybrid combination, determines what the system can and cannot observe. Most organizations deploy NIDS at the perimeter and assume coverage is sufficient. That assumption creates blind spots that sophisticated attackers actively exploit.
Network-based sensors placed only at the perimeter cannot observe east-west traffic between internal systems. When ransomware groups conduct lateral movement after initial access, or when a compromised endpoint begins enumerating internal assets, perimeter sensors produce no signal. The Gentlemen's ransomware group, identified in recent threat intelligence reporting, exemplifies this operational pattern: initial access happens at the boundary, but the dwell time and damage accumulation happen entirely on internal segments the IDS never sees.
Host-based IDS addresses this gap but introduces its own operational challenges. HIDS agents on endpoints consume resources, require maintenance, and generate host-level telemetry that must be centrally aggregated and correlated. When Xdr33, a variant of the HIVE implant, operates on a compromised host, a properly configured HIDS with file integrity monitoring and process behavior analysis will surface anomalies that a network sensor simply cannot detect, particularly when the malware uses encrypted command-and-control channels.
The practical recommendation is a tiered architecture: NIDS at network ingress/egress points and at internal segment boundaries, combined with HIDS on high-value assets including domain controllers, certificate authorities, build servers, and any system involved in software development pipelines. The Novo Nordisk pipeline breach illustrates precisely why build infrastructure deserves HIDS coverage. Attackers who compromise a CI/CD pipeline can operate entirely within legitimate-looking processes unless host-level telemetry is collected and analyzed.
Signature Management as an Active Practice
Signatures are the foundation of most IDS deployments, and they become liabilities the moment they stop being actively managed. The threat intelligence community regularly documents signature drift: organizations that deployed rule sets years ago and never revisited them end up with detection logic chasing attack patterns that current adversaries have abandoned.
The WSzero DDoS family, now in its fourth version and propagating via 21 distinct vulnerabilities, illustrates how quickly attack tooling evolves. A signature that detects WSzero version 2 traffic patterns may produce no signal against version 4. Organizations that treat signature updates as a quarterly maintenance task rather than a continuous operational responsibility create detection gaps that attackers can map and exploit.
Effective signature management includes several concrete practices. First, subscribe to multiple threat intelligence feeds and map incoming indicators to specific IDS rules. When a new CVE appears in active exploitation, a corresponding detection rule should be deployed within hours, not weeks. The record-breaking June 2026 Patch Tuesday created hundreds of potential detection opportunities for vulnerabilities that attackers will probe almost immediately. Teams with signature deployment pipelines can act on that intelligence; teams with manual processes cannot.
Second, run regular rule efficacy reviews. Pull the last 90 days of IDS alerts and identify which rules fired, which produced true positives, and which generated only noise. Rules that have never fired against real traffic in six months are candidates for review: either the threat they detect is no longer active in your environment, the rule is misconfigured, or attackers have adapted their techniques to avoid it. All three scenarios require action.
Third, supplement commercial and community signatures with custom rules derived from your own threat hunting findings. When your team investigates an incident or a suspicious host and identifies specific network behaviors, encode those behaviors as IDS rules. Custom signatures built from direct environmental observation tend to have higher fidelity than generic community rules because they are calibrated to your actual traffic baseline.
IDS Deployment Checklist for Production Environments
The following checklist consolidates the configuration and operational decisions that determine whether an IDS deployment catches real attacks or generates noise.
- Sensor placement audit: Document every network segment and confirm that IDS sensors have visibility into traffic on that segment. Pay particular attention to cloud workload traffic, container orchestration networks, and any segments added in the last 12 months. Container environments receive special mention because vulnerabilities in containerized workloads, as highlighted in recent Kaspersky Container Security research, can be exploited in ways that are invisible to sensors not positioned inside the container network fabric.
- Encrypted traffic visibility: Determine what percentage of your monitored traffic is TLS-encrypted and whether your NIDS has SSL/TLS inspection capability or receives decrypted traffic from a termination point. Attackers routinely encrypt C2 traffic, and surveillance camera access sold by cybercriminals, as recently documented, often communicates over encrypted channels that blind sensors without decryption capability.
- Baseline traffic profiling: Establish documented baselines for normal traffic volumes, protocols, and endpoint behavior before tuning alert thresholds. Without a baseline, threshold-based alerts are guesses.
- Alert triage workflow: Define and document who receives each alert category, what the expected triage time is, and when an alert escalates. An IDS that fires alerts into a queue with no defined response path provides no security value regardless of detection quality.
- Integration with SIEM: Confirm that IDS events are forwarded to your SIEM in real time, with correct field mapping. Alerts that sit in a standalone IDS console are not receiving correlation analysis against authentication logs, endpoint telemetry, and threat intelligence feeds.
- HIDS coverage inventory: Maintain an accurate list of all hosts with HIDS agents installed, with version information and last check-in timestamps. Agents that have not reported in 48 hours represent coverage gaps.
- Signature update frequency: Confirm that automatic signature updates are enabled and verify the update cadence. For environments with active threat exposure, daily updates are a minimum.
- False positive rate tracking: Track the ratio of true positives to false positives per rule category over time. Rising false positive rates signal rule drift or environmental change and degrade analyst trust in the system.
- Decoy asset coverage: Deploy honeypot assets on internal segments and configure your IDS to treat any traffic destined for those assets as high-confidence alerts. Honeypots produce near-zero false positives and are particularly effective at catching lateral movement.
- Coverage validation testing: Run simulated attack traffic against your IDS monthly to confirm that specific rule categories are firing as expected. Use tools like Atomic Red Team or CALDERA to generate controlled test traffic mapped to MITRE ATT&CK techniques.
Behavioral Detection and Anomaly-Based Rules
Signature-based detection operates well against known attack patterns but produces no signal against novel techniques. Behavioral and anomaly-based detection closes part of this gap by identifying deviations from established baselines rather than matching against specific patterns.
The practical implementation of behavioral detection requires meaningful baseline data. An anomaly engine that flags a host for making 200 DNS requests per hour is only useful if you know that the normal rate for that host is 20 requests per hour. Behavioral IDS components that are deployed into an environment without a baselining period generate excessive false positives because they have no reference point for normal activity.
A concrete scenario: a student loan servicer environment handling the data of millions of borrowers, similar to the breach that exposed 2.5 million records, typically has predictable database access patterns. Specific application servers query specific databases during business hours, with volumes that correlate to user activity. An IDS with behavioral rules can detect when a database begins receiving queries from a host that has never accessed it before, or when query volumes spike outside business hours. Those behaviors map directly to credential misuse and data exfiltration patterns, and they do not require a signature that describes the specific attack tool in use.
When deploying behavioral detection, define specific behavioral rules rather than relying entirely on machine learning models to surface anomalies. Machine learning anomaly detection is valuable but requires expertise to interpret its output. Rule-based behavioral detection, such as alerting when a non-administrative host performs LDAP queries against Active Directory, or when a server initiates outbound connections to external IP addresses it has never contacted, produces alerts with clear investigative starting points.
The macOS Tahoe 26 artifact discovery reported in recent threat intelligence highlights another behavioral detection opportunity. New forensic artifacts in updated operating systems create both detection opportunities and evasion risks. Organizations running macOS endpoints should update their HIDS rules to collect and analyze new artifact types as operating system versions change, treating OS updates as trigger events for detection rule review.
Tuning for Precision Without Sacrificing Coverage
Alert fatigue is a documented operational failure mode. Security teams that receive thousands of low-fidelity alerts per day develop habits that cause them to miss the alerts that matter. Tuning an IDS to reduce noise is legitimate and necessary, but it requires a structured approach that avoids suppressing genuine detection capability.
Start with scope tuning rather than threshold tuning. Many high-volume alert sources are legitimate traffic that a specific rule was not designed to handle. An IDS rule watching for port scanning behavior may fire constantly against a vulnerability scanner that your own security team runs weekly. Whitelisting the scanner's source IP removes noise without changing the rule logic, preserving detection capability against actual port scanning from unknown sources.
Address threshold tuning only after scope tuning is complete. Raising alert thresholds to reduce volume is a legitimate tool but carries risk. If you raise the threshold for a DNS tunneling detection rule because your environment produces many DNS requests normally, ensure that the new threshold still catches realistic attack volumes. Reference threat intelligence data on actual DNS tunneling traffic patterns before setting thresholds based on intuition.
Document every tuning decision. Every whitelist entry, every threshold change, and every rule suppression should be recorded with the rationale, the date, and the name of the person who made the change. Tuning decisions accumulate over months and years. Without documentation, teams lose track of why specific rules are configured the way they are, and the collective effect of many small tuning decisions can produce significant blind spots.
Run quarterly tuning audits in which a team member reviews all suppression rules and whitelists with fresh eyes. Sources that were whitelisted 18 months ago may no longer be valid. An IP range whitelisted for a vendor relationship that has since ended represents an unnecessary blind spot. Removing stale exceptions restores detection coverage at no cost other than the time spent reviewing them.
IDS in Cloud and Hybrid Environments
Cloud workloads present specific IDS deployment challenges. Traditional network tap-based NIDS cannot operate in public cloud environments where there is no physical network layer to tap. Cloud providers offer native traffic mirroring capabilities (AWS Traffic Mirroring, Azure vTAP, GCP Packet Mirroring) that allow network-based IDS sensors to be deployed in virtual form, receiving mirrored traffic from cloud VPCs and virtual networks.
Container environments require additional attention. Traffic between containers on the same host does not traverse the host network interface in ways that traditional sensors can observe. A container-aware IDS or network policy enforcement layer with logging capability is needed to capture inter-container traffic. Kubernetes network policy engines with audit logging, combined with runtime security tools that analyze container process behavior, provide the equivalent of NIDS and HIDS coverage within container clusters.
Configuration drift in cloud environments is a persistent problem. Security groups, network ACLs, and logging configurations change through infrastructure-as-code deployments, manual console operations, and automated scaling events. An IDS that was correctly positioned in the network topology at deployment may lose visibility if a new subnet is added without updating traffic mirroring configurations. Implement infrastructure-as-code linting rules that enforce IDS sensor visibility requirements as part of the deployment pipeline, preventing coverage gaps from entering production environments silently.
For hybrid environments spanning on-premises infrastructure and cloud workloads, centralized SIEM correlation is the mechanism that makes cross-environment detection possible. IDS events from on-premises sensors and cloud-native security logs must converge in a single correlation platform for analysts to trace attack paths that cross environment boundaries. Attacks targeting software development pipelines, as demonstrated in the Novo Nordisk breach, frequently involve activity in both on-premises development workstations and cloud-hosted build infrastructure. Without cross-environment correlation, the attack path is fragmented across separate monitoring systems and lateral movement goes undetected.
Common Implementation Pitfalls
Several recurring mistakes undermine IDS deployments that were well-designed at the outset. Understanding these pitfalls helps teams avoid repeating the same operational failures that incident postmortems consistently document.
Treating deployment as completion. An IDS is not a set-and-forget control. The threat landscape changes continuously, as the emergence of the Gentlemen's EDR killer framework makes clear. Attackers actively research detection capabilities and adapt their techniques to avoid triggering specific signatures. An IDS deployed without ongoing maintenance becomes progressively less effective against current attack patterns while still consuming analyst attention for legacy alerts.
Insufficient coverage of internal segments. Organizations place sensors at the perimeter and treat internal network traffic as trusted. This assumption no longer reflects reality in environments where phishing, supply chain compromise, and credential theft enable attackers to establish footholds inside the network. Segment boundaries, particularly those separating development systems, financial systems, and domain controllers from general user networks, require their own sensor coverage.
Missing coverage for management interfaces. Network devices, servers, and security appliances expose management interfaces that are high-value targets. Cybercriminals selling access to Chinese surveillance cameras, as documented in recent threat intelligence, typically obtain that access through compromised management credentials or unpatched vulnerabilities in administrative interfaces. IDS rules monitoring management plane access, such as unexpected SSH connections to network devices or unusual authentication patterns against out-of-band management systems, provide detection capability that generic network monitoring rules miss.
Logging without retention. IDS alerts are most useful when investigators can query historical data during incident response. Alert logs retained for only 30 days limit the ability to reconstruct attack timelines, particularly when attackers operate with extended dwell times. Retain IDS logs for at minimum 90 days in hot storage with 12 months of cold storage, aligned with your organization's incident response requirements and any applicable regulatory obligations.
Ignoring lateral movement signatures. Most IDS deployments are heavily weighted toward detecting initial access and external threat patterns. Lateral movement techniques such as pass-the-hash, Kerberoasting, and remote service exploitation between internal hosts receive less signature coverage in default rule sets. Explicitly audit your signature library for lateral movement coverage and supplement community rules with custom detections for the specific Active Directory and Windows authentication patterns that indicate credential misuse.
Skipping agent health monitoring. HIDS agents that stop reporting are indistinguishable from hosts with no agent installed from a coverage perspective. Implement automated monitoring that alerts when any HIDS agent misses two consecutive check-ins. Treat agent health as a security-relevant metric and include it in your security operations reporting.
Assuming encrypted traffic is not a problem because you cannot read it. The inability to decrypt traffic is not a reason to stop collecting metadata. Even without decryption, flow data, connection frequency, destination reputation, certificate characteristics, and packet timing patterns provide meaningful signals. JA3 and JA3S fingerprinting of TLS handshakes, for example, allows detection of malware families based on their TLS implementation characteristics without requiring decryption of the payload.
Building Operational Discipline Around IDS Outputs
The technical capability of an IDS is only as valuable as the operational discipline surrounding it. Teams that have invested in quality sensors, current signatures, and proper network positioning still fail to catch attacks when the operational layer breaks down.
Define alert severity tiers with explicit response time requirements. Critical alerts, such as detections of known exploit traffic or confirmed C2 communication patterns, should trigger immediate analyst response. High-severity alerts should be reviewed within 30 minutes. Medium and low alerts can be batched for review but should not be indefinitely deferred. Without explicit time requirements, analyst triage prioritization becomes ad hoc, and critical alerts can sit unreviewed during busy periods.
Conduct regular tabletop exercises that use IDS alert scenarios as starting points. Take a realistic IDS alert, such as detection of an internal host performing LDAP enumeration, and walk through the investigation process: what data would an analyst pull next, what would confirm or deny malicious intent, and what would trigger escalation to incident response. Tabletops reveal gaps in investigation playbooks before those gaps matter during a real incident.
Measure and report on IDS performance metrics including detection latency (time from attack activity to alert generation), triage latency (time from alert generation to analyst review), and escalation rate (percentage of alerts that result in incident response engagement). These metrics provide visibility into whether the IDS and the surrounding operational process are performing as intended, and they create accountability for improvement over time.
The current threat environment rewards operational discipline. Attackers are investing in tools designed to evade and disable detection systems, as the Gentlemen's EDR killer framework demonstrates. An organization that maintains disciplined IDS operations, with current signatures, validated coverage, and fast triage processes, presents a meaningfully harder target than one that has deployed capable technology but allowed operational practices to drift.
