3 Show Stoppers for a QSA On-Site Assessment

In today’s blog, we are going to discuss three potential show stoppers for a QSA On-site Assessment. These all come from recent conversations with potential clients, and all three would have resulted in a failing Report on Compliance (RoC). So as a result, we thought a blog discussing what those are and what to do about them once we are at that point would be appropriate.

1. Storing Sensitive Authentication Data

Unless you are an issuer, meaning you issue credit cards, you cannot store sensitive authentication data after authorization, period. Sensitive authentication data consists of the 3 digit CVV or CVC number on the back of the card, contents of the magnetic stripe on the back of a credit card, or contents of the chip in newer cards. The most common place we see this being stored is in call recordings. If you have a call center or take credit card information over the phone, you likely need to ask for the 3 digit CVV code, and if you are recording those calls for quality assurance, that data is being stored. This is an immediate show-stopper, do not pass go, do not collect $200. Simply put, you cannot meet PCI DSS requirements without this in place.

During a recent phone conversation with a potential client, we found out that there was some sensitive authentication data being stored. We advised the client that they could not pass, and so we told them they should not spend the money on a full QSA on-site assessment if they can avoid it. Instead, we recommended a gap analysis where we could come in and provide consultation on what the on-site audit would look like, what other potential red flags exist, and what they could do to meet compliance as quickly as possible. As a start, they needed to figure out a way to either stop recording those calls or at least that portion of the call where the sensitive authentication data was received. This particular client ended up giving the call center a mute button that would mute the recording for that portion of the call. After the process was in place, there also needed to be some evidence that they went back and scrubbed the previously recorded calls.

2. Segmentation

Segmentation is not a PCI DSS requirement. However, it is strongly recommended by the PCI council as a method that may reduce the scope, cost, and complexity of meeting PCI DSS requirements. Without segmentation, every device in your network is in scope and subject to PCI requirements. This means that even the machines not involved in the payment process (think the marketing team’s computer) needs to meet the PCI requirements. This includes the hardening process, defining all inbound and outbound connections, logging, vulnerability scanning and penetration testing, etc.

One of the best requirements to demonstrate the challenge with meeting PCI DSS without segmentation is requirement 1.3.4. This requirement states that outbound traffic from the cardholder data environment to the Internet must be explicitly authorized. This means each and every outbound connection must be documented and approved with an appropriate business justification. Now thinking back to your sales or marketing team, they need access to social media to generate a following, they need access to the CRM platform, likely relevant news websites, etc. Each and every one of these connections must be approved down to the system and port they are accessing. While possible, this would be extremely challenging.

3. Filling out the Wrong SAQ

Recently, we had a client come to us and they told us that they have been filling out an SAQ for years, but now their acquiring bank is telling them they need a level 1 audit. After we started discussing how they accept payments, understanding a little about their situation, and what SAQ they have been filling out, we determined that they were filling out the wrong SAQ for their environment. This is an immediate red flag for us. This does not necessarily mean they won’t meet all the requirements and pass their audit, but it does mean they have been focusing on a subset of the requirements and failing to consider the other requirements that they are going to be responsible for. Some of those other requirements may have historical time requirements associated with them, such as quarterly vulnerability scans.

Summary

In summary, we discussed three red flags or show stoppers for a QSA on-site assessment. First, we talked about storing sensitive authentication data and how to fix that going forward. Then we discussed the importance of segmentation even though it isn’t required by PCI. Finally, we discussed filling out the wrong SAQ, and the importance of doing a comprehensive review to make sure that the neglected requirements are still being met. If you have any questions or want to talk further, give us a call.