Attention Marketers: Access 30 Million IT Decision Makers with ECT News Network's INSTA-LEADS Click to Learn More!
Welcome Guest | Sign In
TechNewsWorld.com

PCI 3.0, Part 2: Defining Your Cardholder Data Environment

PCI 3.0, Part 2: Defining Your Cardholder Data Environment

Limiting your compliance scope will help you shrink your attack surface and reduce points of entry for attackers, lighten your compliance burden and audit costs. The best way to do it is through network segmentation. It's not mandated -- but without it, your entire network will be considered in scope, which increases your complexity, your risk and your headaches.

By Kurt Hagerman E-Commerce Times ECT News Network
03/17/14 5:00 AM PT

PCI 3.0, Part 1: Breathe, Relax, Get Compliant

New compliance guidelines went into effect earlier this year. While e-commerce organizations have until their 2015 audit to transition, the new controls are demanding enough operational and technical changes that smart businesses already have started preparing.

If you're wondering where to get started, one of the first steps you should take is to thoroughly define and document your cardholder data environment, or CDE, and consider ways to limit its scope.

By defining your CDE, you'll be better able to apply controls to restrict where and how the cardholder data is accessible -- and in doing so, strengthen your security while lightening your compliance burden.

Defining Your CDE

Check the 3.0 guidelines, and you'll see they focus quite a bit on defining and validating your CDE. There are a few reasons for this. One is that defining your in-scope environment will illuminate any potential vulnerabilities in your system and help ensure that all vital elements stay protected.

The second is that many organizations fail to understand just how encompassing their compliance scope is. PCI DSS requirements apply to all components in your CDE. That doesn't just cover technology -- it extends to people and processes as well. You'll need to include everyone who handles cardholder data and consider processes such as settlements, reconciliations and chargebacks, as well as manual order processes.

In a nutshell, you'll need to be tireless in your scoping efforts. All locations and flows of cardholder data must be identified. Assume certain people and areas are out of scope and you might be setting yourself up for a costly surprise; just one component left out of scope means the data in that area is vulnerable to attack.

Your first duties include making an exhaustive inventory list, as well as accurate network and data flow diagrams that show how the devices are connected and how payment information flows through your environment. These diagrams must demonstrate all connections between the CDE and other networks, including any wireless networks, your network configurations and the location of all network devices.

If you're wondering exactly what needs to examined and documented, the below list is a good place to start:

  • Security services and segmentation systems: authentication servers, internal firewalls, resolution or Web redirection servers;
  • Virtualization components: virtual machines, switches/routers, appliances, applications, hypervisors;
  • Network components: firewalls, switches, routers, wireless access points, network appliances;
  • Server types like Web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS); and
  • All internal and external applications that either directly handle cardholder data or provide administrative functionality to components within the CDE

Limiting Your Scope

When you look at the above list, you'll understand why limiting your compliance scope is so valuable. Not only can you shrink your attack surface and reduce points of entry for attackers, you can lighten your compliance burden and audit costs.

The best way to do that? Network segmentation. It's not mandated, but without it your entire network will be considered in scope, which increases your complexity, your risk and your headaches.

Start by eliminating unnecessary data up front, then consolidating the right data. With that accomplished, you can use several methods for segmentation, including properly configured internal network firewalls, routers with strong access control lists, or other technologies that restrict access to cardholder data.

Be aware that not everyone will segment the same way; take a look at the configurations and controls you're already using, and let those guide you toward the best segmentation methods for your unique environment.

Next, you'll look at your data flow diagrams, which are required. With just a glance, you should be able to track your environment scope and ensure that your network segmentation has successfully isolated cardholder data.

Be aware that this isn't a one-time process; you'll need to update these diagrams with any changes to the environment so that they accurately reflect all data flows in your current CDE at any given moment.

Compliance and Service Providers

If you're looking to partner with a third-party provider, there's no better time than the present. An experienced service provider can be your best friend when it comes to dealing with compliance challenges. Make sure you choose a validated provider who undergoes its own PCI DSS assessments and can show you evidence of its compliance; those providers will have the on-staff experts and specialized tools you need.

Part of that relationship is clearly understanding and documenting all responsibilities. 3.0 asks organizations and providers to spell out with detailed transparency the division of responsibilities in contracts like MOU, SLA or Terms of Service documents.

Remember, all system components in the cardholder data environment must be validated -- and that includes any hosting provider, managed security service provider or contractors.

PCI 3.0, Part 3: Validating Your Cardholder Data Environment


As chief information security officer for FireHost, Kurt Hagerman is responsible for all aspects of security and compliance for both corporate- and customer-facing products. He is responsible for leading FireHost in attaining ISO, PCI, HIPAA and other certifications.


Facebook Twitter LinkedIn Google+ RSS