PCI DSS 11.5.1.1 (service providers): Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent
PCI DSS v4.0.1 control 11.5.1.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
Additional requirement for service providers only: Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels.
Summary
Service providers only: detect and deal with the channels malware uses to talk out quietly.
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.1.a | Additional testing procedure for service provider assessments only: Examine documentation and configuration settings to verify that methods to detect and alert on/prevent covert malware communication channels are in place and operating. |
| 11.5.1.1.b | Additional testing procedure for service provider assessments only: Examine the entity’s incident-response plan (Requirement 12.10.1) to verify it requires and defines a response in the event that covert malware communication channels are detected. |
| 11.5.1.1.c | Additional testing procedure for service provider assessments only: Interview responsible personnel and observe processes to verify that personnel maintain knowledge of covert malware communication and control techniques and are knowledgeable about how to respond when malware is suspected. |
Service providers only, and it reaches further than it reads. Covert communication channels are how malware exfiltrates without looking like exfiltration: tunnelling over DNS, data hidden inside otherwise ordinary outbound traffic, beaconing paced to blend into normal patterns. Three procedures test three different things, and two of them are not about the detection at all. 11.5.1.1.b examines the incident response plan under 12.10.1 to verify it requires and defines a response, so this control creates an obligation in Requirement 12. And 11.5.1.1.c interviews personnel and observes processes to verify they maintain knowledge of covert channel techniques, which is an ongoing awareness obligation rather than a configuration one. A tool alone satisfies one procedure of three.
What to prepare
- Configuration showing detection of covert channels, and what techniques it covers.
- The section of the incident response plan that defines the response, which is examined directly.
- Evidence that personnel maintain current knowledge: briefings, threat intelligence, training records.
- Examples of the detection operating, if any have fired.
How to implement it
1. Watch outbound, not just inbound. Covert channels are an egress problem, and monitoring built around keeping attackers out will not see traffic leaving.
2. Start with DNS. It is the most common covert channel because it is almost always permitted outbound, and inspecting it is usually the highest-value single step.
3. Write the response into the plan. 11.5.1.1.b examines 12.10.1 for it, so an incident response plan that does not mention covert channels fails this control rather than that one.
4. Give the knowledge element a mechanism. A recurring threat briefing with a record is what turns "personnel maintain knowledge" from an assertion into something 11.5.1.1.c can observe.
Where this commonly fails
- Detection deployed with nothing in the incident response plan, failing 11.5.1.1.b.
- The knowledge element unevidenced, since it looks like a soft requirement and is separately tested.
- Egress monitoring absent because the architecture was built around perimeter ingress.
- A merchant applying this, when it is a service provider requirement.
Related controls
This control refers to 12.10.1.
Others in section 11.5:
| Control | What it requires |
|---|---|
| 11.5.1 | Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or prevent… |
| 11.5.2 | A change-detection mechanism (for example, file integrity monitoring tools)… |
← 11.5.1 · All controls · 11.5.2 →
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.