PCI DSS 11.5.1: Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or prevent
PCI DSS v4.0.1 control 11.5.1: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 11.5.
Requirement 11: Test Security of Systems and Networks Regularly › Section 11.5
Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or prevent intrusions into the network as follows:
- All traffic is monitored at the perimeter of the CDE.
- All traffic is monitored at critical points in the CDE.
- Personnel are alerted to suspected compromises.
- All intrusion-detection and prevention engines, baselines, and signatures are kept up to date.
Summary
Watch traffic at the edge of the cardholder data environment and at critical points inside it, alert someone, and keep the detection current.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 11.5.1.a | Examine system configurations and network diagrams to verify that intrusion-detection and/or intrusion-prevention techniques are in place to monitor all traffic: • At the perimeter of the CDE. • At critical points in the CDE. |
| 11.5.1.b | Examine system configurations and interview responsible personnel to verify intrusion-detection and/or intrusion-prevention techniques alert personnel of suspected compromises. |
| 11.5.1.c | Examine system configurations and vendor documentation to verify intrusion-detection and/or intrusion-prevention techniques are configured to keep all engines, baselines, and signatures up to date. |
Four elements, and the one most often half-done is the second: all traffic is monitored at critical points in the CDE, not only at its perimeter. Perimeter monitoring catches traffic arriving; internal monitoring is what sees an attacker already inside moving between systems, which is the phase most compromises spend the longest in. The fourth element is also separately tested by 11.5.1.c, which examines configuration and vendor documentation to confirm engines, baselines and signatures are kept up to date, so a sensor deployed and never updated fails on its own. Note the standard says intrusion detection and/or prevention: detecting is sufficient where you alert on it, so this does not force inline blocking.
What to prepare
- Network diagrams showing sensor placement against the CDE perimeter and its internal critical points.
- What "critical points" means for your environment, written down, since the standard leaves it to you.
- Alerting configuration and who receives it.
- Update status for engines, baselines and signatures, with vendor documentation.
How to implement it
1. Define critical points and defend the definition. Segment boundaries inside the CDE, the paths to the data stores, and the administrative access routes are the defensible answer, and writing it is what makes 11.5.1.a assessable.
2. Do not stop at the perimeter. It is the most common shape of a partial implementation and the one an assessor looks for immediately after seeing a perimeter sensor.
3. Route the alerts to the people in 12.10.3. The third element is alerting personnel, and the incident response plan under 12.10.5 has to say what happens next.
4. Monitor the updates. Signature currency drifts silently, so a check that the feed is still arriving is worth more than a policy saying it should.
Where this commonly fails
- Perimeter monitoring only, with nothing watching movement inside the CDE.
- Sensors deployed and signatures stale, which 11.5.1.c tests directly.
- Alerts generated into a console nobody watches, which is detection without the third element.
- "Critical points" never defined, so coverage cannot be shown to be adequate.
Related controls
Others in section 11.5:
| Control | What it requires |
|---|---|
| 11.5.1.1 | Service providers: Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent… |
| 11.5.2 | A change-detection mechanism (for example, file integrity monitoring tools)… |
← 11.4.7 · All controls · 11.5.1.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.