I just wanted to give everyone a “heads up” about some guidance we recently received from the PCI SSC regarding jump boxes or out-of-band (OOB) system management solutions and the use of insecure protocols such as SNMPv1/2 and Telnet.
But did everyone know that this solution also requires a compensating control worksheet (CCW)?
For years (at least since the Phoenix Community Meeting years ago), the Council has been recommending the use of firewalls and jump boxes as a way to secure instances where organizations need to use insecure protocols. These enclaves are firewalled, VLAN’d and configured so that only the jump box can be used to remotely connect to the devices over Telnet and allowing other insecure protocols to be kept away from other networks. However, I do not recall any of those discussions ever explicitly calling out the need for a CCW. I suppose the Council just figured we would all be bright enough to write one up.
What led me to this revelation you ask?
When I was going through my QSA Requalification this spring, they had a scenario with a jump box solution. One of the questions related to the scenario involved how you would create a CCW for the insecure protocols used in the administrative VLAN that the jump box provided access. While I answered the questions correctly, it triggered a new question regarding why a CCW was needed in the first place.
Then when the question was posed back to the Council, we got a reply indicating that a CCW would be required because of requirement 2.3.b which states:
“Review services and parameter files on systems to determine that Telnet and other insecure remote-login commands are not available for non-console access.”
The problem with the requirement is that it treats all Telnet with equal distain regardless of risk. Yes, Telnet is always a clear text protocol, but when it is buried two or three layers away from any general network or the internet and requires administrator credentials and MFA, it is hardly as “at risk” as it would be when PCI started over 15 years ago and networks were as flat as a piece of paper.
As a result, I would like to recommend that the Council work to change 2.3.b to take into account the use of network segmentation, firewalls, VLANs, ACLs, MFA and jump boxes to allow the use of Telnet and insecure protocols when in a properly isolated and secure environment. It seems silly to me that someone goes through all of the right steps to secure their environment only to be told that they still need a compensating controls to meet a requirement that does not reflect the real risk.
The other reason I feel this needs to be addressed is that a lot of banks and processors seem to see CCWs as a huge red flag. Something to be avoided at all costs because it implies to them non-compliance. And non-compliance is a “bad” thing. I cannot tell you the collective hand wringing some banks go through for really simple CCWs all because they do not want to have any PCI assessments with CCWs.
Ultimately I think this all comes down to the fact that those banks and processors have no clue as to the amount of risk any CCW presents. This is because most banks and processors staff their PCI compliance areas with auditors and compliance professionals, not technicians. Given that the PCI DSS is predominately all about security technology and its implementation, these auditors and compliance people are not equipped to make the decisions that typically need to be made regarding CCWs. As a result, they are all high risk in their eyes and treated accordingly.
Hopefully the Council can address this situation and we can avoid needless documentation for a preferred “best practice”.
PCI Guru 
Amen!
Well, the powers that be have their own risks too, such as adding a load of language and subrequirements to the DSS. You’re proposing they add something to the effect that when telnet is buried under a few layers of security, that it be allowed. How exactly do they add that to the DSS? What constitutes adequate protection? How many bullets will it take, and will it be complete? Easier to say currently strong encryption is OK, and anything else, let the QSA do the legwork of a CCW.
As I stated, there are still banks that see any CCW as “bad” and should not be included. But I get your point. It’s just do we want a standard that never changes with the “best practices” being followed? Eventually every requirement will require a CCW under that sort of approach.
I agree with you, there must be a change to 2.3.b. Although it might be required to enforced documentation, while I can see that this system will come out of compliance during the internal scans and internal penetration testing.
If a pen tester or scanner cannot get into the CDE or the admin VLAN, then that should be proof enough. It’s the pen testing and scanning without context that is wrong. If you have to physically move the pen testing and scanning equipment’s network connections because of firewalls and other controls to get them done, that in and of itself should be an indication that controls are in place and working.
And yet … your QSA could insist that you change your FW rules to allow the pentester to access the CDE. I was speechless before blurting out “how do I know he won’t introduce malware or attack the system?”
Most pen testers prefer to have the pen testing system moved into the CDE as firewalls can still create issues even when supposedly every port is unblocked.
BTW You are required to test inside the CDE as well as outside of it to prove segmentation as well as that no exploitable vulnerabilities exist in the CDE systems/devices.