Click to learn more about author Rob Chapman.
When I find myself discussing PCI compliance, it always seems like the conversation goes in one direction. Whether I’m speaking with business leaders, IT executives, or the team responsible for deploying technology, everyone primarily just wants to know that a certain solution will check all the boxes to get them compliant or help them stay compliant.
Although it’s understandable, that type of mentality reflects a complicated issue in our industry. Too often, we focus on the question of, “Is it working or not?” when we really should be asking, “Are we doing the right thing?”
I’d like to share a couple of real-world scenarios that illustrate this point and reveal a fundamental need to adjust how we think about PCI compliance.
First, Let’s Cover the Basics
When it comes to PCI compliance, one fundamental concept everyone should understand is PCI scope — the data and systems that are subject to PCI compliance rules. If you want to be safe, you should assume that everything in your IT environment is within the scope of PCI compliance until proven otherwise.
Unfortunately, too many organizations assume the exact opposite. They treat everything as out of scope unless they know for certain that something is in scope. That’s a key mistake that can quickly get them into trouble.
To put it another way, think of the concepts of “trusted” and “untrusted” zones. You should consider PCI scope like a trusted zone. If you know something like your payment cardholder data environment (CDE) or POS system is in PCI scope, it should be part of a trusted zone. And, if something is part of an untrusted zone, it probably won’t be in PCI scope. Of course, that will depend on how well you’ve designed and scoped your environment.
This rule of thumb also applies to any system with a connection to/from something that’s in PCI scope. We commonly refer to these “connected-to” systems as being in PCI scope by the nature of that relationship.
Scenario 1: Implementing a New C-Store POS System
A few years ago, I was part of a project where we were upgrading our POS systems across a large group of convenience stores. We purchased a commercial off-the-shelf solution that held data we were sending off to software hosted in the cloud. Our vendor had a small protocol converter box to perform that step.
However, as we began our rollout, we constantly had to reboot the appliance. To help troubleshoot it, the vendor notified us that they would contact their third-party service to pull the logs. Hearing “third party” immediately sent up some red flags.
It turns out the vendor was using a third party to fully manage the appliance, and we had no contract with that company. But if that third party could connect directly to our POS, we potentially had a huge PCI exposure. Even though the vendor didn’t think its appliance was in PCI scope, it clearly had an impact for our use case.
A lot of PCI heartburn stems from these “connected-to” systems. In this case, we were able to add some firewalls that allowed our POS system to control access from the third-party management service to get it out of PCI scope. But we had to jump through all kinds of hoops to get there.
This scenario illustrates why we can’t fall into the trap of thinking, “It’s out of PCI scope, so don’t worry about it.” In this case, our vendor was a bit short-sighted in that they didn’t understand the full impact of PCI scope. When we put their appliance into a real-world deployment, it definitely was in PCI scope.
Scenario 2: Addressing the Security Risks of Fuel Tank Monitoring Devices
Another common industry-wide mistake that we’re seeing is allowing full access to edge systems such as IoT devices without considering all the potential PCI consequences.
Right now, you can go onto the Internet and, with a minimal amount of effort, access live fuel tank gauge monitoring devices. It’s downright scary when you realize how much data from unsecured edge devices is readily available on the Internet. There are literally thousands of edge systems and IoT devices that are completely unsecured.
The potential damage from a security breach ranges from annoying to catastrophic — and it could create a back door to access your PCI-scoped systems. Hackers could block user access to a device, such as in a ransomware attack. They could also break the integration with your POS systems or create environmental/regulatory issues. Even small configuration changes can become nightmares to track down and fix.
I’ve singled out fuel tank gauges as an example because I know firsthand this has been a common issue in the industry. Unfortunately, it’s only going to get worse as more and more IoT devices go into production. In some ways, it’s almost like waiting for disaster to strike in terms of exposing potential PCI compliance issues.
3 Key Takeaways
Despite these common examples of potential PCI issues, I’m optimistic that we can address a lot of our security challenges simply by adjusting our mentality in the following ways:
1. Start with the assumption that everything is in PCI scope until proven otherwise.
2. To increase security, always design for trusted-to-untrusted data flow. You should primarily care about what’s coming into your systems.
3. Instead of asking, “Does it work?” you should always ask, “Is it the right thing to do?”
By following these three guiding principles, you’ll go a long way in addressing your critical PCI compliance mandates.