- Where PCI DSS Falls Short (and How to Make it Better)
- PCI DSS Wireless Analysis and Recommendations
- PCI DSS Wireless Analysis and Recommendations, Part 2
- PCI DSS Wireless Analysis and Recommendations, Part 3
- PCI DSS Wireless Analysis and Recommendations, Part 4
- PCI DSS Wireless Analysis and Recommendations, Part 5
The PCI Council has recently released a new publication. The PCI DSS Wireless Guidance document is filling out a very important need. One of the most requested items requested of me when I advise on PCI compliance is the topic of wireless. Even technology-savvy directors and managers have a difficult time wrangling with this issue.
As exemplified, of all things, by last month’s in Iran (
see my coverage at http://arielsilverstone.com/library/iran-cyberwar/ ), modern technology far outpaces our ability to monitor, manage, or govern. Simply put, and from quite a different perspective, the ease of introducing wireless technologies is a threat to enterprise security.
While returning again to the
Three Basic Tenets of Security: Confidentiality, Integrity and Availability, one can easily see how unauthorized wireless access can effect Confidentiality. It is somewhat more difficult to explain how it effects Integrity and Availability, and that I promise today this coming Friday, in a blog entry on that topic.
Today I will start analyzing this Wireless Guidance document. My comments will be of two varieties: overview and technical. As I encourage your comments to mine, I will number them and ask that you refer to that number in your comments.
How to Improve on the PCI DSS Wireless Guidelines Document
Wireless Environment Definition
The authors of this document attempted to write an easy-to-understand guide that would help practitioners, and as the authors suggested, auditors, to understand what needs to be done in order to be compliant with the PCI DSS requirements with regards to wireless access. (1) In my view, the comment provided on page 3 which specially excludes Bluetooth or GPRS technology, is a huge mistake.
Most practitioners, and especially the audience to whom this booklet was intended, do not differentiate between wireless technologies. This lack of differentiation does not result from lack of understanding. On the contrary – the practitioners do understand that data leakage can happen from the use of any wireless technology, regardless of its acronym. The common element here is the self-same definition of "Layer 1" – the physical lack of it for most of the data path. This is a missed opportunity.
Looking at the sheer number of access points and users, Bluetooth is far more widely deployed than 802.11 wireless elements. The Council is running the risk that well-meaning auditors and users will simply overlook this vulnerability due to this under-serving document.
Depth of the Document
(2) Partly of the failure stated above, the document is neither technical enough nor substantial enough to be a true Auditor guideline. As any practitioner with more than one year of service knows, a lot of the auditing is done by fresh-faced kids barely out of school. I highly recommend a separate guidebook for auditors with much more content than this one.
Requirement Category Breakdown
I do love (3) the breakdown performed on page 4, calling requirements into two separate groups. To my knowledge, this is the first time someone has defined "Generally Applicable Wireless Requirements" as distinct from a group’s (insert X, or PCI here) special needs. It will be interesting to note, over the near-term future, if this variation truly holds or if it proves unwieldy (or incorrect) to manage.
Another area of major concern to me, is the (5) widely incorrect definition of the Cardholder Data Environment (CDE). The core of any PCI compliance is a proper definition of the CDE. The Council is correct by starting with the definition as a basis. The problem is at the very definition. Per the document, the CDE is defined
as the computer environment wherein cardholder data is transferred, processed, or stored and any networks or devices directly connected to that environment. (emphasis mine)
This swine-flu approach (whereby touching makes suspect) is a common security "panic" definition. As you can easily see, if you follow the logic plainly, then every network touching any network becomes part of the CDE. In turn, this "touching" network, now a part of the CDE itself, has other "touching" networks, and so on… at the very least – clarify what you mean by directly!
The Internet as a CDE
To make matters worse (6) the very graphic provided on this page as an example has a problem.
Element "D" herein is the firewall, while element "E" is …. the Internet. Oops…. we just made the Internet a CDE.
As I trust you will agree, the definition needs more work…
Tomorrow I will continue this analysis.
Mondays into PCI -days; Tuesdays into Cloud-days; Wednesdays into weekly-special-subject-days; Thursdays into guest-blogger-days; and Fridays into surprise-days.