The mis-integrated element of PCI DSS
Updated: May 24
It is no secret to say that I am a keen supporter of the PCI DSS integrated controls framework. However, during my research for my recently released book, I found a couple of elements that made the integration component to be far from seamless.
The majority of the control framework structure make perfect sense but then there are some controls just appear to have been thrown into the framework, without following what to me would be common sense. If I could make any influences for the v4.0 changes, it would be to make sure that the framework is enhanced to ensure consistency.
Unique to PCI DSS is how they employ the 6 goals and 12 requirements that provide an integrated approach.
Goal 1 - Build and Maintain a Secure Network and Systems
Having implemented a secure network architecture, this must be subject to strict change control measures (Req. 6.4) and be subject to security monitoring and security assurance testing (Goal 5).
Where this structure falls short of being consistency is in regard to the following control areas:
Requirement 6.6 - Web Application Testing
Much like the network & system penetration testing (Req 11.3) has not been included in requirement 1 or 2, wouldn't this make more sense to have this included in Requirement 11 (Regularly test security systems and processes), rather than as a bolt-on to Requirement 6? I appreciate that there is a need to differentiate Web Application testing (Req 6.6) from external (Req 11.3.1), internal (Req 11.3.2) application/infrastructure security assurance testing but couldn't this be better achieved through the inclusion of an additional security testing control - much like was achieved with the inclusion of a segmentation testing (Req 11.3.4) control.
Requirement 11.4 - Perimeter Intrusion Detection Systems (PIDS) & Intrusion Detection Systems (IDS).
Wouldn't this be more appropriate to have been included as part of the security monitoring? Think of this like an alarm system for a property, you would expect the alerts to be monitored and responded to as part of the integration into the Incident Response (Req 12.10) process. Is Req 11 (Security Testing) really the most appropriate place for your PIDS & IDS (alarm system)?
Requirement 11.5 - Change Detection.
Surely monitoring for unauthorised changes is more appropriate in Req 10?
I have found it extremely helpful to visualise the PCI DSS controls framework against real-life examples and to appreciate how the evolution of the framework, over the past 2 decades, provides a unique and robust integrated defences to enhance the protective security efforts, for the safeguarding of cardholder data.
It is important to understand that the PCI DSS framework is a catalogue of security controls, developed to help businesses to mitigate known risks that are associated with payment card operations and their supporting systems.
A real-life example. You would expect the physical security measures at bank to employ an integrated approach to ensure that someone can't walk straight in off the high street and gain unauthorised entry to the vault. The same should apply to your supporting network architecture, to ensure that if the perimeter is breached, there are other separate layers of security controls which get progressively more difficult to compromise.
However, for the controls framework to be effective, it is essential that organisations employ a 'Top-Down' team-based approach to ensure that they maintain an integrated approach to help ensure that they are able to easily identify the ABNOROMAL from NORMAL.