Welcome to the first blog post in our new series, “QSA Q&A,” where experts from Qualified Security Assessor (QSA) companies share their thoughts on some of today’s most important data security and compliance topics. QSAs are independent security organizations that have been qualified by the Payment Card Industry Security Standards Council (PCI SSC) to validate an organization’s adherence to the PCI Data Security Standard (DSS).
To kick off our series, today we are speaking with Joe Meyer, Director of Risk Management & Governance at the NCC Group. Joe has been a QSA since 2011 and has more than 20 years of experience working in the information technology arena. At NCC Group, Joe develops and leads multiple service disciplines and offerings, and provides expertise to help clients align their security goals with regulatory and industry standards.
1. How do today’s call center businesses regard PCI DSS compliance? Is it something they are taking more seriously?
Today’s call centers are light years ahead of where they were 10 years ago, primarily due to an increase in call center-friendly solutions for call recording, acceptable use and data destructions. At the turn of the century, call centers had very few industry-specific tools or technical approaches they could use to help with security and compliance. It wasn’t until around 2010 that we started to see interactive voice recognition (IVR) and call recording solutions begin to address the biggest compliance gap within call centers, call logs, and recordings.
For example, a .wav file used to store a call recording for “training and quality control purposes” is a PCI record if it contains credit card numbers and/or the CVV in the recording. But because this was viewed as a non-traditional data set, many call centers were unable to achieve full PCI DSS compliance without leveraging compensating controls. With the solutions available now that mute, mask, tokenize, or in some cases, remove the credit card information from the call altogether, call centers are able to meet the full intent of PCI DSS compliance where they struggled just a decade before.
2. At Semafone’s roundtable event in March, you stated “You are not secure because you’re compliant, you are compliant because you’re secure.” Can you expand on this notion?
When frameworks such as the PCI DSS were first introduced, they were initially meant to fill a void. That void was a result of many companies lacking simple information security baselines or guidelines to implement one. Because PCI DSS was intended to be industry agnostic and more prescriptive than other “frameworks,” many organizations adopted it as the standard for their organizational security. Though this is a great place to start, PCI DSS is specific to credit card data. Not all InfoSec practices are covered in the standard, and therefore a gap was created around elements within an environment that are not related to payment card data. We noticed in the 2000s that companies were proclaiming how secure they were because they were PCI DSS compliant, but that is not the case. Simply meeting the basic standards of a compliance framework does not, nor has it ever, implied security.
With that said, if an organization takes on all necessary security principles, best practices, risk assessments and segmentation, and does it correctly, it should expect to be more secure than the basic requirements of a compliance framework. Therefore, just because you are compliant with a framework, does not mean your organization is “secure.” However, if you go above and beyond what the framework suggests, you are considered more secure than the basic requirements, and by proxy, mostly secure. Ergo, the statement of compliance is a result of good organizational security, not the other way around.
3. How can call centers most effectively de-scope their environments for PCI DSS compliance?
Effectively answering this question would require assessing all, or at least most, call centers. However, in my recent experience, call centers haven’t needed to “segment” their networks as much, due to the introduction of technical solutions that offload the burden of complying with PCI DSS to a third-party service provider. Most service providers have received the recommendations by those of us in the industry that the removal or transference of risk to a third-party who handles payment card data is the best way to “de-scope” or reduce the amount of applicable controls.
4. Are organizations putting off or delaying PCI DSS compliance projects? If so, is it due to cost, lack of understanding that there’s a real risk, or lack of C-level support?
We see a growing issue of complacency, more so than a delay. Organizations that achieved PCI DSS compliance two or three years ago continue to barely get by each year and have not made the necessary upgrades or improvements to their environments or technologies. As for C-level support, PCI DSS version 3.2 has set the framework to begin holding executives accountable for the compliance, security and protection of their organization’s information.
5. What are the real implications of delaying compliance projects?
One word: immeasurable. Long gone are the days when compliance frameworks were deemed simply an act of “checking the box.” Most frameworks have matured enough to provide a decent level of organizational and data set security. By avoiding compliance projects, an organization is making itself bigger, brighter and an easier target for attack. The ability to protect an organization against threats all but goes away when compliance initiatives are pushed to the back burner.
6. We are seeing the regulatory landscape evolving, with new state laws (like the NY State DFS Cyber Security Regulation) and even global laws (EU GDPR) coming into play to protect sensitive data. Where does PCI DSS compliance fit in with this changing landscape?
PCI DSS doesn’t necessarily fit into the landscape from an “apples to apples” standpoint. What this means is that state and commonwealth regulations add a governmental “specificity” to what you should and should not do in order to maintain the ability to conduct business. The New York DFS, for example, requires you to protect any and all data; however, in the event of a single data record breach, the penalty could include suspending your organization from conducting financial business in the state of New York.
Further, the difference between the PCI DSS framework and state regulations is simply a matter of definition. A framework is meant to be a guide on how to conduct things, whereas a regulation is a set of standards on how to continue business operations. The PCI DSS has been and continues to be a framework on how to build your InfoSec program. Government regulations require businesses to follow certain rules in order to continue doing business. There’s a fundamental difference.
7. What does the future of PCI DSS compliance look like?
The majority of retailers and merchants will have little, if any, responsibility to PCI. With the introduction of chip and pin, EMV and transference to payment gateways, the future of PCI DSS compliance will focus almost solely on service providers, managed hosting providers, and payment gateways.
To hear more from Joe, check out the recording of our recent webinar, “PCI DSS Compliance & Your Call Center: The Dos and Don’ts of Scope Reduction.”