As an individual who has been in the IT industry for over 29 years, the last 17 years of which has been in the compliance/assessment/auditing niche, I recognized early on in my career that continual learning is the key to success in IT. I’ve had some great mentors in my life and am thankful that they instilled in me the heart and desire to gain knowledge and apply it. As a result, my focus lately has been PCI. I’ve been a Qualified Security Assessor (QSA) for nearly five years, which is long enough to not only master the PCI DSS framework, but also to pinpoint where companies struggle adhering to the robust payment card industry standards.
The QSA Perspective Series is a six-part blog series wherein I’ll share my perspective on applying the PCI standards, as well as what I focus on when starting an engagement. The series topics I plan to address include the following:
- The Cardholder Data Environment
- Connected-To / Security Impacting Systems
- Network and Dataflow Diagrams
- Service Providers and Nested Third Parties
- Cloud Auditing – Is it really that different?
- Cloud Auditing – AWS, Azure, Clients – Who is responsible for what?
The goal of the series is to share knowledge and provide perspective on how I apply common sense fundamentals to help companies achieve and demonstrate PCI compliance. I won’t say it hasn’t been difficult for my clients that I’ve assessed through the years, and I will say that in many cases it was even harder for me. In my five years as a QSA, I’ve assessed all types of clients in all types of industries, both international and national, large and small, and one thing I’ve learned is that QSAs can truly impact the security of consumer credit card data.
I take pride in that fact, and ownership of the responsibility that I have as a QSA. So let me share my perspective on what I focus on and why. It’s a proven approach, and it’s very simple. The fundamentals of cybersecurity are important. Focusing on the fundamentals is the key to successfully complying with the PCI DSS. I hope you enjoy this series, and I hope it helps provide perspective. Either way, you’ll know how I think as a QSA, and why, and can be prepared for your next PCI assessment.
Cardholder Data Environment
I can’t tell you how many times I’ve observed and heard misunderstandings of what the cardholder data environment is. So, what is it? Why does it seem so nebulous and difficult to pin down? And why do I focus on it as a QSA? I’ll tell you why, for it’s the single most important aspect of any PCI assessment, and 9 times out of 10, it’s not been defined correctly.
So, what do the PCI security standards say about what the cardholder data environment (otherwise referred to as the CDE) is? Some would be surprised to know that it’s actually a defined term in the standards, and rightly so. According to the Payment Card Industry (PCI) Data Security Standards (DSS), the definition of CDE is “The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data.”
So what does cardholder data mean? “At a minimum, cardholder data consists of the full PAN. (Primary Account Number, i.e. 16-digit cardholder number). Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code.” When thinking about credit card data, the full PAN is the key. Without the full PAN, even if you have the cardholder name, expiration date and/or service code, you don’t have cardholder data. On the flip side, if you have full the PAN and it’s accompanied with name, expiration and/or service code, all of those items are considered cardholder data. And if you don’t have cardholder data in the environment, you don’t have a CDE. This is a crucially important factor and impacts the way I go about determining what PCI requirements are relevant for my clients.
This same concept applies to sensitive authentication data (SAD). SAD is defined as “Security-related information (including but not limited to card validation codes/value, full track data (from the magnetic stripe or equivalent on a chip), PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions.”
My point by citing the definitions is that the CDE is a defined term, and it’s defined for a reason. As a QSA, my focus initially in every assessment I do is to understand and pinpoint the CDE. I need to understand the boundaries of the CDE in relation to everything else around it so I can understand what may be in scope. Knowing what the CDE is and what its boundaries are are the first steps in evaluating the accuracy of the client’s PCI scope.
Notice how the definition highlights that the CDE is comprised of people, processes, AND technologies. So, it’s not just about systems. It’s also about the people who interact with credit card data, and it’s about the processes used to operate and secure the credit card data. The key is being able to identify whether they are part of storing, processing, or transmitting cardholder data or sensitive authentication data.
Let’s start with people. Taken in context, some of the “people” that could be involved in the processing of credit card data are the following (and this is not an all-inclusive list, just some examples):
- Customer Service Reps who receive phone calls from customers and are provided credit card numbers over the phone and enter them into a system to process
- Retail personnel who accept a physical credit card from a customer and swipe it into a card reader or payment application to process the payment.
- IT personnel who have access to or configure systems that store, process or transmit cardholder data.
How about processes? Here are some examples:
- Customer Service
- Customer Support
- Configuration Management
- Change Management
- Patch Management
- Vulnerability Management
- Logging & Monitoring
- Application Development
The PCI DSS does a really good job of describing through its control set all the relevant processes that should be evaluated.
And as for technology? That’s the simplest part, and what QSAs usually focus the most attention on. Here are some examples:
- Web servers
- Servers (i.e. Windows, Linux, Unix, etc) or Mainframe or AS/400 systems
- Virtualization systems
- SFTP servers
- PTS devices (PIN Transaction Security, i.e. card readers), or POI devices (Point of Interaction)
Another aspect of CDE scope that is included and considered as part of the CDE are system components that are on the same network segment (for example, in the same subnet or VLAN) as system(s) that store, process, or transmit cardholder data or sensitive authentication data.
Why is all of this important? It’s important because the PCI DSS requirements apply to all system components included in or connected to the cardholder data environment. In order to understand what is considered “connected,” you have to be able to understand what comprises the CDE. The CDE boundaries are critical to ascertain, and I’ll explain in future blogs how the approach I take is sequential and dependent on validating that the scope of the assessment is accurately defined and documented.
But to be clear, defining CDE scope is not up to me. As a matter of fact, PCI DSS clearly highlights the shared nature of confirming that the PCI DSS scope has been accurately defined. According to the PCI DSS, “At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of its PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers) to ensure they are included in PCI DSS scope. The entity retains documentation that shows how PCI DSS scope was determined. The documentation is retained for assessor review and/or for reference during the next annual PCI DSS scope confirmation activity. For each PCI DSS assessment, the assessor is required to validate that the scope of the assessment is accurately defined and documented.”
CDE is the beginning point and the center of PCI scope. Also note that PCI requires that the entity define the scope of its CDE, and that the QSA’s role is to validate that the scope of the assessment is accurately defined and documented. If CDE scope is not accurate, the QSA should work with the client to clearly define the CDE boundaries before the actual assessment begins.
Common Errors in PCI DSS Scoping
Here are some common errors I often see in relation to determining the scope of the CDE:
- Not having a complete inventory of all systems that store, process or transmit cardholder data or sensitive authentication data.
- Not identifying “unknown” data that has “leaked” out of applications and databases.
- Not identifying all physical locations that store, process or transmit cardholder data or sensitive authentication data.
- Not identifying all connected networks and confirming network segmentation is in place and effective (if network segmentation is being used to reduce scope).
- Not allowing enough time for the assessor to interview all application, database and system owners during assessment procedures.
- Not allocating enough time to perform thorough system testing during an assessment.
- Assuming encrypted data is out of scope.
Understanding the CDE scoping can be quite confusing and at times overwhelming. So when your assessor begins to dig in and figure out what your CDE is, no matter how long it takes to do it, these are some of the reasons why. How to apply the end result is important, too, and future blogs will highlight the importance of it. Determining the proper CDE is the first step toward validating PCI scope.