Can systems be out of scope even on same network segement?

[AllanPoll]

Network segment with administratively locked down workstations (running various Windows flavours) and servers attached. Most workstations configured to use DHCP, select few configured with static IP addresses. The static IP addresses are allowed access out and natted, via the local firewall, to the rest of the corporate network out onto the Internet to access a web application payment gateway service that is PCI compliant.

Access controls to the PC controlled at the local level by the usual Windows domain controls such that only members of a specific domain group can log on to those IPs with statically allocated IP addresses and are presented with a single icon that opens a web browser session configured to only access the domain of the remote web application. The remote web application has further access controls such that the end user has to log in and can only log in from the NAT'd IP address. The end user can now enter new cardholder detail information but cannot view previously entered details.

Bottom line, the PC's are acting as data entry terminals and the only risk associated with being on the same network as other workstations/services is that someone may install a keylogger or trojan onto those PCs to harvest card holder data ... however the controls in place are such that that risk is no less if those PC's were to be put on a seperately firewalles/acl'd network.

As a QSA do you assert the letter of the law (ie. controls based audit) and decree that the whole of network is in scope period or a more risk based approach and deem controls around those select PCs to be sufficient enough to take the rest of the network out of scope?

[mdahn]

@AllanPoll you provided a lot of detailed information and are asking one of the basic questions about scoping for compliance. "What is 'good enough' segmentation?"

Well, the answer to that is not simple. Instead the answer is anything that will prevent one set of systems or people from negatively affecting the security of the cardholder data you protect.

Always, always, always take a risk based approach (12.1) and work towards the intent behind the requirement instead of the literal meaning. Contact me directly if you need more specifics.

[AllanPoll]

Thanks Michael,

The risk based approach is exactly the route I've taken and shall complete the current RoC accordingly (ie. although these specific workstations reside on a network populated with other systems the controls around, and functionality of, these workstations results in no requirement for network segregation and does not bring any of the other systems on that network into scope).

I guess I was looking for some form of support, get that wooly feeling that your not out there on your own with this approach.

[DMertz]

Michael's point is simply looking at the network architecture is not enough. What you are doing may be sufficient. However, additional issues which need to be considered include (but not limited to): 1) The applications which reside on these devices and how secure are they?, 2) the management protocols of these devices, 3) educational efforts of employees, 4) internal audit/monitoring of activities on the network, 5) company policy which is established and communicated, 5) patch management, 6) shared drives, 7) what relevant logging of activity is occurring, etc.

Hope this helps.

David Mertz
Partner
Compliance Security Partners
913 706-4217

[mdahn]

You should examine all attack vectors and determine if any of them can be used to negatively affect the security of the Cardholder Data Environment (CDE) or connected networks/systems.

Those items David mentions may be examples of attack vectors. Remember that 'segmentation' is not always network based. You can segment operationaly and otherwise. Look at the risk and protect appropriately.