August 2015
PCI Newsletter
Welcome!
Welcome to the August edition of the Comsec PCI newsletter.
In this newsletter we will share with you, our PCI partners, PCI insights, latest trends, updates, innovations, commentaries and other Card Payment Security related items.
With each and every edition of the newsletter, we are aiming to promote discussions focusing on issues relevant to the audience – you!
We will be happy to hear from you and you are welcome to send any feedback, questions, information and requests to our e-mail: ComsecQSA@comsecglobal.com.
Spotlight: Cardholder Data Environment Scoping
This month we will focus on one of the most important phases in any PCI compliance process – the Cardholder Data Environment (CDE) Scoping.
CDE scoping is the process of identifying the system components, applications, technologies and people that store, process or transmit Cardholder Data, including any connected component. The importance of scoping lies in the goal to set expectations and recognize the efforts that would be required for compliance with the PCI DSS.
Almost 300 controls divided to 12 requirements that must be in-place for all components in the CDE, but what exactly are those components? It is not instantly obvious and also let’s face it – we are all prone to optimism bias which may cause us to think that as few as possible components are the scope of work for the PCI compliance process.
Getting back to the definition, The PCI DSS defines the CDE to be “the people, processes and technology that store, process or transmit cardholder data or sensitive authentication data, including any connected system components.”
Special attention must be given to the second part of the definition, which is sometimes ignored: “including any connected system components.”
To clarify and to enable correct scoping, the PCI SSC and QSAs provide clear instructions for accurately defining the scope of the CDE and the different components which form the scope of the assessment, using three categories of system components:
Category 1 (In-Scope): System components that process, store or transmit cardholder data or are not isolated or restricted through controlled access from other Category 1 system components. (Example: Points of Sales, Card Data database server).
Category 2 (In-Scope): System components do not store, process or transmit cardholder data but have controlled access to and/or from Category 1 devices. (Examples: Antivirus Management Server, DC, Remote Connections Server).
Category 3 (Out-of-Scope): Components that do not process, store or transmit CHD and are isolated from (no connectivity with) the CDE. (Examples: user workstation segmented by network from the CDE).
It is important to set the correct expectations regarding the scope of the CDE, right from the start of the compliance process. Following the 3 categories system is a great tool for identifying the accurate scope.
As of 2012, PCI DSS Requirement 6.2 compliance requires organizations to implement a wide process of vulnerability management, to centrally manage and classify vulnerabilities on a regular basis, and as part of ongoing compliance.
This requirement can be implemented in many ways, both manual as well as with the assistance of designated tools, but has to retain the following characteristics:
1. Automatic or manual process for prioritizing and classifying vulnerabilities in CDE components, based on external sources such as: Vendors publications, Information Security websites and Vulnerability assessment tools.
2. Produce general score/rating (High/Medium/Low).for the vulnerability based on the external score and on an internal risk consideration.
3. Prioritization and implementation of actions to remediate vulnerabilities according to their rating.
For achieving compliance with requirement 6.2, it is the responsibility of any organization to design and maintain a procedure for addressing and remediating vulnerabilities on an ongoing basis.
News and Updates
PCI DSS v3.2 is just around the corner!
Comsec consulting is taking an active part in the Council’s working groups for updating the standards, supplementals and drafts, and will inform you exclusively regarding upcoming changes expected in the new version (v3.2). What we can say right now is that it will set the ground for future dated requirements and additions to the standard. Most of the changes in v3.2 are a result of feedback received by the payment card community- QSAs, Merchants, Service Providers, and address current security threats and trends. We can be very optimistic about the Council approach for improvement, which will undoubtedly aid with compliance efforts of the community.
Service Providers: Registration in Payment Brands Lists
We have recently sent all of our PCI compliant and certified Service Providers an email with explanations about the current process for getting listed in the payment brands sites and lists for compliance Service Providers. We urge you to make sure you are familiar with the updated registration procedures, and are available for any inquiry and assistance regarding the subject.
P2PE – Merchants “Holy Grail”?
Since its initial release, the PCI P2PE standard (Point-to-Point Encryption), one of the PCI SSC newest programs, a receiving strong endorsement by both the PCI SSC and the Payment Brands. And not without a cause, since using a validated P2PE solution paves the way for a considerable scope reduction and simplification of the PCI compliance process. In fact, a single payment device can be the only in-scope component in a P2PE environment of merchants.
Comsec Consulting is assessing and certifying solution providers and merchants against P2PE. For more information, please contact us at ComsecQSA@comsecglobal.com.
