PCI DSS Wireless Analysis and Recommendations, Part 3

Welcome! Please comment and leave me a note telling me what you like and what you'd like to see more of. Sign up to my RSS Feed!

 

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:

– all, of course, time allowing.

 

Permalink

 

PCI DSS Wireless Analysis and Recommendations, Part 2

 

As I said in Part I,   The PCI DSS Wireless Guidance document is filling out a very important need.  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 II

Semantics

A small matter, but (7) the definition of part B.,, whereby a hub switch or other network device …transmits cardholder data is not accurate.  Why don’t we define it, for these purpose, as a non-segmenting network device that can submit and receive data  Would that work better?  Leaving it as is breaks your demaraction example and your "directly" connected assumption.

A bigger problem appears with figure 3:

 

If you define the firewall as the Demarc point, as done above, and then try including a wireless access point "F" inside the perimeter, as drawn here, there is a danger of causing confusion about what is proper and what is right.  By marking the network device "B" as an Unrouted Switch (which I believe is done in order to parallel the picture above), a dangerous possibility of complete non-segmentation exists here.   Simply put: I believe it possible for an architect or non-security technologist to design to this diagram.  Why don’t we (8) display the right-and-proper way to do it instead?

 

Proper Architecture

Section 2.1.3 does provide a more appropriate segmentation of the network.  Placing any wireless access point on a different network is a proper way to do so, considering the business fact of "There is a different risk profile to wireless networks".   As I said before:

 

If there is no business reason to do it, don’t do it.

 

 More detail on the analysis of this paper will be next week, on Monday.

Thank you for reading!

 

 

 

 

 

Beginning next week I intend to make:

– all, of course, time allowing.

 

Permalink