2.2.2 definition of unsafe protocols

[I3inford]

Hi,

I am currently project manager responsible for pre audit preparation for PCI DSS compliance of the environments we set up for our customers using card holder data.

regarding this requirement: 2.2.2 For a sample of system components, critical servers, and wireless access points, inspect enabled system services, daemons, and protocols. Verify that unnecessary or insecure services or protocols are not enabled, or are justified and documented as to appropriate use of the service (for example, FTP is not used, or is encrypted via SSH or other technology).


I am in search of a reliable source for a definition what (un)safe protocols and services are. I mean we all know that HTTPS is considered safe and FTP is not, but what about all the other beautiful protocols we find on different layers?

I hope someone can help me...

cheers,
I3inford

[lyalc]

Review the protocols in use at your organisation e.g. a network traffic audit. Then google these for security issues, and decide what is risky in your situation.

Some examples:.
FTP and telnet don't use encryption, so passwords etc travel across the network unencrypted. FTP has historically been configured to permit anomymous logins.

SSL is by default permit weak/null encryption, so these are risky.
SSH versions prior to 2 have a number of security exposures in the protocol itself (let alone possible implementation flaws), so this is insecure and should be avoided, unless its the only supported option e.g. a legacy switch or firewall.

The original windows NTLM allows trivial rainbow attacks, so this is not an advisable protocol, unless needed for legacy compatibility.

SNMP V 1 and 2 permit command execution from any source with no/publicly known authentication. Unless these old versions of SNMP are essential for monitoring/management, disable them, and filter the machines that can send SNMP to the network devices and servers.

And so on.


lyalc

[I3inford]

Thank you for your quick response.

That is basically the methodology I wanted to use, but I thought maybe someone had put this information together, already.

I'll probably make my life easy on that one, though.
I'll identify the protocols we use for maintenance and make sure they are safe. I'll let our customer order me to enable anything he wants, so he is stuck with arguing with the QSA. I have a valid business reason to keep the protocols enabled if I have to due to contratural circumstances.

Thanks again.
I guess I'll be around here more often now.

[jbhall56]

I have a valid business reason to keep the protocols enabled if I have to due to contractual circumstances.

If you are contractually obligated to provide a certain protocol, then you need to provide the protocol. The PCI does NOT say that you cannot use these protocols, it just wants them only used when there is absolutely no other choice.

You need to come up with some compensating controls surrounding these protocols so that they have a minimal risk to your processing environment. Things like further segmentation around the devices that might use these protocols, additional firewalls, really limited access, HIDS/HIPS, additional monitoring, etc.

In addition, you need to have your management sign off on the fact that these protocols are used and that they acknowledge the risk they present.