We’ve spent a lot of time talking about PCI 3.0 this year. You might even be thinking, “I get it, I need to adapt my compliance practices.” Well, we’re not done yet. In fact, there’s a specific area we haven’t talked about much, and it’s an area that often gets overlooked by e-Commerce businesses and financial institutions. I’m talking about scoping and data capture.
When merchants think about defining and validating the cardholder data environment (CDE), they often focus on protecting data in storage. Usually they understand that encryption is the gold standard in safeguarding the confidentiality of cardholder data (CHD), and they follow best practices for encrypting data at rest. Yet time and again I see organizations fail to consider data capture in their scoping endeavors – even though it’s a high-risk area.
Let’s say, for instance, that your site uses order forms that ask for card data. The transmission of the data is encrypted using SSL. But because the form is on the server, that form data is posted back to your web server and becomes stored in memory. If you make the same mistake as other organizations, you’ll overlook that aspect and forget to include the entire system as part of your scope. But if you do it right, you’ll include that system and ensure all the right controls are being used to protect your servers.
There’s one dynamic in particular I see quite often. Sometimes in an effort to reduce their scope, organizations will use third party services to handle data capture for them, often using a “host capture” service offered by their payment gateway or processor. By outsourcing the capture of cardholder data, these organizations often think they’re off the compliance hook, so to speak.
The truth? If your business is at all involved in data capture, it’s still your job to safeguard all relevant systems. Here’s why. While third party services can undeniably play a useful role, these services can include code on your servers. The process still interacts with your website and that means you must be careful in implementing, monitoring and making changes to that code – otherwise you run the risk of it becoming compromised.
If you are using a host capture method, you still need to consider your web server as in scope, even if in a more limited way. The PCI SSC created a new SAQ (SAQ A-EP) specifically for this case. It is very similar to SAQ C and contains 139 questions so clearly the SSC considers these systems still in scope. The issue is properly integrating and protecting the host capture code typically provided by the vendor and having controls in place to ensure that your web server does not become compromised. If it does, then the code is subject to being changed; allowing an attacker to create a man-in-the-middle situation and siphoning off all of your CHD as it is being transmitted to the vendor provided page.
Remember, every network or process involved in the storage, process, transmission or capture of data falls under the compliance umbrella. So go ahead and use third party services if you like – just remember to include your own systems in your scoping and compliance efforts. Take a look at your own security controls in this area and check that they’re safeguarding your servers appropriately and keeping that code from becoming compromised or co-opted. Remember, scoping is one of the most critical aspects of getting compliant – and data capture is an excellent example of why every organization must be careful and diligent in building a thorough security program.