4.3Comparing inspection methods and sensor placement

Monitoring design entangles three axes: "how deeply to inspect," "insert into the path to block or just take a copy," and "store everything or keep only a summary." Each carries a trade-off between visibility and cost/latency/risk, and unless you choose by goal (block or merely observe, need payload or is a statistic enough, want long-term retention), you either waste performance or lose the evidence you needed. This section compares inspection depth, sensor placement, and data granularity as practical judgments.

4.3.1Depth of inspection

• Packet filtering (stateless) permits/denies each packet individually by 5-tuple (IP, ports, protocol) against an ACL. Holding no connection state, it is fast and cheap but cannot judge "is this return packet part of an established session," so it tends toward looseness like opening ports broadly to allow return traffic.
• Stateful inspection maintains a connection state table and automatically allows return traffic for sessions established from the inside (while new outside-to-inside stays denied by default). Safer and easier to operate than stateless, it uses more resources for state management. It centers on L3/L4 state.
• Deep packet inspection (DPI) inspects the payload up to L7—application identification, IPS signatures, malware detection—reaching into the content. It offers the highest visibility but consumes the most CPU/memory and adds latency. NGFWs and IPS perform it; note that once traffic is encrypted, the content is invisible (unless it is decrypted).

4.3.2Sensor placement (inline vs. tap)

• Inline places the sensor in series on the traffic path. Since traffic must pass through it, it can block or rewrite (the premise of an IPS/firewall). In return it adds latency and risks halting traffic (or passing it through) on device failure, requiring a fail-open/fail-closed design choice.
• Tap/SPAN receives a copy of traffic out-of-band. It cannot block—only detect/record (the premise of an IDS/packet capture), but by not inserting into the production path it adds no latency or failure risk. A hardware tap physically duplicates every frame and rarely drops, whereas a switch SPAN (mirror) port can drop frames when oversubscribed.

4.3.3Data granularity (full capture vs. NetFlow)

• Full packet capture (via a tap) stores both headers and payload in full. It is the most detailed evidence—allowing later file extraction and command reconstruction—but consumes storage heavily, making long-term retention impractical. The norm is to capture only the segment targeted for deep investigation.
• Transactional data (NetFlow) keeps only a summary per flow: 5-tuple plus byte/packet counts and times. Without payload it is lightweight, good for long-term retention and wide-area baselining, and strong at detecting beacons or abnormal volumes at scale. It cannot confirm content, so in practice it is combined with full capture for deep dives.

You are redesigning data-center monitoring. The requirements are: "(1) block known attacks on the spot; (2) separately, be able to investigate all traffic in detail after the fact without adding latency or failure risk to production; and (3) watch for abnormal traffic volume (beacons/exfiltration) at scale over a span of months." For (1), "block on the spot" cannot be done by a tap that only sees a copy—blocking requires an inline placement, an IPS (judging signature matches via DPI) in series on the path, where you design the fail-closed/open behavior and latency tolerance. For (2), "investigate in detail later without affecting production," there is no need to insert into the path, so take a tap (or SPAN) copy of the traffic and feed it into full packet capture. Trying to make the inline IPS also do full capture would worsen latency under the combined load of DPI and full storage, violating "do not affect production" in (2)—the norm is to separate blocking (inline) from detailed recording (tap). To avoid drops, choosing a hardware tap over SPAN is also sound. For (3), "watch abnormal volume at scale over months," hoarding full capture for months is impractical, so build a long-term statistical baseline with lightweight NetFlow (transactional), and when a deviation is detected, dive into full capture only for that segment—a two-tier approach. Thus, blocking via inline + DPI, detail via tap + full capture, and long-term monitoring via NetFlow—assigning a method to each goal—is the design judgment that satisfies both performance and evidence.

4.3.4Section summary

• Inspection depth: stateless (per-packet, fast) -> stateful (tracks return) -> DPI (up to L7, heaviest); deeper sees more but costs more
• Placement: inline can block but affects the path/failure risk; tap/SPAN is a copy that detects only, with no impact (SPAN may drop when oversubscribed)
• Granularity: full capture has payload but is storage-heavy; NetFlow is statistics-only, lightweight, long-retained. Separate the roles and combine them