POS and PCI requirements

[secguy]

I have a question on how a auditor would look at POS in the following scenario.

All the stores use wireless for scanning inventory.
POS systems run MS. Only use of these systems is store activities. Such as inventory, cash register, sales activity tracking. etc… The stores POS tie into a POS master server that collects all the information. Night the stores communicate back to corp. They pass all the activity for that day. They communicate via dsl over VPN to corp. All data is encrypted. Firewalls at point of entry at each store. The POS do not email or use browsers. USB are locked down. We do have access from corp via VPN to each store system for patches, etc...The router at each store may use DHCP or static to the ISP. My question is would this be considered a private segment even though we have a public facing IP? There is no access from the internet only the VPN. I am trying to figure out if we need to use a vendor to run external scan to all these IP’s. PCI says all external facing addresses must be scanned, but what if we do not have any open services on those devices. I am curious how they do this with a router DHCP off an ISP anyway.

I am also trying to figure out if we need to protect these same way we would a Desktop.
If these systems are only for one app and do not run any normal browsers, mail, etc. Would we be required to run A/V, firewall, hips, etc.?

[jbhall56]

First you need to answer some questions regarding your use of wireless for inventory management. Is the wireless 802.11a/b/g or an old proprietary protocol? If it is 802.11 something, how is it isolated from the rest of the POS network? It should be segregated by a firewall and appropriate 802.11 security implemented. You have store firewalls, but you did not indicate that these firewalls segment the wireless from the wired.

As long as you can show that all of your store routers are configured to direct all WAN traffic to your corporate network via VPN and that the local ISP address is never used, then there should be no reason to worry about the ISP IP address.

Your POS is MS Windows based yet you apparently have not implemented A/V. This is not acceptable. Because you have Windows systems, you need to have A/V implemented on your store servers, workstations and any other systems that are at risk of infection. These systems are just as at risk as any others on your networks.

I would recommend implementing HIDS/HIPS on your servers at your stores. Based on your description, these systems store cardholder data, so they need file monitoring and log analysis performed on them just like your corporate servers.

In regards to personal firewalls, that is for portable systems which I do not believe your POS is portable in the sense of a notebook. Therefore, personal firewall software does not need to be installed on your POS workstations.

Something you do not bring up but is important to the PCI process. How many versions of POS do you have out in your stores? The amount of sampling that will need to be done will be dictated by your answer. Even with a great POS testing lab, a QSA should want to review at least one implementation of each POS version out in the real world even though you can test each version in your POS testing lab.

[lyalc]

I woud recommend you do run vulnerability scans against the store IPs. Athough they may not have any listening services now, an error of configuration, unauthorised change, poorly reviewed change request, or malicioous software infection would change this situation in an instant.

I know this overlaps with the quarterly firewall rule review - but eyeballing these rules for multiple sites once a quarter usually means something gets missed, which just might be hugely important to site security.

Schedule the firewall rules review mid-way between scans, and the potential exposure time window should drop to 50%, a worthwhile risk reduction for minimal cost.
I know with DHCp you may not get a 100% accurate scan each quarter - but you've still managed the risk better, and the auditor can see that the work has been done, rathr than have to write up a compensating controls sheet that may well conclude that the risk of configuration errors and malware is too high.