PDA

View Full Version : SNMP community string changes


El_Luke
03-16-2009, 11:34 AM
I'm actually fairly surprised but I've looked and I cannot find a specific PCI requirement to justify changing SNMP community strings periodically. I was about to tell someone they had to do that, and went to look for a requirement as proof but I don't see one.

So as I see it, companies are not required by PCI to change SNMP community strings periodically.

Anyone disagree?

partpricer
03-16-2009, 01:30 PM
I would agree with you. There are only two places where SNMP community strings are mentioned in PCI-DSS 1.2. They are included below for reference.

2.1 Always change vendor-supplied defaults before installing a system on the network—for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts.

2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. Ensure wireless device security settings are enabled for strong encryption technology for authentication and transmission.

jonassono
03-16-2009, 02:25 PM
Community strings are a considered to be a very weak form of authentication in the SNMP protocol as they are passed in the clear text in SNMP messages and can be easily sniffed.

Accordingly, there is little benefit, from a security perspective, changing them.

In order to mitigate this weakness, PCI-DSS requires that all non-console administrative access (which includes SNMP management) be encrypted (see Requirement 2.3).

El_Luke
03-16-2009, 03:07 PM
SNMPv2 can be configured for encryption but it only uses DES, which is too weak. Are you saying that you tell your clients that they must use SNMPv3, that the v2 is prohibited?

jonassono
03-17-2009, 06:17 AM
Not at all. I tell my clients that if they use VPN, SSL or another secure authentication/encryption technique for all non-console messages, as per PCI-DSS Requirement 2.3 they will be considered to be compliant on this issue.

I also advise them that, if they so choose for other security or technical reasons, to further mitigate the potential risks in this category, go for it.

This could include other remediation such as implementing SNMPv3 or an appliance/utility such as the Tavve Zone Ranger to translate v2 requests to v3 requests. But understand, it is not a PCI-DSS requirement.

Magnafix
03-17-2009, 04:09 PM
I'm actually fairly surprised but I've looked and I cannot find a specific PCI requirement to justify changing SNMP community strings periodically.

Your mistake was in assuming PCI DSS is about security. It is about compliance. Work on security separately, and be pleased when PCI DSS contributes something to that effort.

El_Luke
03-18-2009, 06:39 AM
Actually, now I have come back around again and can see where, in some cases, rotation of SNMP strings would be required.

Read strings - still don't care really.
However, if you are using write strings to manage the device via SNMP, that is essentially admin access to the device, equivalent to the ssh/enable password in Cisco terms. In that case, I could argue for the requirement of changing the write string periodically and when an admin leaves, e.g.

If the device had an ACL only allowing the network mgmt system to connect via SNMP, then I let it go, but without that, it could reasonably require changes.