Internal Scan Scoping and Procedures Question

[dazz057]

I am looking for some information that will help me scope the quarterly internal VA Scan requirements.

Currently our payment processing application/hardware is hosted by a 3rd Party. The Application, Web, DNS, Mail, and DB servers that process CC info are logically segmented from the rest of the network. The Web servers hosts a portal for a Customer Care group at a remote location to access and input CC payments on the customer's behalf. CHD is not stored on any systems at this site or the Customer Care Group site.

I would like to know if systems located at the Customer Care Group's site would be in-scope for the quarterly internal scans. And if so, if this network is not physically/logically segmented from the rest of the network, would the entire network be in-scope.

[jbhall56]

Originally Posted by dazz057

Currently our payment processing application/hardware is hosted by a 3rd Party. The Application, Web, DNS, Mail, and DB servers that process CC info are logically segmented from the rest of the network. The Web servers hosts a portal for a Customer Care group at a remote location to access and input CC payments on the customer's behalf. CHD is not stored on any systems at this site or the Customer Care Group site.

I would like to know if systems located at the Customer Care Group's site would be in-scope for the quarterly internal scans. And if so, if this network is not physically/logically segmented from the rest of the network, would the entire network be in-scope.

The key is whether or not you have truly appropriately segmented the networks. While on the face of your description, it appears a such, a QSA or other independent authority would have to verify that the logical segmentation does not allow for any spurious access to the PCI network from other networks. If truly segmented, the that would mean that the Web servers would definitely be in scope for scanning.

The tough determination is your Customer Care Group. The reason this is tough is we need to know how they connect to the Web site and what ruels and monitoring are in place for these people. A piece of information that you did not provide.

The key to network segmentation as it relates to PCI compliance is your ability to control and monitor access to PCI in-scope resources. Even on internal networks, if you have placed firewalls between your PCI network and the rest of your networks and you can show you enforce rules for access and you enforce monitoring of the PCI network and its interfaces with other networks, then you should be able to limit your scanning only to the PCI network.

VLANs and ACLs are only part of a network segmentation program. You also need a firewall or similar device to control and monitor what is going on as packets cross between your PCI network and other networks. Without that visibility, you really are blind to attacks, even on your internal networks.

If you take a look at recent breaches, they all involve inside attacks. The bad guys have adjusted strategy since most organizations have hardened their Internet connectivity and they are now focused on the inside. So, you also need to focus on hardening the inside of your network. That is why the PCI DSS was adjusted to make internal vulnerability and penetration testing mandatory.

[dazz057]

Originally Posted by jbhall56

The tough determination is your Customer Care Group. The reason this is tough is we need to know how they connect to the Web site and what ruels and monitoring are in place for these people. A piece of information that you did not provide.

Thanks for your reply jbhall56.

Addressing the Customer Care Group (CCG) question. The CCG connect to a webportal via SSL v3 connections. They receive customer CC data over the phone (calls are sometimes recorded) and input directly into the portal which process and transmits the data to our acquire. The web, application and DB servers are hosted by a 3rd party and do not store any of the CHD (data is held in cache until acknowledgment of receipt by the acquire and then cache is deleted; transactions logs are sanitized of all PAN) I do not know if the portal interface that the CCG sees masks the CC data as it is input into the various fields before transmission to the application. So my question still stands; are the CCG systems in-scope for the Quarterly internal VA scans?

[jbhall56]

Thanks for the clarification on the Customer Care Group (CCG).

Now the question is, does the browser cache of the Customer Care Group's PCs get flushed after every transaction when they enter CHD through the Web application? If only one account is in the browser cache at any given time, then I would rule the CCG PCs out of scope.

If the browser cache stores all CHD entered until the system is shutdown, then all of those CCG systems are potential targets and I would rule them in scope for scanning. I would also recommend that you modify these systems so that they only store one account at a time in any cache.

FYI As a best practice, I would recommend the implementation of critical file monitoring on your CCG systems just to minimize the potential that keyboard loggers or other rogue software cannot be readily installed on these systems since they could be a good source of CHD. After the latest breach at Heartland that used HD slack space and was only detected by the left over log files, a file monitoring approach might have caught the original installation of the software.

[mckafka99]

Would another recommenation for the CCG machines in this example be to segment them into their own logical network from machines not used to goto the portal?

[jbhall56]

That is an option.

But I would only recommend implementing that approach if the CCG systems are storing CHD in their browser cache.

[mckafka99]

Originally Posted by jbhall56

Thanks for the clarification on the Customer Care Group (CCG).

Now the question is, does the browser cache of the Customer Care Group's PCs get flushed after every transaction when they enter CHD through the Web application? If only one account is in the browser cache at any given time, then I would rule the CCG PCs out of scope.

I am intersted in knowing why they would be out of scope since the threat from keyloggers or screen captures still exist. Referencing your reply to my question re: keyloggers in another post, wouldn't one want to still take precautions mentioned there with any machines used to enter CHD into a web form, regardless of what is held in the browser cache? Or is it the case, in this example, that they are out of scope for the quarterly scan.

Thanks for the replies.

[jbhall56]

Originally Posted by mckafka99

I am intersted in knowing why they would be out of scope since the threat from keyloggers or screen captures still exist. Referencing your reply to my question re: keyloggers in another post, wouldn't one want to still take precautions mentioned there with any machines used to enter CHD into a web form, regardless of what is held in the browser cache? Or is it the case, in this example, that they are out of scope for the quarterly scan.

They are out of scope because these systems come into contact with CHD one at a time, not in bulk. By one at a time, I mean that the operator does not have a stack of documents that they are doing bulk data entry. They are taking calls, at random, and encountering CHD one at a time. Even with a stack of documents, the focus would not be on the systems involved but the security with which the documents are accounted for.

In order to classify whether or not these systems should be included, I needed to determine whether or not the browser buffer gets flushed after every transaction. If the buffers do NOT get flushed, then these systems potentially contain bulk CHD and therefore need to be protected just like your servers that contain CHD.

The threat of installing a keylogger on any of these systems is a very real threat and as such they should have anti-virus and critical file monitoring implemented. They should also be on your list of critical systems to be patched as quickly as possible. However, if they do not contain bulk CHD, they do not need to be scanned or penetration tested unless you feel it's necessary for you to sleep better.

And just to clarify. Internal vulnerability scanning and penetration testing needs to be done at least annually or whenever significant changes occur to your in-scope network and/or applications.

[mckafka99]

Originally Posted by jbhall56

The threat of installing a keylogger on any of these systems is a very real threat and as such they should have anti-virus and critical file monitoring implemented. They should also be on your list of critical systems to be patched as quickly as possible. However, if they do not contain bulk CHD, they do not need to be scanned or penetration tested unless you feel it's necessary for you to sleep better.

And just to clarify. Internal vulnerability scanning and penetration testing needs to be done at least annually or whenever significant changes occur to your in-scope network and/or applications.

(I dont mean to hijack this thread but I am facing a very similar situation described for the CC machines)

So for these "data entry" machines, no scanning/pen testing is ever required if the browser cache is flushed after every 'transmission'? On a related note, if these same machines are used for other applications such as email, they login to a windows domain, they use a CRM and some other non cc-related accounting programs, do those remain out of scope?

Thanks again.