The PCI Guru has an article about an issue with PCI DSS requirement 2.3.b
https://pciguru.wordpress.com/2017/06/09/we-need-a-change-to-2-3-b/
Reminder of what 2.3.b is about:
2.3.b Review services and parameter files on systems to determine that Telnet and other insecure remote-login commands are not available for non-console access.
And the guidance for 2.3 is:
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. To be considered “strong cryptography,” industryrecognized protocols with appropriate key strengths and key management should be in place as applicable for the type of technology in use. (Refer to “strong cryptography” in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms, and industry standards and best practices such as NIST SP 800-52 and SP 800-57, OWASP, etc.)
Translation: No telnet. Or basically no remote login methods that transmit credentials in clear text.
The PCI Guru’s article makes a case for the allowance of telnet (and other insecure remote-login commands) in “a properly isolated and secure environment”.
Meh, I say go ahead and treat the telnet users with disdain. Maybe it is time to take a look at that creaking infrastructure that only supports telnet. At least the compensating control mechanism may bring the issue to management’s attention. Maybe it is time to ditch those old VT-100 tape drives that only support admin and key exchange through telnet. Maybe it is time to stop transmitting admin passwords around in cleartext. Yes, isolation will reduce the risk of intercepting these credentials, BUT it does not eliminate the risk. Any interception of the traffic (at the firewall, switch, or router. Or maybe vlan transversal, ARP spoofing, DNS hijack, whatever that gets an adversary access to these packets) could give an attacker the next link in their attack chain.
What modern equipment is this an issue on? Maybe the problem is really with the vendors still pushing out product that requires these protocols. Or the companies who continue to buy them. Regardless, mitigate the risk with a compensating control to address the risk of transmitting the password in plain text and carry on appears to be the best advice overall and the message from the council.
The bigger issue around completion of the compensating control is what control do you use to mitigate the risk? Segmentation? Maybe, but its going to have to be above and beyond what would have been required anyway.
What would make me change my tune: I dunno. Send me your ideas if you disagree.
Ad below this line:
