Regulatory Silliness

Susan just pointed me to a "Self-assessment questionnaire" for the Payment Card Industry Data Security Standard (PCI/DSS). While, on the whole, the intent of that standard is good, there are some areas of it that, as usual, stray into the realm of regulatory silliness.

For example, on page 6, under the requirement to "Do not use vendor-supplied defaults for system passwords and other security parameters" we find 2.1.1.a "Are SSID broadcasts disabled?" The PCI/DSS Security Standard version 1.1 actually requires disabling broadcast of the SSID in requirement 2.1. As Wikipedia says "SSID is broadcast in the open in response to a client SSID query..." When a client asks for the access point, the SSID is always broadcast. Thus, to find the SSID of any network, all you have to do is listen when a client associates to the network. The Wi-Fi Alliance actually points this out in its Enterprise Solutions for Wireless LAN Security document. That document also recommends broadcasting the SSID as a security best practice to ensure that users have the information they need to select the right network.

The really bad part about the advice to hide the SSID, however, is hinted at in the WPA Deployment Guidelines for Public Access Wi-Fi Networks, from the Wi-Fi Alliance: "A radio signal with a familiar SSID does not ensure that the user will be connected to equipment operated by a service provider that the subscriber trusts." The same document also points out that the client will connect to the closest AP for purposes of data transport. To see how that would work, assume that a network has a hidden SSID, and the client has been pre-provisioned to connect to that SSID. In this case the client may actually end up connecting to a fake network if the fake network is perceived to be closer. The client will connect to the one with the stronger signal, and will not be able to tell that one of them is rogue. If the remaining security parameters differ between the real network and the rogue one the client will not automatically connect; the user will have to accept the connection. However, the user has no simple way to tell rogue from fake either. If the networks broadcast their SSIDs the conflict would be much more easily detectable. Some clients may even automatically downgrade the security and connect to the fake, but visible, network, without user interaction. This would not work if the real network were broadcasting its security parameters. The client would detect that there were two networks with the same SSID and different parameters.

Curiously, the PCI/DSS Security Standard version 1.1 does not require use of WPA2 or even WPA for security on wireless networks. It only recommends that they be used "when WPA-capable." In other words, it permits use of the completely discredited "Wired Equivalent Privacy" (WEP) protocol, which provides no security at all, and requires use of security theater measures that actually reduce the security of your wireless network. One is left to wonder when the next TJX disaster will happen.

Published 10 March 2008 10:30 AM by jesper

Comments

# Alun Jones said on 10 March, 2008 03:14 PM

Hey, at least they require the WEP keys to rotated quarterly - given how long it takes a WEP key, that means that anyone who's trying to hack your credit card data out of a wireless stream has to spend a couple of minutes getting the new key every three months. How much more secure do you want? :)

Don't forget, also, that when a laptop with wireless access to a non-broadcast SSID is out and about, it's spending some of its time shouting "My user wants me to connect to a site called 'SecretSSID'" to any wireless listener in the neighbourhood.

# LonerVamp said on 11 March, 2008 03:05 PM

Where do they say you can use WEP alone?

# jesper said on 11 March, 2008 03:29 PM

LonerVamp: Section 2.1.1 in www.pcisecuritystandards.org/.../pci_dss_v1-1.pdf:

2.1.1 For wireless environments, change wireless vendor defaults, including but not limited

to, wired equivalent privacy (WEP) keys, default service set identifier (SSID), passwords,

and SNMP community strings. Disable SSID broadcasts. Enable WiFi protected access

(WPA and WPA2) technology for encryption and authentication when WPA-capable.

# LonerVamp said on 11 March, 2008 03:35 PM

Ahh, I can see how 2.1.1. can read that way. I think 4.1.1 is more clear in this subject. It says not to use WEP alone at all, but if you have to, use it in conjunction with another encryption layer.

I think 2.1.1. was worded that way just to give examples of the places that may have default settings/keys/passwords in case you do have them in use.

# jesper said on 11 March, 2008 03:51 PM

I think you've managed to find one of the wonderful inconsistencies in the regulation. 4.1.1 requires some things that are technically infeasible, such as using WEP with WPA. It certainly could be argued though that WEP by itself is not permitted.

The interesting thing with the standard, however, is that it specifically applies only to the act of transmitting cardholder data. If you do not actually transmit cardholder data over a wireless network, 4.1.1 does not apply. You can have a WLAN with WEP connecting to a physical infrastructure, as long as no cardholder data is ever transmitted via the WLAN.

# Antknee said on 12 March, 2008 09:09 AM

It is silly. However I find it equally silly that MS recommends changing then Administrator name when it is a well know SID. Especially when admins usually change it to a name relating to administrator.... joe admin, adm, something like that.

# jesper said on 12 March, 2008 10:49 AM

Funny. As luck would have it, I am just putting the final touches on an article where I discuss renaming the Administrator account. Look for it in an upcoming issue of TechNet Magazine.