There’s always been sort of an intriguing (the more suitable word perhaps arguable) line of (in)coherence in some of the PCI DSS requirements. This from my very personal QSA viewpoint. So sometimes I feel like the figures don’t just all add up and I can’t help but mumble over the rationale of (some parts of) the standard (yeah, I know that’s in fact one of the big “don’ts” that I was given at the onsite QSA training back in the day; but I think it’s fair to assume that’s an “acceptable risk” after years of hands-on work).
Incoherence in some of the PCI requirements
Let’s focus on the following requirements in PCI DSS (the very recent and most up-to-date v3.2, though my points stand in general):
especially in relation to what requirement 4 aims at:
Before “unveiling” what makes me so puzzled with the above, let’s very quickly look at the intent of such requirements by directly referring to the guidance provided by the PCI DSS standard itself. Here is, a significant excerpt when it comes to req 2.3:
“If non-console (including remote) administration does not use secure authentication and encrypted communications, sensitive administrative or operational level information (like administrator’s IDs and passwords) can be revealed to an eavesdropper. A malicious individual could use this information to access the network, become administrator, and steal data. Clear-text protocols (such as HTTP, telnet, etc.) do not encrypt traffic or logon details, making it easy for an eavesdropper to intercept this information.”
This is, however, what refers to req. 8.2.1:
“Many network devices and applications transmit unencrypted, readable passwords across the network and/or store passwords without encryption. A malicious individual can easily intercept unencrypted passwords during transmission using a “sniffer,” or directly access unencrypted passwords in files where they are stored, and use this data to gain unauthorized access.”
Now please focus on the first part of the text accompanying the general statement of section 4:
“Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals.”
Basically, the PCI DSS standard defines the need to use strong cryptography and security protocols to protect “sensitive” data during transmission. As one might expect, channel-level security is regarded as one of the standard’s major concerns.
Understandably (section 4), being cardholder data at the core of the standard, PCI DSS wants to protect it whenever and wherever transmitted “over open, public networks” (e.g. the Internet, wireless technologies, bluetooth, cellular technologies, GPRS, satellite communications, etc.), since such kind of networks are not trusted by definition.
Still understandably (req. 2.3 and 8.2.1), PCI DSS also wants to grant protection of other relevant sensitive data (such as admin IDs and passwords) in transit in internal network segments, so that possible eavesdroppers are not able to sniff unencrypted passwords and gain non-console administrative access to system components, web GUIs and stuff, since that would indirectly pose a threat to cardholder data.
Differences in PCI DSS requirements
The thing that I’ve never really grasped, in this whole story, is how PCI DSS requirements for encryption of data in transit can be so different for private networks and public networks – especially when it comes to the nature of the data being transmitted.
Indeed, considering that it’s pretty much matter of fact that clear-text cardholder data flow in internal network segments on most of PCI DSS environments (termination of secure channels normally takes place at the perimeter level; plus, despite being strongly encrypted while at rest in accordance to what required by section 3, PAN and SAD might be handled in unencrypted/decrypted form in the back-end) why, if I were an eavesdropper with faculties of sniffing traffic in an internal PCI environment, would I hunt for valid credential sets only, without going “straight to the point”?
Cause as things are put today, it almost seems like making authentication credentials unreadable during transmission is somewhat addressing a bigger risk than having readable PAN and SAD out and about. Don’t you feel that PAN and SAD should then need an extra-layer of security when flowing internally as well, for coherence?
My conclusion, simply put, either internal network is inherently trusted or any data classification criteria would impose me to protect PAN and SAD before anything else, being the most critical piece of information handled in my PCI environment. In which case, I would expect some sort of a dedicated “Requirement 4” for internal network segments too.
It would be really great to get your opinion on that!
