Answering Some Dream Team Questions

After our PCI Dream Team event on May 17, I thought I would take some questions that do not require long and involved answers and publish them in this post.  FYI – I have edited and spell checked these, so they likely do not look like you entered them but they should convey your questions as you asked them.  Hopefully I answered one of your questions.

Q: Does anything special need to be done with the use of Virtual Terminals?  We use the virtual terminals to manually enter credit cards from time to time.  The computers used are normal user computers with the basic security done, but I have been wondering if they need to have extra limitations or security put in?

A: There are a lot of solutions that imply they take the workstation/terminal out of scope or magically reduce scope when using virtual desktop (VDI) solutions.  None of it is true.  If a device is used to enter PAN (regardless of HOW), it is a Category 1 device because it is used to enter PAN.  The bottom line is that any device used to enter PAN is in-scope for full PCI compliance.  There is no “magic” to change that fact.

Q: Do all POI devices have a keypad? I’m thinking of PC’s with integrated MCR’s – will those all change to separate POI’s with a keypad?

A: All point of interaction (POI), aka card terminals, that are customer facing have a keypad because they need to be able to accept PIN entry.  Merchants that are going to P2PE/E2EE solutions end up with a separate POI that is connected to the POS PC/terminal via USB so that the POS solution can communicate the total price of the sale as well as to know if the transaction is approved or declined.  The POI securely communicates with the transaction processor over Ethernet or using the USB connection and the Ethernet connection of the POS PC.  In both cases, the POS PC never has access to the sensitive authentication data (SAD)/cardholder data (CHD) as it is encrypted at the POI.  However is using an E2EE solution, the QSA will need to validate that the E2EE solution to ensure that they do in fact encrypt at the POI and therefore the POS PC/terminal is out of scope.  In addition, the merchant will have to contact their acquiring bank to get formal approval that the E2EE solution gives scope reduction for the merchant.  This will likely require the QSA to provide their evidence and assessment procedures to the acquiring bank for that approval.

Q: Are administrator workstations always in scope for PCI DSS regardless if an administrator is connecting to CDE servers via jump box?

A: Yes, because they are “connected to” systems when they access the jump box.  They may not be entering cardholder data (CHD), but they likely can access it or influence its processing/transmission because they are administrators.  That said, I would treat them in the Open PCI Scoping Toolkit vernacular as a Category 2x system.  That means they can probably avoid the bulk of PCI requirements but, at a minimum, need to be properly security hardened, kept updated, have anti-virus/anti-malware and are monitored “periodically”.  And as a reminder, administrators will need to use multi-factor authentication (MFA) after January 31, 2018 when accessing the cardholder data environment (CDE).

Q: Are you having/forcing your clients to follow the December scoping guidance, and are you bringing administrator workstations into scope?

A: I guess I am curious as to when anyone would have thought that administrator workstations ever were out of scope?  Nothing has changed in that regard as they were always in scope for PCI compliance.

Q: Are “crash kits” in restaurants for use when the system is down in scope for compliance?

A: The kits themselves are not in scope, but when they get used, the forms that get generated which contain the embossed image or handwritten PAN and other sensitive authentication data (SAD)/cardholder data (CHD) place those forms in scope for PCI compliance.  They therefore need to be securely stored, securely transmitted and subsequently securely destroyed in accordance to the relevant requirements in section 9.

Q: Does pushing non-cardholder data out of CDE system excludes connected system out of PCI scope? For example pushing non-cardholder data such as CPU usage for monitoring or number of transactions per day used for reporting etc.

A: According to a discussion at the 2016 Community Meeting and a subsequent Assessor call, the Council has publicly stated that if it can be unequivocally proven that the flow is only outbound from the cardholder data environment (CDE) to a device and that the data does not contain cardholder data (CHD), that device can be ruled out of scope.  However you have to get your QSA to buy into that argument and I do not know too many QSAs that will agree with that decision.  In my experience, there is still too much of a risk that cardholder data (CHD) could leak through that flow and saying it is out of scope is not accurate nor is it good practice as it leads to an exfiltration point that is not monitored.  The question you have to ask yourself is, how will it look in that newspaper headline when your organization is breached that you ruled it out of scope because it was outbound only?

Q: PCI DSS requires a firewall in place, are host level firewalls meeting that requirement?

A: Yes, as long as they perform stateful packet inspection (SPI), they are properly and securely configured and they are appropriately monitored like any other in scope firewall.

Q: Regarding vulnerability assessments for internal scans, do we have to address medium vulnerabilities or only critical and high vulnerabilities?

A: The PCI DSS and the Council have been very clear on this which is why it is disconcerting when this question constantly gets asked.  The guidance for requirement 6.2 is very clear as it states, “Consider prioritizing patch installations such that security patches for critical or at-risk systems are installed within 30 days, and other lower-risk patches are installed within 2-3 months.”  The bottom line is that you need to apply ALL patches/updates to all in scope systems as soon as possible.  So get on with patching and updates, no excuses.

Q: More than once I’ve been told that the decision to implement PCI compliant controls is a financial decision. What are the expected fines and penalties for failing?

A: No organization gets to ignore any PCI requirement because of financial or any other reasons.  However in those cases where a requirement cannot be directly met, an organization must then come up with compensating controls that go above and beyond that requirement in order to be in compliance.  In my experience, it is almost always cheaper to meet the PCI requirement than to go the compensating control worksheet approach.  You will have to talk to the card brands as they are the ones that come up with the fines and penalties.

Q: Do you ever foresee the card brands implementing any sort safe harbor clauses in regard to PCI?  If a merchant is doing their best to be secure and (more importantly, as far as PCI is concerned) compliant and they are breached, as it stands right now, PCI will not help you.  Instead, PCI seems to be wielded as a weapon to extract fines from the merchant.

A: You are joking right?  LOL!  Actually, with merchants going to P2PE/E2EE and tokenization solutions, I could envision changes in the PCI compliance process at the merchant level because the risk is only with the POI.  Time will tell.

Q: Have you heard anything further regarding the FTC’s review of PCI?

A: Not a word and I would not expect to hear anything until the FTC decides to tell us anything.  I do know that issues regarding the FTC’s information requests from the QSACs were supposedly worked out and that the requested information was delivered to the FTC.  But that is the extent of my knowledge on the matter.

Advertisement