Select Monthly Archives
- June 2019
- May 2019
- April 2019
- March 2019
- February 2019
- January 2019
- December 2018
- November 2018
- August 2018
- July 2018
- May 2018
- March 2018
- February 2018
- December 2017
- November 2017
- September 2017
- August 2017
- June 2017
- May 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- March 2016
- October 2015
- September 2015
- July 2015
- May 2015
- March 2015
- February 2015
- January 2015
- December 2014
- September 2014
- August 2014
- July 2014
- June 2014
- December 2013
- September 2012
Written By: Chip Ross March 21, 2019
This is Part 2 in a 4-part series exploring how to ensure readiness for a Payment Card Industry (PCI) assessment, and how to avoid issues that can cause delays and additional costs. In Part 1, we discussed:
- The need for upper-management commitment
- Definitions of Merchants and Service Providers
- Who might be asking for proof of PCI compliance
- Determination of Merchant or Service Provider level
- Available PCI compliance validation options
Once we understand the basics of how PCI compliance validation works from the outside, we need to ensure we need to identify all situations in our business that may have PCI compliance implications.
Do I Understand My Organization?
From a PCI perspective, it’s all or nothing. Either an entity is compliant, or they aren’t. That means it’s very important to ensure that all portions of an entity’s business are considered. If one part of a business is compliant, but another part that is not compliant is discovered during the course of the assessment, it can lead to added delays and costs. There are two types of entities to be considered, and different approaches may be used.
In the ROC reporting template (see Part 1[CR2] ), there is a specific section for listing all business entities that require compliance with PCI DSS. It specifically mentions wholly-owned entities, and allows the assessor to list whether each entity is included as part of the assessment, or will be assessed separately. The PCI DSS Glossary doesn’t specifically address what wholly-owned entities are, but includes this definition:
Term used to represent the corporation, organization or business which is undergoing a PCI DSS review.
Lacking any other direction, we follow the Merchant IDs (MIDs) (sound familiar? If not, see Part 1). Any entity that is using a particular MID, must be included in the same assessment. Conversely, if there is some sort of organizational unit that is somehow legally defined, it may be possible to conduct a separate assessment for that particular entity.
This is especially important for any assessment involving an Self-Assessment Questionnaire (SAQ). The SAQ templates don’t have the same section specifically calling out wholly-owned entities. However, there is a spot for ‘Company Name’, and ‘DBA (doing business as)’. That means that if the company has legally defined organizational units, and are using different MIDs, it may be possible to conduct separate assessments for each.
Remember, for most Merchants, the acquirer is the one that sets the reporting requirements. That being the case, if there are any questions regarding which organizational units should be included in any particular assessment, consult the acquirer for direction. For Service Providers, consult each of the card brands.
Once the entities which require reporting have been determined, it’s important to ensure that all business units of the entity are considered. It’s entirely possible for a business unit to accept cardholder data without consulting IT or Compliance personnel (That never happens, right?). This unexpected increase in Scope (discussed further in this article) can lead to delays and added cost.
Additionally, it’s important to obtain input from all business units. In fact, if it’s possible, we recommend that representatives from all business units meet together to explore how each may handle cardholder data. We’ve found that this sort of meeting allows the representatives to ‘bounce’ things off of each other, often revealing previously unknown or unconsidered cardholder data handling.
How Are My Organizations Handling Cardholder Data (CHD)?
In Part 1, we established that entities handling a large amount of transactions must complete a Report on Compliance (ROC), which addresses all ways CHD is handled.
Entities without large transaction counts may opt to use one of the available SAQs. The SAQs also take into consideration how an entity handles CHD. Is it all e-commerce? Are there face-to-face transactions? Is CHD stored?
The SAQs are labeled A, A-EP, B, B-IP, C-VT, C, P2PE, and D. There are separate SAQ-D documents for Merchants and Service Providers.
Why is this important? Well, each of the different SAQs has a different number of requirements. For example, and SAQ-A has 22 requirements, and an SAQ-D for Merchants has 330. It is important to note that SAQ-D is the only option for Service Providers that aren’t required to complete a ROC, and contains 369 requirements.
More information regarding how the way CHD is handled affects which SAQ can be used is also available in the blog article: https://www.appsecconsulting.com/blog/pci-101-transaction-volumes-and-validation-requirements
AppSec Consulting has seen it happen numerous times; we discover unknown information about the environment during the assessment that ends up changing the nature of the engagement. It is not much fun when we discover an unknown process or system, which requires more validation tasks to complete a ROC, or requires the entity to complete a much more complicated SAQ. How do we avoid this? We carefully examine the Scope.
What is My Scope?
Consult the PCI Data Security Standard (PCI DSS) for a detailed discussion regarding the scope of a PCI assessment. We will not restate it here, but at a high level, the Cardholder Data Environment (CDE) which includes all people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data, and all systems connected to or supporting the security of the CDE are in-scope for the assessment. It is extremely important that each entity understand exactly how they handle CHD, or in the case of some Service Providers, how they are affecting the security of another entity’s CHD.
Some of the items that are important to know before any engagement are:
- Data flows; determine where is CHD:
- Traversing systems
- Payment Acceptance Channels; is CHD obtained through:
- Mobile applications
- Voice Over IP (VOIP)
- Postal Mail
- In person via Point of Sale/Interaction devices (POS/POI; registers, card swipes)
- CHD storage; where is CHD:
- Stored on my systems (databases, file storage, call recordings)
- Stored by another entity (hosting providers, off-site storage)
- Backup systems (both online and backup tapes)
- Hard-copy documents
- How is stored CHD protected:
- Encryption at rest, and in transit
- Data destruction once no longer needed
- Infrastructure; do I understand which system components are used to store, process, transmit, or protect CHD, including:
- Network devices
- Other systems providing security controls (VPN servers, logging systems, etc.)
- Inventories of all system components
- Service Providers/Outsourcing; are outside entities:
- Storing, processing, or transmitting my CHD
- Providing other managed services affecting the security of my CHD
- PCI compliant
- Not PCI compliant
- Providing documentation regarding which requirements are being addressed by them
- Covered by contracts which require them to protect any CHD they may posses
- Personnel; do I understand those who:
- Receive CHD or enter CHD into any systems
- Can view clear-text CHD
- Have access to the CDE (cardholder data environment)
- Manage the system components
- Are roles defined and documented?
- Scope reduction; to reduce scope, have I implemented
- Network Segmentation
- Payment Tokenization
- Data-loss prevention (DLP)
- PCI SSC validated Point-to-Point Encryptions solutions (P2PE)
- Other third-party solutions
Do I have a documented Scoping statement?
One of the easiest ways to ensure preparedness is to assemble all of the above information about the environment into a consolidated Scoping statement. It is basically a narrative describing the results of the efforts of your scope determination. It should describe the people, processes, and technologies regarding how your organization handles CHD, or impacts the security of another entity’s CDE.
This is a valuable tool, as it helps assessors see how the entity examined their environment, to ensure they know where CHD is present, and where it should not be present. It can also contain evidence, or references to evidence, showing the accuracy of the scoping exercise. Finally, this sort of effort is usually done collaboratively, and provides a forum where personnel can share information, which may lead to discovery of previously unknown or unconsidered possible locations of CHD.
How Can AppSec Consulting Help?
Our Qualified Security Assessors (QSAs) leverage AppSec Consulting’s proven PCI Assessment methodologies. Their many years of security, IT, development, and PCI auditing experience ensures that whatever your goals, the outcome is exactly what you need and makes strategic sense for your business. Whether you’ve been asked by your bank “to comply with PCI”, or preparing for your first validation with a Report on Compliance (ROC), gearing up for annual re-validation, or would just like to know what the PCI DSS mean to your business, our team of experts are there to help.
More information can be found at www.appsecconsulting.com, or call us at 408-224-1110