The PCI DSS Wireless Guidance document is filling out a very important need.  As I said in Part I, Part II, and Part III.   Today I will continue analyzing this Wireless Guidance document.  I will number them and ask that you refer to that number in your comments on my suggestions.  Remember – the goal is to help improve the document.

How to Improve on the PCI DSS Wireless Guidelines Document – Part IV

More processes

Continuing in the review of the "Complying with PCI DSS" flow chart, I found some other areas I would change.

(14)  I remove the arrow form "Change defaults" and draw one instead from "Generate audit report" – to "Enable 802.11i".   This may seem as a small fix, but in fact it means "Enable 802.11i AFTER you generate an audit report".   I also (15) would consider changing the verbiage of "Generate audit report"….  How can you generate an audit report to prove that the defaults have been changed?  Do you simply compare it to an earlier report that said that those were the vulnerabilities?  Do you just submit it as "this weakness not found" type report?  Either way, lets change the way it is phrased.

Similarly to (14) above, I would recommend item (16) to route the arrow from "Enable 802.11" to "Physically Secure" to originate at "Generate a wireless audit".  The difference being that taking the steps of "A centralized management system" and "Generate a wireless Audit report that proves…"  are very important to enablement of Audit.  The way the chart is drawn now, these can be seen as optional processes, and should not.

Finally here (17) I would like to note that in some situations it is not feasible, while certainly being desirable, to physically secure wireless devices.  They can be our of reach (as in on a very high ceiling) or maintained by a third-party organization.   I would suggest that the term be defined so an organization would not fail on their audit just for that reason alone.

More to come next Monday…

Tomorrow we will have Chris’ final article in the "How to talk to Senior Management about Security".  On Friday, as I promised, a discussion of Confidentiality, Integrity and Availability, and the next article in the PCI DSS Wireless series will be Monday.

Permalink

The PCI DSS Wireless Guidance document is filling out a very important need.  As I said in Part I, and Part II.   Today I will continue analyzing this Wireless Guidance document.  I will number them and ask that you refer to that number in your comments on my suggestions.  Remember – the goal is to help improve the document.

How to Improve on the PCI DSS Wireless Guidelines Document – Part III

Point of Clarification

>Before I delve into the flow-chart detailed in section 2.2, that I have a lot of input on, let me suggest that the comment at part 2.1.3 (9) is a tad confusing:

Allow me to suggest that if there was a way to guarantee that no traffic would ever enter or leave from the AP to the CDE, then those are, in fact, not on the same network.  Since there is no way to positivly assure of it, and keeping in mind the inteded audience of this document, why don’t we (10) call this scenario out as such?

Finally on this point, why don’t we agree the firewall’s configuration is always a part of the PCI DSS?  At the very least, this device is the demarc point and we need it.

Requirements and Processes

This flow chart, titled "figure 5" and appearing on page 8, could be improved:

In this ‘blog entry I will start the discussion about it.

Firstly, let’s look at the first two rows of the flow chart:

There seems to be a logical problem here.   Let me suggest replacing the flow with mine, below:

 The two changes I notate are (11 in Red) that documented access control policies should exist BEFORE we can check if there are any unauthorized wireless devices and (12 in blue) that the rule about Documentation and about Proving should be broken into two separate rules.  The proving rule might belong to an audit, and required by PCI DSS. 

I also have another suggestion (13), that the box marked "have monthly reports…" should be considered for clarification due to the discussion on the previous section of firewalls within or without the CDE definition – there by leading to the possibility that all scans be rendered useless due to a functioning firewall…

Beginning next week I intend to make:

• Mondays into PCI -days;
• Tuesdays into Cloud-days;
• Wednesdays into weekly-special-subject-days;
• Thursdays into guest-blogger-days;
• and Fridays into surprise-days.

- all, of course, time allowing.

Permalink