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.
