Intrusion Detection System (IDS)

Applies to. 11.5.1 requires intrusion-detection and/or intrusion-prevention techniques on all traffic at the perimeter of the Cardholder Data Environment and at critical points inside it, with personnel alerted to suspected compromises and all engines, baselines and signatures kept up to date; the assessor checks system configurations and network diagrams for that coverage. The IDS's own logs are among those 10.4.1 requires to be reviewed at least once daily, 10.7.2 names IDS/IPS as a critical security control whose failure must be detected and alerted, and 12.10.5 requires the incident response plan to cover monitoring and responding to its alerts.

Example. A retailer mirrors traffic from the switch in front of its card-processing segment, and from the link between the store network and head office, to a detection sensor. When a workstation starts probing the payment servers on ports it has never used, the sensor alerts the on-call analyst, who follows the incident response procedure to isolate the machine.

Limits. An IDS detects and alerts; it does not block. 11.5.1 accepts detection, prevention or both, so a detection-only deployment is acceptable provided the alert reaches a person who acts on it. Coverage is measured in traffic, not sensors: a sensor at the internet edge that sees nothing of the traffic between internal segments does not monitor the critical points inside the CDE. An IDS is not a substitute for the network security controls that decide which traffic is allowed at all, nor for daily log review, and an alert queue nobody watches fails 11.5.1.b, which checks that the techniques alert personnel of suspected compromises. Detection of rogue wireless access points is a separate obligation under 11.2.1, whatever the IDS can see.