Introduction: Security Products Cannot Protect an Organization on Their Own
- IDS: Intrusion Detection System
- IPS: Intrusion Prevention System
These systems monitor network traffic or system activity to identify signs of potentially malicious behavior. An IPS is intended to go a step further by taking preventive action, such as blocking traffic that matches a detection condition.
But detecting suspicious activity and preventing damage are not the same thing. Traffic outside the monitored scope remains invisible. An alert does not change the situation unless someone has the responsibility and authority to act on it. A product may also fail to perform as expected when its configuration, certificates, log collection, or detection rules are not properly maintained.
This article explains the basic roles and limitations of IDS/IPS, examines incidents involving Equifax, Target, and SolarWinds, and considers what these cases reveal about modern detection technologies and security operations.
Key points
- An IDS/IPS can inspect only the traffic and activity it is able to observe.
- Detection is the beginning of incident response. Damage is limited only when detection leads to investigation, decisions, containment, and recovery.
- Adding AI/ML or expensive monitoring products does not eliminate data gaps, false positives, missed detections, or operational shortcomings.
- Management is responsible for providing the budget, people, decision-making authority, and practical priorities needed for the organization to respond.
1. What Do IDS and IPS Detect and Prevent?
An IDS/IPS is not a device that stops every attack. It is one layer of defense: it identifies suspicious signs in the traffic or activity it can monitor, may block activity when configured to do so, and records information that can support investigation.
| Function | What it does | Why it matters to the organization |
|---|---|---|
| IDS | Detects, records, and reports suspicious traffic or activity | Provides clues that can help the organization recognize an attack and begin investigating |
| IPS | Takes preventive action, such as blocking traffic that meets defined conditions | Can stop some matching attacks before they reach the protected system |
| Anomaly and behavior analysis | Examines traffic volume, destinations, usage patterns, protocol deviations, and other signals | Can provide leads on activity that does not match known attack patterns |
| Logs and alerts | Records detection details and notifies relevant people or systems | Supports incident response, audits, post-incident reviews, and improvements to detection rules |
IDS and IPS do not necessarily refer to separate products. A single product may provide both capabilities. They can also be deployed as network-based systems that inspect traffic in transit, or as host-based systems that monitor activity on individual servers and endpoints. For an IPS to block activity, it must be deployed in a position where it can control the relevant traffic, or have the ability to take preventive action on the host. Organizations should therefore verify a product’s placement, configuration, and enabled features rather than relying on its name alone. [1]
Monitoring Technologies Have Different Roles and Areas of Visibility
IDS/IPS and related products may have similar-sounding names, but they do not all perform the same job. The table below summarizes their general roles. Actual capabilities vary by product and deployment. In particular, NDR overlaps with network-based IDS/IPS, while XDR capabilities may overlap with EDR and SIEM.
| Technology | Information primarily handled | Main role | Important consideration |
|---|---|---|---|
| Network IDS/IPS | Network traffic visible at its observation point | Detects suspicious traffic and blocks it when configured to do so | Visibility depends on sensor placement and network paths |
| Host-based IDS/IPS | Events and activity on servers or endpoints | Monitors or prevents activity involving files, processes, and system behavior | The relevant software must be deployed and managed on each target host |
| EDR (Endpoint Detection and Response) | Endpoint and server processes, files, connections, and user or system activity | Detects and supports response to suspicious endpoint behavior | Sensors must be deployed on the relevant endpoints and their data must be delivered correctly |
| NDR (Network Detection and Response) | Network traffic and traffic metadata | Analyzes network behavior and helps investigate suspicious activity | Coverage depends on the segments and traffic that can be observed; response capabilities vary by product |
| SIEM (Security Information and Event Management) | Logs from networks, endpoints, identity systems, cloud services, applications, and other sources | Aggregates logs and supports detection and investigation through rules and correlation | Collecting logs is not enough: source selection, data quality, analytics, and operations all matter |
| XDR (Extended Detection and Response) | Telemetry from multiple security domains | Correlates information across domains to support detection and response | The integrations and capabilities vary by product; there is no single implementation boundary shared by all vendors |
Network traffic and system activity
|
+---------------+----------------+
| |
v v
+------------------+ +------------------+
| Network | | Endpoints and |
| IDS / IPS | | servers |
+------------------+ | EDR / Host IDS |
| +------------------+
| |
+---------------+----------------+
|
v
+--------------------------+
| SIEM / XDR and similar |
| Log aggregation and |
| correlation |
+--------------------------+
|
v
+--------------------------+
| Human investigation and |
| decisions |
| Containment, recovery, |
| and review |
+--------------------------+
NDR analyzes and correlates network information from another
perspective. Integration and deployment vary by environment.
This is a conceptual diagram of how the roles can relate; it does not mean every organization should adopt the same product stack. The important thing is that the information needed to protect critical assets against the threats an organization faces is observed, analyzed, and delivered to the people responsible for responding.
A network-based IDS/IPS primarily inspects the traffic visible to its sensors. When traffic is encrypted, the system cannot inspect the details of the encrypted payload unless an appropriate decryption and inspection mechanism is in place. Similarly, activity that abuses legitimate credentials or follows valid communication procedures may be difficult to identify as malicious from network traffic alone.
IDS/IPS is an important defensive capability, but it does not guarantee complete protection. Organizations must continuously manage what is monitored, whether the monitoring system is working as intended, who responds to alerts, and how much damage can be contained if an intrusion occurs.
2. Incidents in Which Monitoring Products Failed to Prevent Damage
Real-world incidents show that the problem is not always the absence of security products. Blind spots in monitoring, detection information that did not reach the right people, alerts that did not lead to action, and inadequate containment after an intrusion can all contribute to an incident.
Case 1: The Equifax Data Breach (2017)—Certificate Management and Asset Visibility Failures
In 2017, the U.S. credit reporting agency Equifax suffered a major data breach affecting approximately 148 million people. According to an investigation by the U.S. House of Representatives, attackers exploited a vulnerability in Apache Struts to gain access to an internet-facing web application. The report describes how the affected system remained unpatched after the vulnerability had been disclosed, allowing attackers to obtain and exfiltrate personal information. [3]
Equifax had IDS and IPS systems in place. On March 14, 2017, it added a Snort rule to its IDS/IPS to detect attempts to exploit the Apache Struts vulnerability. However, the report records the introduction of the rule; it does not establish that the rule blocked multiple attacks that day. The following day, a vulnerability scan examined 958 externally facing IP addresses but failed to identify the vulnerable system. The report states that the scanning tool used during remediation did not identify the vulnerable Apache Struts installation. [3]
Another serious problem involved the SSL Visibility Appliance (SSLV), which decrypted encrypted traffic and passed it to inspection systems. The ACIS (Automated Consumer Interview System) was an internet-facing Equifax portal used to handle consumer disputes and related inquiries. According to the House report, the certificate used by the SSLV monitoring the ACIS environment expired on January 31, 2016. Under the appliance’s default configuration, web traffic continued to pass through even after the certificate expired. As a result, the IDS/IPS systems behind it could not inspect the encrypted traffic. When Equifax renewed the certificate on July 29, 2017, suspicious traffic was identified almost immediately. The House report describes the monitoring gap as having lasted 19 months. [3]
Incoming HTTPS traffic
|
v
+----------------------+
| SSL Visibility |
| Appliance (SSLV) |
| |
| Certificate expired |
| Unable to decrypt |
| traffic |
+----------------------+
|
Encrypted traffic passes through
|
v
+----------------------+
| IDS / IPS |
| |
| Unable to inspect |
| the payload |
+----------------------+
|
v
+----------------------+
| ACIS web system |
+----------------------+
The core failure: The monitoring appliance's problem did not
stop traffic or surface as an obvious outage. Traffic continued
without the intended inspection.
This case demonstrates that detection rules alone cannot provide effective protection. Certificate and appliance health, asset inventories, vulnerability scanning, patching, and network segmentation must work together. Even when a monitoring appliance appears to be running, the organization must verify that it is actually inspecting the traffic it is supposed to inspect. [3]
Case 2: The Target Data Breach (2013)—Alerts Did Not Lead to Investigation or Response
In 2013, the U.S. retailer Target suffered a major theft of payment card data and other information. A committee staff report included in a 2014 U.S. Senate hearing record summarized the publicly available reporting and expert analysis at the time. It described how attackers reportedly used credentials associated with a third-party HVAC service provider to gain access to Target’s network and then expanded their activity into internal payment-related systems. The staff report also acknowledged that the full details of the incident had not been established from the public information then available. [4]
According to an investigative report by Bloomberg Businessweek cited in the Senate staff report, Target’s FireEye malware detection system generated an urgent alert when malware intended to facilitate data exfiltration was installed. The report said that Target’s security team did not act on the alert and that the automatic malware-removal feature had not been enabled. The alert reportedly carried the generic name malware.binary. The committee report suggested that, if similar alerts had appeared frequently, the warning might have been treated as a false positive. However, this is a possibility raised on the basis of contemporaneous reporting; it is not established fact that the staff who received the alert actually classified it as a false positive. [4]
The lesson is that the ability to detect an event and the ability to act on the resulting information are two different capabilities. A product may issue an alert, but defense will fail if no one is clearly responsible for reviewing it, assessing its significance, and deciding whether to contain the incident.
Case 3: The SolarWinds Supply Chain Attack (2020)—Threats Hidden in Trusted Software and Traffic
The SolarWinds Orion supply chain attack, which came to light in 2020, involved attackers inserting malicious code into the development and distribution process for Orion software. According to a CISA alert dated December 17, 2020, the malicious DLL was signed with a legitimate SolarWinds code-signing certificate and distributed through software updates. After installation, the malicious communications used techniques designed to imitate legitimate SolarWinds protocol traffic. [5]
In this attack, the apparent legitimacy of the software signature and the resemblance of the network traffic to normal product communications helped conceal the malicious activity. CISA also described initial access methods beyond the Orion compromise. It would therefore be inaccurate to simplify the event by claiming that every intrusion began through Orion, or to state categorically that a particular organization’s IDS/IPS was bypassed despite being deployed. [5][6]
Defending against threats of this kind requires more than network monitoring. Organizations need to correlate information about software publishers, signatures and update histories with process execution, privileged account usage, unusual destinations, and changes in traffic volume. Even when software comes from a trusted source, its update path and behavior after execution need to be considered.
What the Three Incidents Tell Us
| Incident | Main problem | What organizations should learn |
|---|---|---|
| Equifax (2017) | A vulnerable system was not identified and patched, while an expired certificate also left a monitoring path unable to inspect traffic | Continuously verify monitoring health, asset inventories, and vulnerability management as interconnected responsibilities |
| Target (2013) | Detection alerts did not lead to investigation and containment | Define alert priorities, ownership, response deadlines, and decision-making authority |
| SolarWinds (2020) | The attack was concealed within trusted software updates and traffic resembling legitimate communications | Correlate network monitoring with software supply-chain, identity, and endpoint activity |
3. Structural Limitations of IDS/IPS
A system cannot make reliable decisions about traffic or activity that it cannot observe. In addition, even when communication follows a technically valid format, a network device alone may not be able to determine whether the purpose of that activity is legitimate in the context of the business.
| Area that is difficult to detect or prevent | What can happen | Examples of complementary controls |
|---|---|---|
| Encrypted traffic (HTTPS/TLS) | Without decryption and inspection, the details of the encrypted payload cannot be examined | TLS visibility in managed environments, traffic metadata analysis, and endpoint, server, and application logs |
| Access using legitimate credentials | Stolen passwords, session tokens, or API keys may be used through normal procedures, making malicious activity difficult to distinguish from legitimate traffic alone | Multi-factor authentication, least privilege, correlation of authentication and activity logs, and additional checks for sensitive operations |
| Data exfiltration through legitimate cloud services | Data may be concealed within traffic to commonly used cloud storage or external services | Data-loss monitoring, contextual analysis of destinations, volume, and users, and access controls for sensitive data |
| Lateral movement inside the network | After an intrusion, attackers may use ordinary business protocols for host-to-host communication, making perimeter-only controls less effective | Network segmentation, endpoint and server monitoring, and restrictions on administrative privileges |
| New or modified attacks | Activity that does not match known patterns or the assumptions built into detection logic may be missed | Behavior analysis, updated threat intelligence, detection-rule reviews, and threat hunting |
Encrypted Traffic Is Not Entirely Invisible, but Visibility Is Limited
HTTPS/TLS described above is essential for protecting communications. However, a product inspecting traffic in transit cannot read an encrypted payload as-is. It may be able to observe metadata such as destinations and traffic volumes, but the available information depends on the protocol version, configuration, and observation point. Metadata alone cannot establish the contents or purpose of a communication.
One way to inspect the contents of encrypted traffic is to establish appropriate decryption and re-encryption mechanisms, with suitable key management, in an environment controlled by the organization. However, that does not mean every connection should be decrypted without exception. Privacy, legal and contractual requirements, certificate and key management, compatibility with mutual TLS and certificate pinning, and the impact on systems all need to be considered.
With TLS 1.3, some passive decryption techniques used with earlier versions of TLS may no longer work in the same way. In 2025, NIST published a practice guide describing standards-based example architectures for monitoring and analyzing traffic within enterprise-controlled data centers while retaining TLS 1.3. The guide does not recommend decrypting all traffic indiscriminately; it presents options for gaining the visibility needed in managed environments. [2]
Encryption is therefore not a reason to give up on monitoring. The challenge is to decide what content should be inspected and what should be covered by metadata, endpoint information, and other sources, while taking privacy and business requirements into account.
Conclusion
This article explains the basic roles and limitations of IDS/IPS, and examines incidents.
In the next article, I will delve into the following aspects:
- Recent detection technologies and the role of AI/ML
- Proactive involvement from executives and managers, and the operational frameworks that need to be established
References
- NIST SP 800-94, “Guide to Intrusion Detection and Prevention Systems (IDPS)” (February 2007). Foundational material on network-based, wireless, network behavior analysis, and host-based IDPS, as well as design, deployment, configuration, monitoring, and maintenance. Because it is an older publication, it is used here for basic technical classifications rather than as a comprehensive description of current products. NIST CSRC
- NIST SP 1800-37, “Addressing Visibility Challenges with TLS 1.3 within the Enterprise” (September 17, 2025). A practice guide to maintaining visibility into communications in managed enterprise environments while using TLS 1.3. NIST CSRC
- U.S. House Committee on Oversight and Government Reform, “The Equifax Data Breach: Majority Staff Report” (December 2018). Documents the Apache Struts vulnerability, introduction of the Snort rule, scans of externally facing IP addresses, SSLV certificate expiration, and the resulting monitoring gap. The 19-month period used in this article is based on the certificate records obtained by the committee. A footnote in the report notes that the Government Accountability Office (GAO) reported a different period of 10 months. Report PDF
- U.S. Senate Committee on Commerce, Science, and Transportation, “Protecting Personal Consumer Information from Cyber Attacks and Data Breaches” (March 26, 2014 hearing record). Includes a committee staff report on Target’s intrusion path, network segmentation, and FireEye alerts. The staff report drew on contemporaneous reporting and expert analysis, and noted that the full details of the incident had not been established. U.S. Government Publishing Office
- CISA, “AA20-352A: Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations” (December 17, 2020). Describes the SolarWinds Orion supply chain compromise, the malicious DLL signed with a legitimate code-signing certificate, and communications designed to resemble legitimate Orion traffic. CISA Advisory
- MITRE ATT&CK, “SUNBURST (S0559).” Summarizes SUNBURST, including its use of HTTP/DNS communications and techniques for imitating normal SolarWinds API traffic. MITRE ATT&CK
This article does not dismiss the value of IDS/IPS or monitoring products that use AI. Detection coverage and response capabilities vary by product, deployment, configuration, and monitored environment. Always assess the actual architecture and operational conditions before deployment.