Deploying IDS/IPS on the Network: Inline, TAP, and SPAN Choices

An intrusion prevention system (IPS) sits inline — directly in the forwarding path — so it can drop malicious packets in real time before they reach their target. An intrusion detection system (IDS) sits out-of-band, receiving a copy of traffic from a switched port analyzer (SPAN) session or a network test access point (TAP); it can alert on what it sees but cannot block anything as it happens. That placement decision — inline for prevention, passive for detection — is the single distinction the N10-009 exam tests most often on this topic.

Detection vs prevention is really a placement question

Both device types inspect traffic for signs of attack. The difference is not the analysis engine — it is where the box sits relative to the packets.

A passive IDS hangs off to the side of the network. Something else (a SPAN port or a TAP) hands it a duplicate of the traffic, and the original packets continue to their destination untouched. By the time the IDS raises an alert, the suspect traffic has already been delivered. That makes an IDS a visibility and forensics tool: it tells the security team what happened so they can respond, but the response is human or downstream, not automatic at wire speed.

An inline IPS is a bump in the wire. Every frame on that path physically enters one interface of the IPS, gets inspected, and either exits the other interface or gets discarded. Because the real traffic — not a copy — flows through the device, the IPS can drop a malicious packet, reset a TCP session, or block a source address the instant a rule matches. Prevention is only possible inline; a device fed by a mirror copy has nothing to drop, because the genuine packets never pass through it.

	Inline IPS	Passive IDS (TAP/SPAN-fed)
Position	In the forwarding path	Out-of-band, receives a copy
Can block in real time	Yes	No — alert only
Adds latency	Yes, inspection delay on every packet	None to production traffic
Failure impact	Can interrupt traffic if it fails or misfires	Cannot affect production traffic
False-positive cost	Legitimate traffic gets dropped	A noisy alert, nothing more
Typical use	Internet edge, in front of critical servers	Sensitive segments, forensics, industrial networks

Feeding a passive sensor: SPAN vs TAP

A passive sensor is only as good as the copy of traffic it receives, and there are two ways to produce that copy.

SPAN (port mirroring) is a switch feature. You configure the switch to duplicate frames from one or more source ports or VLANs (virtual local area networks) to a destination port where the sensor plugs in. It costs nothing extra and can be reconfigured in software, which makes it the default answer when a question simply asks how to connect an IDS to a switch without putting it in the forwarding path. Its weaknesses come from being a software feature: mirroring is a low-priority task for the switch. Under heavy load the switch can silently drop mirrored frames, an oversubscribed destination port cannot carry a full-duplex link’s combined traffic, and the switch typically discards malformed or errored frames before they ever reach the mirror session.

A network TAP is dedicated hardware inserted into the physical link itself. It splits the signal — optically on fiber, electrically on copper — and passes an exact duplicate of every bit to the monitoring port while the original traffic flows through unimpeded. Because the copy is made at the physical layer, a TAP forwards everything, including corrupt and malformed frames, and it keeps working regardless of how busy the connected switch is. When a scenario demands a perfect, lossless copy of the wire — every bit, bad frames included, immune to switch CPU load — the answer is a TAP, not SPAN. Passive TAPs on fiber need no power at all, so even a TAP failure generally does not interrupt the monitored link.

The trade-off is simple: SPAN is free, flexible, and lossy under stress; a TAP is a purchase and a maintenance-window insertion, but the copy it produces is complete and trustworthy.

Choosing a mode: what can you afford to break?

The deployment decision comes down to a risk comparison.

Inline costs availability. An inline IPS adds inspection latency to every packet, and it is a new single point of failure on the path. If the appliance loses power or its inspection engine hangs, traffic behavior depends on its failure mode: fail-closed hardware stops all traffic (safe for security, terrible for uptime), while fail-open bypass relays pass traffic uninspected (uptime preserved, protection gone). Worse, a false positive on an inline device is not just noise — it is an outage for whatever legitimate traffic matched the bad rule.

Passive costs response time. A TAP- or SPAN-fed IDS can never interrupt production traffic, by design — but it also can never stop an attack in flight. Detection without prevention means your containment depends on how fast someone acts on the alert.

This is why environments with zero tolerance for unplanned downtime — industrial control networks running supervisory control and data acquisition (SCADA) traffic are the classic example — deploy a passive IDS fed by a TAP rather than an inline IPS. A production line halting because an IPS false-positived on legitimate control traffic is a worse outcome than a delayed response to an alert. Conversely, an internet-facing edge protecting patchable servers usually justifies inline prevention: the attacks are constant, and the blast radius of a mistaken block is tolerable. Segmentation design questions overlap here — see network segmentation for PCI DSS for how sensors fit into isolated segments.

In virtualized data centers the sensor itself is often deployed as a virtual network function rather than a dedicated appliance, but the inline-versus-passive decision is unchanged. Some products blur the line: an IPS platform can run in a monitor-only (IDS) mode during an initial tuning period, then be switched to blocking once its rule set is trusted. Tuning that rule set is its own discipline, covered in IDS/IPS detection methods and tuning.

How the N10-009 exam tests this

• A scenario says the team wants malicious packets dropped automatically in real time — the answer is an IPS, and it must be deployed inline in the traffic path. “Real-time blocking” is the phrase that eliminates every passive option.
• A device “monitors a copy of traffic and generates alerts but cannot block” — that is the definition of an IDS. If the stem mentions SPAN or a TAP as the feed, it is confirming passive placement.
• A question asks how to give a sensor a perfect physical copy including malformed frames, unaffected by switch load — choose a network TAP over SPAN. If the question just asks which switch feature copies traffic to a sensor port, the answer is port mirroring/SPAN.
• A high-availability environment (factory floor, SCADA, hospital) needs visibility with no possibility of the monitoring tool disrupting traffic — passive IDS via TAP, never inline IPS.
• Compare-and-contrast items ask which statements about inline vs passive are accurate: inline enables blocking but adds latency and a failure point; passive adds no risk to traffic but cannot prevent anything.

Placement questions reward pattern recognition — drill them with practice questions until “real-time blocking” means inline without a second thought.

Quick reference

• IPS = inline, inspects live traffic, blocks in real time; IDS = passive, inspects a copy, alerts only.
• Prevention requires inline placement — a mirror-fed device has no packets to drop.
• SPAN/port mirroring: switch software copies traffic to a sensor port; free and flexible, but drops mirrored frames under load and excludes errored frames.
• Network TAP: hardware in the link; delivers every bit, including malformed frames, independent of switch CPU; passive fiber TAPs need no power.
• Inline risks: added latency, single point of failure, false positives become outages; know fail-open vs fail-closed behavior.
• Zero-downtime segments (SCADA/industrial): passive IDS via TAP is the safe answer.
• Many IPS platforms can start in monitor-only mode and move to blocking after tuning.