The Breach That Started in a Place Nobody Was Watching
The Novo Nordisk breach exposed something that security teams across industries already suspect but rarely address directly: software development pipelines are high-value targets, and most intrusion detection systems are tuned for the wrong environment when attackers enter through them. When credentials, secrets, or code repositories become the initial access point, IDS deployments built around perimeter traffic patterns often generate silence at exactly the wrong moment.
This is not an isolated problem. The student loan breach that exposed 2.5 million records followed a similar pattern of delayed detection, where the intrusion completed before any meaningful alert reached an analyst. The emergence of Xdr33, a variant of the CIA's HIVE attack kit, adds another layer of urgency. Xdr33 is designed to blend into normal traffic patterns, making signature-based detection insufficient without behavioral correlation layered on top. These incidents together describe a detection environment where standard IDS deployments are routinely outpaced by adversaries who have mapped the gaps in advance.
This article focuses on what intrusion detection systems should actually be doing in 2026, grounded in the attack patterns showing up in real environments right now. It covers architecture decisions, tuning priorities, detection logic, and the implementation errors that silently degrade coverage over time.
Understanding What Modern Attackers Actually Trigger
Before adjusting any IDS configuration, security teams need an accurate picture of what modern attack chains look like in terms of observable network and host behavior. The Gentlemen's EDR killer framework, recently documented in threat intelligence reporting, demonstrates that sophisticated actors are actively suppressing endpoint detection before moving laterally. When EDR tooling is disabled or blinded at the endpoint level, the IDS becomes the last reliable detection layer for lateral movement. That shifts the burden significantly.
The WSzero DDoS family, now in its fourth version and propagating through 21 vulnerabilities, illustrates how automated exploitation tools have accelerated. IDS rules written to catch WSzero version two will miss version four if the detection logic depends on static payload patterns rather than behavioral indicators like anomalous scanning cadence or unexpected connection rates to specific port ranges.
Ransomware groups including The Gentlemen operate by identifying and exploiting behavioral blind spots in detection stacks. Their methodology involves extended dwell time, minimal noise during reconnaissance, and staged exfiltration that mimics normal data movement. An IDS tuned purely for volumetric anomalies will miss the early phases of this entirely.
The sale of access to Chinese surveillance cameras by cybercriminals underscores a different angle: compromised IoT and embedded devices are now used as persistent footholds inside network segments that IDS deployments rarely inspect with the same rigor applied to servers and workstations. These devices generate legitimate-looking traffic by design, which makes behavioral baselining essential rather than optional.
Architecture Decisions That Determine Detection Coverage
Placement Strategy for Network IDS Sensors
Sensor placement is the single most consequential architectural decision in any IDS deployment. Most organizations concentrate sensors at the perimeter and treat east-west traffic as implicitly trusted. This assumption breaks under almost every modern attack scenario where initial access has already occurred.
Effective sensor placement follows the principle of covering all traffic segments where lateral movement could complete undetected. This means sensors at network segment boundaries, not just at the internet edge. In environments with development pipelines, sensors belong on the network segments hosting CI/CD infrastructure, build servers, and artifact repositories. The Novo Nordisk breach type specifically targets these segments because they are frequently connected to both development workstations and production environments through automation.
In cloud environments, network-based IDS must account for traffic that never crosses a physical sensor. VPC flow logs, cloud-native IDS services, and agent-based host intrusion detection fill gaps that physical sensors cannot reach. Treating cloud workloads as extensions of the on-premises network for detection purposes requires deliberate architecture, not assumption.
Choosing Between Network and Host-Based Detection
Network intrusion detection systems (NIDS) and host-based intrusion detection systems (HIDS) serve different purposes and catch different attack phases. NIDS excels at detecting scanning, exploitation attempts, command-and-control communication, and exfiltration. HIDS catches file system changes, privilege escalation, process anomalies, and persistence mechanisms that produce no distinct network signature.
The Gentlemen's EDR killer framework targets endpoint agents directly. Organizations relying solely on HIDS agents face the same suppression problem. This makes a layered approach mandatory: NIDS provides a detection layer that cannot be disabled by killing a process on the target host, while HIDS provides context about what is happening at the system level that network traffic alone cannot reveal.
Containers and microservices introduce additional complexity. Kaspersky's work with container security analysis highlights that vulnerabilities within containerized workloads often produce attack behaviors that cross container boundaries in ways that neither traditional NIDS nor HIDS fully covers. Container-aware intrusion detection that understands pod-to-pod communication and API server access patterns represents a genuine capability gap in most deployments.
Detection Logic That Holds Under Real Attack Conditions
Signature Management as a Living Process
Signature sets decay. Rules written to detect a specific exploit or malware variant become less relevant as attackers modify their tools. The A Record-Breaking Patch Tuesday for June 2026 released fixes for a significant number of vulnerabilities simultaneously, meaning attackers are actively developing exploits for newly patched vulnerabilities while defenders are still deploying updates. Signature coverage for these vulnerabilities needs to arrive before exploitation becomes widespread, which requires a signature update process that runs on a short cycle tied to threat intelligence feeds.
Effective signature management involves three parallel tracks. The first is maintaining up-to-date vendor signatures that cover known exploits and malware families. The second is developing custom signatures for attack patterns specific to your environment, including your software stack, your network topology, and the specific tools your adversaries are known to use. The third is regularly retiring signatures that generate high false-positive rates without catching real attacks, because noise degrades analyst attention and obscures genuine alerts.
Behavioral Detection for Threats That Signatures Miss
Xdr33, as a variant of the HIVE attack kit, is engineered to avoid signature detection. Its network communication patterns are designed to blend with legitimate traffic. Catching it requires behavioral rules that flag anomalies rather than match known patterns. This includes detecting unusual beacon intervals, encrypted traffic to unexpected destinations on unusual ports, or connections from internal hosts that have no documented reason to initiate outbound connections.
Behavioral detection rules should target the following categories of activity:
- Internal hosts initiating connections to external IP addresses with no prior communication history and no business justification
- Repeated failed authentication attempts followed by successful authentication from the same source, particularly during off-hours
- Lateral movement indicators such as SMB connections from workstations to server segments or RDP connections between systems that do not normally communicate
- DNS queries for recently registered domains, domains with high entropy names, or domains queried by only a single internal host
- Large data transfers to external destinations during atypical time windows, particularly from systems that handle sensitive data
- Execution of scripting engines or administrative tools from process parents that would not normally spawn them
Protocol Anomaly Detection
Protocol anomaly detection flags traffic that violates the expected behavior of a given protocol even when the payload matches no known malicious signature. HTTP requests with malformed headers, DNS queries with unusually long labels, or TLS handshakes using deprecated cipher suites can all indicate exploitation attempts or tunneling. This detection approach adds coverage that complements signature matching without requiring knowledge of the specific attack being used.
Tuning Priorities That Improve Signal Quality
An IDS that generates thousands of alerts per day without analyst capacity to review them provides worse security than a well-tuned system generating hundreds of high-confidence alerts. Alert fatigue is a documented failure mode, not a theoretical concern. Security teams that have experienced a major breach after an alert was missed during a high-volume period understand the operational cost directly.
Tuning starts with establishing accurate baselines. Before suppressing any alert category, analysts need to understand what normal looks like in their specific environment. Internal port scanning by a vulnerability management system looks identical to attacker reconnaissance in signature terms. Suppressing port scan alerts without first verifying that the scanning source is always the authorized vulnerability scanner introduces a blind spot. Baselining should cover traffic volumes, connection patterns, authentication behavior, and DNS query patterns across a period long enough to capture weekly and monthly cycles.
After baselining, suppression rules should be applied by source IP, destination IP, or specific signature with documented justification. Every suppression rule should have a review date. Environments change, authorized scanners get decommissioned, and suppression rules that were accurate six months ago may now be hiding real attacks.
Alert Prioritization and Severity Calibration
Not all IDS alerts represent equal risk. A detection that flags a potential SQL injection attempt against a system that runs no database requires different handling than the same detection against a system that hosts customer financial data. Contextualizing alerts with asset criticality data transforms IDS output from a flat list of potential events into a prioritized queue.
Severity calibration should reflect actual business risk. An alert for a known-exploited vulnerability affecting a public-facing system running an unpatched version belongs at the top of the queue. An alert for the same signature targeting a system known to be patched belongs lower. This requires integrating asset inventory data, patch status, and business function into the IDS workflow, which is a process requirement rather than a purely technical one.
IDS Best Practices Checklist
Use this checklist as an operational reference for evaluating and improving your IDS deployment. Each item represents a validated practice derived from real-world incident patterns.
- Sensor coverage audit: Verify that sensors cover all network segments where sensitive data moves, including east-west traffic paths, development pipeline segments, and cloud workload communications.
- Signature update cadence: Confirm that signature updates are applied within 24 hours of release and that the update process is automated with manual verification for rule sets applied to critical segments.
- Custom rule development: Maintain a library of environment-specific detection rules covering your unique application stack, internal communication patterns, and known adversary TTPs relevant to your industry.
- Behavioral baseline documentation: Document normal traffic patterns for all monitored segments and review baselines quarterly or after significant infrastructure changes.
- Suppression rule inventory: Maintain a complete list of all active suppression rules with documented justification and scheduled review dates, with no rule older than 90 days without review.
- Asset criticality integration: Connect IDS alerting to an asset inventory that includes criticality ratings so that alert prioritization reflects business risk.
- Log retention and correlation: Ensure IDS logs are retained for a minimum of 12 months and are ingested into a SIEM for correlation with authentication, endpoint, and application logs.
- Out-of-hours coverage: Verify that alerting and escalation procedures function outside business hours, since many breaches begin during low-coverage periods.
- Container and cloud workload coverage: Confirm that detection capabilities extend to containerized workloads and cloud-native services, rather than stopping at the virtual machine or physical network boundary.
- Lateral movement detection rules: Test that IDS rules flag unexpected internal-to-internal connections, particularly RDP, SMB, and administrative tool usage across segment boundaries.
- Exfiltration detection: Implement rules that flag large outbound transfers, particularly during off-hours, and monitor for data movement to cloud storage services that are not authorized for business use.
- EDR correlation: Integrate IDS alerting with endpoint detection data so that analysts can correlate network-level indicators with process and file system activity on the same host.
- Red team validation: Conduct purple team exercises specifically designed to test IDS coverage by simulating the attack techniques most relevant to your threat model, including the TTPs used by active ransomware groups.
- IoT and embedded device monitoring: Apply the same detection logic to network segments hosting IoT devices, cameras, and embedded systems as to server segments.
- Threat intelligence integration: Feed current threat intelligence including IOCs from active campaigns into IDS signature sets and blocklists on a daily cycle.
macOS Artifacts and the Detection Gap in Endpoint-Centric Environments
The discovery of new macOS Tahoe 26 artifacts is a useful illustration of how detection gaps emerge from platform assumptions. Many IDS deployments are designed around Windows-centric attack patterns because that is where most enterprise workloads run. Development environments, creative teams, and executive users on macOS represent a segment where both NIDS and HIDS coverage is often weaker, and where network behavior baselining has received less attention.
When a new artifact type appears on macOS, organizations that have not baselined normal macOS network behavior have no reliable way to detect the anomalous activity that artifact usage might produce. This applies equally to Linux workstations and cloud instances running Linux-based containers. Platform diversity in modern environments requires platform-diverse detection logic, not a single set of rules applied uniformly regardless of the operating system generating the traffic.
Implementation Pitfalls That Undermine Deployed Systems
Treating Deployment as Completion
The most common and most damaging mistake in IDS operations is treating the initial deployment as the completion of the project. An IDS deployed 18 months ago and tuned against the threat landscape of that period is progressively less effective against current attack techniques. The attack kit variants, the new DDoS families, the EDR killers, and the pipeline compromises documented in current threat intelligence were not all present 18 months ago. Detection logic must evolve continuously to remain relevant.
Establish a formal review cycle that includes signature currency, suppression rule validity, sensor placement adequacy, and behavioral baseline accuracy. Quarterly reviews are a reasonable minimum. High-risk environments warrant monthly reviews.
Ignoring Encrypted Traffic
A significant and growing percentage of malicious traffic uses encryption. IDS deployments that do not incorporate TLS inspection or at minimum TLS metadata analysis are blind to command-and-control communication, encrypted exfiltration channels, and malware delivery over HTTPS. TLS inspection introduces operational complexity and requires careful handling of certificate trust, but the alternative is accepting a large detection gap for an attack category that attackers actively exploit.
Where full TLS inspection is not feasible, metadata analysis of TLS handshakes provides partial coverage. JA3 fingerprinting identifies client-side TLS behavior patterns associated with specific malware families. Certificate characteristics such as self-signed certificates, recently issued certificates, or certificates with mismatched common names can indicate malicious infrastructure even without decrypting the payload.
Siloing IDS from the Broader Security Stack
An IDS operating in isolation from SIEM, EDR, and threat intelligence platforms produces alerts that analysts cannot contextualize quickly. An IDS alert indicating a connection attempt to a known malicious IP means one thing when it appears alone. It means something significantly different when correlated with an EDR alert showing that the initiating process was spawned by a script executed from a CI/CD pipeline, in the context of a breach like the one affecting Novo Nordisk's development pipeline.
Integration work is ongoing maintenance, not a one-time configuration task. API changes, schema updates, and platform upgrades all have the potential to break integrations silently. Verify that data flows from IDS to downstream platforms on a scheduled basis, and alert on integration failures as a first-class operational event.
Underestimating the Maintenance Burden of Custom Rules
Custom rules written to address specific threats in your environment require maintenance as your environment changes. A rule that flags connections from a development server to an external IP may become a false positive generator after the development team legitimately begins using a cloud-based dependency management service. Without a process for reviewing custom rules against current environment knowledge, the rule set accumulates noise sources that degrade analyst confidence in the entire alert stream.
Assign ownership to custom rule sets. The team or individual that wrote a rule should be responsible for reviewing it when the environment changes in ways that might affect its accuracy. Document the threat scenario each custom rule is designed to detect so that future reviewers can evaluate whether the rule remains appropriate.
Skipping Validation After Configuration Changes
Configuration changes to IDS sensors, rule sets, or suppression lists should trigger validation testing. Deploying a new suppression rule without verifying that it does not inadvertently cover attack traffic is a common source of detection gaps. Use controlled test traffic that matches known attack patterns to confirm that suppression rules are scoped correctly and that modified rule sets still trigger on the behaviors they are designed to catch.
This validation step is often skipped under operational pressure, particularly during high-volume change windows like the patch cycles following a major Patch Tuesday release. Building validation into the change management process rather than treating it as optional prevents the accumulation of silent gaps in detection coverage.
Where Intrusion Detection Actually Earns Its Place
The incidents documented in recent threat intelligence, from pipeline compromises to surveillance camera hijacking to EDR suppression frameworks, share a common characteristic: they succeed in environments where detection capabilities have not kept pace with attacker sophistication. An IDS that was well-configured 18 months ago and has received minimal maintenance since is not a security control. It is a record-keeping system that generates logs nobody reads until after the breach is confirmed.
Intrusion detection earns its place in the security stack through continuous investment in tuning, integration, coverage validation, and threat intelligence alignment. The teams that catch intrusions early are not running fundamentally different technology. They are running the same technology with more discipline, more current rule sets, and more rigorous integration with the rest of their detection stack. That discipline is achievable in any organization willing to treat IDS operations as ongoing work rather than a deployment milestone.
