eBook for Compliance Manager

PCI DSS
That's The Way It Is!

Didier Godart

PCI DSS - Thats the Way It Is

Copyright 2015 by Didier Godart. All rights reserved.
All rights reserved under International Copyright Law. Contents and/or cover may
not be reproduced in whole or in part in any form without the express written consent
of the Publisher.

CONTENTS
Introduction.......................................................................... 7
About the author.................................................................. 9
PCI, what are you talking about?.........................................11
Payment processing terminology and workflow...................15
Distributing Roles...............................................................19
Merchant levels: What, Who and How...............................23
Whats your type?.............................................................27
DSS in a nutshell.................................................................31
Defining the Scope of the PCI assessment..........................35
Certification programs, striving for quality..........................41
The Validation Toolbox........................................................45
The Prioritized Approach....................................................51
Tokenization........................................................................55
Mind The Gap.....................................................................59
Compensating Controls: Magic Trick or Mirage?...............63
The World Isnt Perfect........................................................69
Nice Look!...........................................................................75
Is your organization behaving like

a fashion victim or a clown?.......................................79

Why are my scan reports so thick? -

Impact of potential vulnerabilities...........................85

P C I

D S S

What to do if compromised?...............................................93
Your PCI Logbook - What is required

in terms of log management?.....................................99

PCI DSS and SANS Top 20 Critical Security

Controls: The Sumo match......................................103

Qualified internal scanning staff using appropriate

scanning tools - What does that mean?...................113

Dont get lost in translation with Executives.

Get them listening...................................................121

Introduction to Risk Assessment.......................................127

PCIco strengthens the scoping rules..................................137
A New Standard is Born....................................................141
PCIP is it worth it?............................................................149
Should I disable my protection

system for ASV scans?.............................................157

The PCI Library - What docs

are required for compliance?....................................165

Do all PCI DSS requirements apply?................................167

Trainings your organization must deliver

to comply with PCI DSS.........................................173

PCI DSS Crypto-framework.............................................183

Money for nothing............................................................191
Key take-away from the PCI

Community meeting 2013.......................................199

PCI DSS Version 3 Changes and

Impact - Should You Care?.....................................209

Patch management, how to comply with PCI....................217

Control your privileged accounts - How to

contain the Keys to the kingdom problem.............227

And PCI said Get Pen-Tested!.......................................235

The Holy Grail vs ROC-Fission:

The only way to reach compliance...........................241

The 7 golden rules for Maintaining Compliance...............247

INTRODUCTION

BOUT PCI Thats the Way It is

At first sight, PCI DSS could seem simple.Twelve

requirements to swallow and that is it!

But any compliance manager who undertook the PCI

journey would tell you how it could turn rapidly into a long,
laborious, tedious and challenging journey.

The path to compliance is littered with traps, imprecisions,

doubts, technological, organizational and human challenges.

Through this book, my aim is to simplify the life of glorious

knights responsible for getting their company up to mandatory

compliance levels (and keep it there).

H OW ?
Well by anatomizing various PCI related ambiguous areas,

confusion and misunderstanding from the backstage.

P C I

D S S

This eBook is based on the authors experience and

discussions with the community, vendors, merchants, acquirers

and members of the PCI Council. You could go all over it

from the cover to the last page or use it as a reference book by

reading specific topics of interest.

D i di e r

G oda rt

ABOUT THE AUTHOR

ECOGNIZED ACTOR
AND contributor of the
PCI community from its

early days, Didier Godart set the

first security rules for e-commerce

security and co-authored the first

versions of the PCI Data Security

Standard, ASV program guide and
self-assessment questionnaires.

Didier Godart started his own company,Dgozone.com,which

educates and supports all-size and all-type of organizations

around the world on security and compliance matters.

P C I

D S S

Beside this book, he released multiple books, papers, blogs

and compliance tools such as the famous PCI, HIPAA, FISMA

Compliance Dashboards and the compliance platform.

REFERENCES
Didier Company Website: DGOZONE.COM
Didiers PCI-GO sites: Blogs, Papers, Policies, procedures,

templates, compliance dashboard and compliance platform.

http://dgozone-pci.weebly.com

G E T I N TO U C H
Feel free to contact the author for clarification, suggestions

and amendements.
Didier Godart

d@dgozone.com

Twitter: @DGodart

LinkedIn: http://www.linkedin.com/in/didiergodart

D i di e r

G oda rt

10

1
PCI, WHAT ARE YOU
TALKING ABOUT?
W H AT I S P C I ?

CI STANDS FOR: Payment Card Industry denoting the

debit, credit, pre-paid, e-purse, ATM and POS (Point of

Sale) terminal and associated businesses.

But PCI is specifically referring to the Payment Card Industry

Security Standards Council, a council formed by:
MasterCard
Visa
American Express
Discover
JCB

11

P C I

D S S

The PCI Council develops and maintains 5 standards that work

together to protect payment transactions and cardholder data.

PCI DSS: (My bible) It covers systems that store, process,

or transmit cardholder data and is used by acquirers, issuers,

merchants, service providers.

PCI PA-DSS: it covers payment applications and is used

by application developers.

PCI PTS: It covers point-of-interaction devices (or POIs)

used for PIN entry.

PCI Point-to-Point Encryption (P2PE): It defines security

requirements of such solutions, with the goal of reducing

the scope of PCI DSS assessment for merchants using

such solutions. Audience: Vendors, assessors, and solution
providers that may develop products for, implement, and
evaluate P2PE solutions.

PCI Card Production Standard: It defines the logical

security requirements for activities associated with card

production such as card personalization, PIN generation,

PIN mailing, and card distribution/delivery. Audience:
Card manufacturers and card personalization vendors

D i di e r

G oda rt

12

P C I D S S I S N T A R E G U L AT I O N
B U T A C O N T R AC T
PCI DSS is a contract that starts at payment card brands and

is propagated through merchant banks to merchants. It is

not a regulation. This contract requires merchants to protect

payment card data using security controls, but it also requires

organizations to contract for external testing, contractually

require service providers to adhere to PCI DSS standards, and

conduct audits regularly. These activities all involve IT security,

but are by no means the sole responsibility of the security team.

13

P C I

D S S

2
PAYMENT PROCESSING
TERMINOLOGY AND
WORKFLOW

NE CANNOT MOVE through the PCI ecosystem without basic understandings of the payment processing terminology and workflow. So

lets have a look behind the scene.

T H E PAY M E N T
P R O C E S S I N G T E R M I N O LO GY
In a nutshell, the payment transaction could be depicted
as follow:

We have cardholders that make payment card purchases

from merchants, merchants that send payment transaction data

15

P C I

D S S

to their acquirers, and acquirers that send payment transaction

data through the payment brand network to the issuer.

The cardholder is the person that actually has the

payment card and uses it to purchase goods or services.

The merchants are the organizations accepting payment.

The acquirer is the bank the merchant has a contractual
relationship with.

The issuer is the organization that issued the card to

the cardholder.

The payment brands are the credit card organization

(Visa, MasterCard, Amex, Discover, JCB).

Note:
Visa and MasterCard never will issue cards. Their cards are

always issued through a bank (Issuer) or other organization.

American Express, Discover, and JCB International
cards directly. They also acquire those transactions.

D i di e r

G oda rt

16

issue

T H E PAY M E N T P R O C E S S I N G WO R K F LOW
It encompasses the following operations:
1. Authorization
2. Clearing
3. Settlement
Authorization: At the time of purchase, the merchant requests
and receives authorization from the issuer to allow the purchase
to be conducted, and an authorization code is provided.
The process includes:
1. The cardholder swipes or dips card at the merchant location.

2. The merchants bank (or acquirer) asks processor to

determine the cardholders bank (or issuer).

3. The processing network determines the cardholders

bank and requests approval for purchase.

4. The cardholders bank approves the purchase.

5. The processor sends approval to merchants bank.
6. The merchants bank sends approval to the merchant.
7. The cardholder completes the purchase and receives
a receipt.

17

P C I

D S S

Clearing: In the Clearing process, the acquirer and issuer need

to exchange purchase information to complete the transaction.

The process includes:

1. The merchants bank sends purchase information to the

processor network

2. The processor sends purchase information to the

cardholders bank, which prepares data for the
cardholders statement

3. The processor provides complete reconciliation to the

merchants bank

Settlement: The merchants bank pays the merchant for

the cardholder purchase and the cardholders bank bills the
cardholder.This process includes:
1. Cardholders

the processor.

bank

(Issuer)

sends

payment

to

2. The processors settlement bank sends payment to the

merchants bank (Acquirer).

3. Merchants bank pays the merchant for cardholders purchase.

4. Cardholders bank bills the cardholder.

D i di e r

G oda rt

18

3
DISTRIBUTING ROLES

N THIS NEWSLETTER we will distribute the roles for

the PCI play.

And the winners are:

R E G U L ATO R S ( S C R I P T W R I T E R S
A N D D I R E C TO R S )
They are writing the scenarios and directing the play.
The PCI council whose main responsibilities are:
Maintain the standards and supporting documentation
Qualify assessors and perform quality assurance checks
of their work

19

P C I

D S S

 Maintain a list of validated payment applications and

approved PIN transaction security devices

Educate the community

Promote PCI on a global basis
Payment Brands responsible for:
Development and enforcement of their own compliance
program

Fines and penalties for non-compliance

Forensic investigations in case of breaches

TA R G E T E D E N T I T I E S ( L E A D I N G R O L E S )
They take the lead role by following the directors instructions.
Merchants: Business entities directly involved in the

processing, storage, transmission, or switching of transaction

data or cardholder data.

Service Providers: Same as above but on behalf of merchants.

They must ensure and maintain compliance on an ongoing

basis as well as validate and report compliance.

D i di e r

G oda rt

20

ASSESSORS (SUPPORTING ROLES)

In this category, the nominated are:
Qualified Security Assessors (QSA): They are qualified by
the Council to assess compliance to the PCI DSS standard of

merchants and service providers. They go on-site. To date, there

are 348 Qsas.
List of QSA
https://www.pcisecuritystandards.org/approved_companies_
providers/qualified_security_assessors.php

Approved Scanning Vendors (ASV): They are approved by the

Council to perform external vulnerability scans for the targeted

entities. To date, there are 110 approved companies.
List of ASVs
https://www.pcisecuritystandards.org/approved_companies_
providers/approved_scanning_vendors.php

Payment Application Qualified Security Assessors (PA-QSA):

They have been qualified by the PCI Council to have their

21

P C I

D S S

employees assess compliance to the PCI PA-DSS standard. To

date, there are 62 qualified companies.
List of PA-QSA
https://www.pcisecuritystandards.org/approved_companies_
providers/payment_application_qsas.php

Internal Security Auditors (ISA): Individual security auditor

staff of targeted entities qualified by the PCI Council to

perform the role of assessor for their organization. Companies
using ISA do not need to be assessed by QSA.

SCRIPT

N OT E S

The keyword PCI compliance on google generates more than

12 million hits.

PCI is definitely considered as a business driver for hundreds

of security companies that provide a diversity of services to

the targeted entities in the preparation and maintenance of

their compliance.

D i di e r

G oda rt

22

4
MERCHANT LEVELS:
WHAT, WHO AND HOW

HIS NEWSLETTER OUTLINES the merchant levels.

W H AT I S A L E V E L ?
Level is a classification of organizations accepting

and processing credit cards. They are defined and used by

the payment brands to indicate what compliance validation
procedures and reporting requirements targeted entities are
expected to complete.

There is no consensus in this area between payment brands

(this would be too easy ) so there are as many levels defined as

there are payment brands.

They are mainly defined based on the number of transaction

processed annually on the payment brand networks.

23

P C I

D S S

WHO DETERMINES THE LEVEL

A P P L I CA B L E TO A M E R C H A N T ?
Since acquirers are responsible for merchants compliance

they are the ones who determine the level applicable to

a merchant.

So if a merchant accepts multiple brands and those brands

utilize different acquirers, the merchant could be subjected to

multiple levels according to the acquirers.

H OW D O T H E Y D E T E R M I N E T H E
A P P L I CA B L E L E V E L ?
Acquirers qualify the applicable level mainly based on

the number of transactions processed annually, as well as any

account compromises experienced by the merchant.

Merchant levels definition per payment brands and trans-

action volume

D i di e r

G oda rt

24

Side notes:
No Level 4 merchant for American Express
No Level 3 and Level 4 merchants for JCB International
Payment brands reserve the right to escalate a merchants
level dependent on risk such as previous compromise
where PCI requirements were not in place.

25

P C I

D S S

5
WHATS YOUR TYPE?
D O N OT M I S TA K E L E V E L S
FOR TYPES!

N NEWSLETTER #4 we saw that the payment brands

classify organizations accepting and processing credit cards

into levels. Levels are related to the number of transac-

tion processed annually on the payment brand networks and

are used to indicate what compliance validation procedures

and reporting requirements targeted entities are expected
to complete.

So, pay attention: do not mistake levels for types, which

is another classification used in the context of PCIco.

27

P C I

D S S

W H AT I S I T A L L A B O U T ?
If levels are associated with the number of transactions

processed annually, types are associated with the way

organizations handle and process cardholder data. They are

used to determine which sections and requirements of the PCI
bible are applicable to these organizations.

So to know which sections of PCI DSS apply to your

organization, you need to know your type.

Side note: As types determine relevant sections and

requirements of PCI DSS, they are closely related to the self-

assessment questionnaires that organizations are asked to

complete as part of the validation procedure.

W H AT A R E T H E 9 T Y P E S ?
If levels are independently defined by each payment brand,

types have been defined conjointly by all brands. There are

nine types namely:

Type A: Card-not-present (e-commerce or mail/telephone-

order) merchants, all cardholder data functions outsourced.

This would never apply to face-to-face merchants.

D i di e r

G oda rt

28

Type A-EP: E-commerce merchants who partially outsource

their e-commerce payment channel to PCI DSS validated third

parties and do not electronically store, process, or transmit any
cardholder data on their systems or premises.

Type B: Merchants who process cardholder data only via

imprint machines or standalone, dial-out terminals.

Type B-IP: Merchants who process cardholder data only via

standalone, PTS-approved point-of-interaction (POI) devices

with an IP connection to the payment processor.

Type PE2P: Merchants using only hardware terminals as

part of a validated P2PE solution listed by PCI SSC.

Type C-VT: Merchants who process cardholder data only

via isolated virtual terminals on personal computers connected

to the Internet.

Type C: Merchants whose payment application systems are

connected to the Internet.

Type S: Service providers

Type D: All other merchants who do not meet the

above descriptions.

29

P C I

D S S

R E F E R E N C E:
For more information about the way to determine your

type, please review the PCI Data Security Standard SelfAssessment Questionnaire.

D i di e r

G oda rt

30

6
DSS IN A NUTSHELL

CI DSS WAS originally developed by MasterCard

and Visa through an alignment of security require-

ments contained in their respective programs to secure

ecommerce: the Site Data Protection for MasterCard and the

Cardholder Information Security Plan (CISP) for VISA US.

PCI DSS adopts a top down approach. It starts with six

high level goals: a confusing terminology as the unique goal

of the program is to protect cardholder data while transmitted,

processed and stored by an entity. I would prefer calling

them sections or domains. Those goals are then mapped

against 12 requirements that each subdivide into more

granular requirements. Each requirement comes with a set of
corresponding testing procedures.

31

P C I

D S S

So thinking that PCI DSS compliance is just about

implementing 12 requirements is inaccurate. There are more

than 200 specific requirements.

The schema below depicts the combination of the two first

layers of requirements:

G OA L S
The six goals, sections or domains are:
G1:

Build and maintain a secure network

G2:

Protect cardholder data

D i di e r

G oda rt

32

G3:

Maintain a vulnerability management program

G4:

Implement strong access control

G5:

Regularly monitor and test networks

G6:

Maintain an information security policy

HIGH LEVEL REQUIREMENTS

The 12 high level requirements are:
R1:

Install and maintain a firewall configuration

to protect cardholder data

R2:

Dont use vendor-supplied defaults for system

passwords and other security parameters

R3:

Protect stored cardholder data

R4:

Encrypt transmission of cardholder data

across open, public networks

R5:

Use and regularly update anti-virus software

R6:

Develop and maintain secure systems and applications

R7:

Restrict access to cardholder data

by business need-to-know

R8:

Identify and authenticate access to system components

R9:

Restrict physical access to cardholder data

R10:

Track and monitor all access to network

resources and cardholder data

33

P C I

D S S

R11:

Regularly test security systems and processes

R12:

Maintain a policy that addresses information security

S I D E N OT E S:
1. Why 6 domains and 12 requirements? Actually the

MasterCard SDP and Visa CISP programs consisted

respectively of 12 and 6 requirements. As both wanted

to keep their numbering they reached a compromise. So
the current structure of the PCI DSS is the end result
of a compromise

2. Are all requirements relevant for my organization? No,

the relevance of requirements for your organization
depends on your type (see Newsletter #5).

R E F E R E N C E S:
Link The PCI DSS V3 to https://www.pcisecuritystandards.org/
documents/PCI_DSS_v3.pdf

D i di e r

G oda rt

34

7
DEFINING THE SCOPE OF
THE PCI ASSESSMENT

NTITIES SUBJECTED TO
the PCI program have the ultimate responsibility for defin-

ing the scope of the PCI assessment.

What does that mean?

According to the rules, the PCI scope must encompass all sys-

tem components included in, or connected to, the Cardholder

Data Environment (CDE).

W H AT I S T H E C D E ?
The PCIco defines the CDE as the people, processes and

system components that store, process or transmit cardholder

data or sensitive authentication data.

35

P C I

D S S

Side note:
There is a simple way to understand the difference between

cardholder data and the sensitive authentication data. The

cardholder data is displayed on the front side of your credit

card, such as the full PAN, cardholder name, and expiration date.
The sensitive authentication data is generally printed on the

back and is used to authenticate cardholders and/or authorize

payment card transaction such as card validation codes and full
magnetic-stripe data.

W H AT I S M E A N T
BY SYSTEM COMPONENTS?
By system components one must understand:
Network components such as firewalls, switches,
routers, wireless access points, network appliances and
other security appliances.

Servers such as Web, database,authentication, mail,

proxy, time synchronization, domain name.

Applications, purchased and custom applications.

I would also add the component people into the

business departments that deal with cardholder data, as well

D i di e r

G oda rt

36

as any departments associated with the management, security,

installation and maintenance of the above system components.

H OW D O YO U D E T E R M I N E T H E S C O P E ?
The scope of PCI compliance could be extremely difficult to

determine. Probably the best way to handle this critical exercise

is by adopting a top-down approach through two series of
workshops. The aim of the first group is to capture the entire

end-to-end business process; understand where cardholder data

is used and for which purposes; as well as identifing third party

relationships and dependencies. The second series is much more
focused on technical aspects such as the identification of system

components and technical procedures that support the business

processes.

The final exercise in scoping is to create the scope document,

detailing what is in and what is out of the scope of PCI

compliance, as well as the rationale behind these findings. This

document should be regularly reviewed.

H OW D O YO U R E D U C E T H E S C O P E ?
The scope of a PCI assessment could reveal quite large for

some organizations and therefore quite demanding interms of

37

P C I

D S S

resources, time, finance as well as being an considerable source

of stress. To minimize these considerations, the associated

expenses and the risk of non-compliance, its of the utmost

importance for entities subjected to PCI compliance to reduce

the scope as much as possible. To do so one may consider the

following areas:

1 . R E D U C I N G T H E N E E D F O R DATA
S TO R AG E

Ask yourself the following question: Do we really need to keep

cardholder data? Minimizing where card data is stored helps to

reduce the scope.

2 . N E T WO R K S E G M E N TAT I O N

Network segmentation consisting in isolating the cardholder

data environment from the rest of the organizations data is

perhaps the best way to limit scope.

At a minimum, segregation should entail logical separation

between networks via router and switch ACLs, as well as

involving the separation provided by a stateful firewall. The

optimal solution being the physical separation between networks.

D i di e r

G oda rt

38

Side notes:
PCI defers to the QSA (for organizations subjected to

on-site audits) to render judgment about what is acceptable in

terms of network segregation. Different PCI QSAs interpret
this differently, adding to the challenge of PCI compliance.

For those not subjected to on-site audits, the acceptable

level of segregation is left to their own judgment.

3 . T H E U S E O F T H I R D PA R T Y S O LU T I O N S

In many cases entities are storing cardholder data

unnecessary. The most common reasons are recurring billing

and dealing with chargeback or disputes.

Outsourcing this data storage to PCI-compliant service

providers that can securely manage your payment processing

and securely store your records is definitely a way to reduce the

scope of the assessment. There are a lot of third party solutions

available that will store and perform the necessary financial

operations - authorization, clearing and settlement - on your

behalf. Such solutions usually use tokenization to help you deal

with recurring payment. Tokenization allows you to replace the

PAN with a token in your database.

39

P C I

D S S

Dealing with chargeback and disputes (the return of funds

to a consumer, forcibly initiated by the consumers issuing

bank) does not require the full PAN but generally only the last
four digits. So you could reduce the scope via that mechanism
as well.

Side notes:
1. Speak to your acquirer or processors to know what
they would need from your organization to handle
chargeback and disputes.

2. Keep in mind that outsourcing payment processing

and data storage does not absolve an entity from the

responsibility to process payments on behalf of the

business in a PCI-compliant fashion. The merchant

or business still owns and is responsible for meeting

this requirement irrespective of whether or not these

processes are outsourced.

D i di e r

G oda rt

40

8
CERTIFICATION
PROGRAMS, STRIVING
FOR QUALITY

N 2005 - for the first time in history - all major pay-

ment brands collaborated together to create a unique set

of requirements (PCI DSS) aimed at reducing credit card

fraud. As a consequence, we have seen a demand for new security-related solutions and services emerging.

We didnt have to wait long to see the security industry

respond to this demand, integrating the three letters acronym

into their marketing plans. Suddenly every security company is
a self-proclaimed PCI expert and is offering to help you become
compliant. With so much noise, there was a need for some kind

of regulation to guarantee the quality of all this help. The

PCIco partly addressed this need by establishing the thesholds

for qualification of two major actors of the program: namely

41

P C I

D S S

the Approved Scanning Vendors (ASV) and the Qualified

Security Auditors (QSA).

I was working at MasterCard in 2005 when the requirements

were put together and was personally charged with the

creation and management of the certification program for

ASVs. The PCIco does not certify products; this is not their
core competency and never will be, so the aim of the ASV

certification is to verify the ability of a scanning vendor to

detect, report vulnerabilities and misconfiguration.

My team had to do something that had never been done:

build an intentionally insecure network. While this sounds

fairly easy - by definition isnt it insecure out of the box?

- its actually not straightforward to do it deliberately for

a heterogeneous network of firewalls, routers, DNS, mail,

application and database servers comprised of a diversity of

services and applications. Furthermore, we had to know the

exact list of flaws for each target. We did this to replicate the
process ASVs go through when they scan a network.

Without much more information than a list of IPs, vendors

have to scan 10-16 remote targets within a specific time

window, which may be considered too short for some of them.

Vendors are expected to treat the certification body (test lab)

as a customer, using the same process and scanning technology

they intend to use on the field.

D i di e r

G oda rt

42

Having led this program for about 5 years I can tell you how

difficult it is to pass the test. Targets are regularly reconfigured

and vulnerabilities frequently added or removed.

To pass the test, a vendor must report their results in the

expected PCI format and reach a specific threshold (%) of

findings for each target.

I saw hundreds of companies failing again and again while

others were passing with our compliments each year. I came to

the conclusion that the success resides in two areas:

1. the scanning technology used, made of up of a scanning

engine, vulnerability databases, and reporting systems.

2. the skills and knowledge of individuals using the

scanners. While not all scanners are adequate for the
task, scanners that have been incorrectly configured
are disasterous.

Since April 2011, the PCIco has been pushing their quest

for quality further by requiring employees of ASVs to take

training and pass a test on an annual basis, in addition to the

existing requirement for the organizations ASV solution to

be annually recertified. Furthermore, the PCIco is currently

defining a quality program with the aim of controlling ASVs
on the field.

43

P C I

D S S

Much more still needs to be done in the domain of quality

and qualification though. One area were we could see the PCIco
adopting a certification program in the future is penetration
testing, though at present this is occupying a kind of no mans
land for ambigueous reasons.

D i di e r

G oda rt

44

9
THE VALIDATION TOOLBOX

CI IS PROBABLY
one of the few compliance programs out

there equipped with a com-

pliance validation toolbox. In

this newsletter I would like

to briefly cover the content of

this toolbox.

A S V N E T WO R K V U L N E R A B I L I T Y S CA N S
This tool has been specifically designed to help organizations

meeting one particular requirement of PCI DSS (11.2.2).

Perform quarterly external vulnerability scans via an Approved

Scanning Vendor (ASV), approved by the Payment Card Industry

Security Standards Council (PCI SSC).

45

P C I

D S S

PCI requires the external network scans to be performed

by security companies qualified by PCIco on an annual basis

(Approved Scanning Vendors).

The scope of the external vulnerability scan must include

all externally accessible system components that are part

of the cardholder data environment. It should also include
any externally-facing component that provides a path to the
cardholder data environment.

The scan customer is responsible for defining the scope of

the external vulnerability scan. If an account data compromise

occurs via an externally facing system component not included

in the scan, the scan customer is responsible.

ASVs are to validate any IP addresses found during the

scan with the scan customer to determine whether or not they

should be included within the scope of the assessment.
ASV scan report consists in three parts:
1. An attestation of compliance (AOC) (global compliance attestation)

2. An executive summary (component compliance summary information)

3. A detailed vulnerability report

(detailed list of vulnerabilities)

D i di e r

G oda rt

46

Side notes:
A passing result is obtained when the scan report does

not contain any high or medium severity vulnerabilities,

as well as no automatic failures as defined by PCIco

To be considered compliant an organization must pass

four consecutive ASV scans within twelve months

S E L F-A S S E S S M E N T
The self-assessment questionnaire often referred to as the

S-A-Q allows organizations to self-evaluate their compliance

with PCI DSS. This is a useful tool to determine, document and

follow up alignment with the standard.

Actually, there is a specific SAQ version for each merchant

type (see newsletter #5). Each SAQ covers only PCI sections

and requirements relevant to the corresponding merchant type.

The SAQ consists of two parts:
Questions correlating to the PCI DSS requirements
Attestation of Compliance (AOC) or self-certification

that a company is eligible to complete a specific SAQ

type

47

P C I

D S S

The different SAQ versions were originally designed to

be filled out by hand and were only available in PDF format;

however, the current official edition is available in both PDF and
word format. Beside these official formats, I currently maintain

a composite Excel version combining all the self-assessment

types into one sheet and there are online SAQs platforms
available that facilitate completion of your self-assessment.

O N -S I T E AU D I T
This tool is a thorough assessment performed within

organizations to validate their adherence to the standard.

Such assessments must be conducted by qualified external

(QSAs) or internal security auditors (ISAs) trained and

approved by PCIco.

If internal individuals are used, the key thing is that they

must belong to an internal audit organization. For obvious

independency reasons IT staff or information security staff
could not perform the assessment.
On-site audit includes:

1. Validation of the scope of the cardholder data

environment

D i di e r

G oda rt

48

2. Verification

of

documentation

all

technical

and

procedural

3. Confirmation that every PCI DSS requirement has

been met

4. Evaluation, acceptance or rejection of compensating

controls

5. Production of the Report on Compliance (ROC)

W H I C H TO O L S A R E R E L E VA N T F O R M Y
O R G A N I Z AT I O N ?
If the validation rules are specific to each payment brand,

they are all based on the merchant levels (see newsletter #4).

Depending on your level you will either need to go through

an annual on-site audit or complete the SAQ appropriate to

your type (newsletter #5). It is highly recommended that entities
that must go through an annual on-site audit also complete the
SAQ as a preparation for the on-site inspection.

In addition, nearly all organizations must present passing

results of quarterly network perimeter scans, which have to be

performed by approved scanning vendors (ASV).
Side note:

49

P C I

D S S

 The best way to know what validation tools you are

subjected to is to refer to your acquirer(s).

VISA Canada is requiring Level 2 and 3 merchants

to validate their SAQs with a QSA. Personally I dont

see any QSA endorsing a SAQ without a thorough

inspection so I dont see any difference between this

validation and an on-site audit, particularly in terms
of cost for the entities subjected to compliance. If you

have any information about this topic, please let us

know in the comments section.

D i di e r

G oda rt

50

10
THE PRIORITIZED
APPROACH

S INTRODUCED IN
our newsletter #7 - DSS
in a nutshell, organiza-

tions subjected to compliance

are required to implement more

than 200 requirements. With

this in mind, achieving compliance could be a painful, long and

costly exercise, so its legitimate to wonder how to approach

this. In response, the PCI Council shared their view on the

best approach to compliance. They code-named this the
Prioritized Approach.

51

P C I

D S S

W H AT I S I T ?
A tool to help and guide organizations establish a roadmap for
compliance, and demonstrate progress to key stakeholders.

WHO IS IT FOR?
The prioritized approach is suitable for merchants who

undergo an on-site assessment or use self-assessment type D

(see newsletter #5).

H OW D O E S I T WO R K ?
Any roadmap is composed of milestones. The prioritized

approach suggests dividing compliance projects into six phases,

each of them targeting specific security controls laid out in
the standard:

1: Remove sensitive authentication data and limit

data retention.

Scope reduction, data retention and disposal, destruction of

unnecessary data.

D i di e r

G oda rt

52

2: Protect the perimeter, internal, and wireless networks.

Traffic control, firewall, routers, DMZ, logical and physical

access control, line encryption, IDS, internal and external

scanning, penetration testing.

3: Secure payment card applications.

Hardening, standard configuration, patching, secure coding
practices and procedures, Web scanning, application firewall.
4: Monitor and control access to your systems.
Access management, users identification and authentication,
user activity monitoring and audit trail, WAP monitoring, file
integrity monitoring, incident response.
5: Protect stored cardholder data.
Data encryption and masking, key protection and management,
backup media handling, visitor handling.

53

P C I

D S S

6: Finalize remaining compliance efforts,and ensure all

controls are in place.

Policies, procedures and standards not covered above.

D i di e r

G oda rt

54

11
TOKENIZATION
THE CONCEPT
The concept of tokenization is quite simple to understand:

replacing a valuable asset with a non-valuable one. This is the

same principle as when a museum uses replicas for public

exhibition while keeping authentic artworks secure in its safe,

or how a casino uses tokens while keeping cash secured in the
vault, or when you leave your coat in a cloakroom in exchange
for a ticket.

TO K E N I Z AT I O N F O R P C I: K I L L I N G T WO
B I R D S W I T H O N E S TO N E
PCI isnt really concerned by the protection of artworks, cash

or coats, right? Here, the valuable asset is the cardholder data,

and more specifically the PAN (Primary Account Number:
the credit card number also known as account number). So

55

P C I

D S S

tokenization consists of swapping PANs wherever they are

stored by a piece of information (token) that will be not be

attractive for criminals since the token cant be used for

transactions or fraudulent charges, so there is little harm done if

its stolen. PANs could then be eliminated or stored for further
reference in an electronic vault located internally or externally.

Actually, the notion of tokenization within the PCI

framework was originally introduced in DSS V3 as an

acceptable solution to comply with requirement 3.4:

- Render PAN unreadable anywhere it is stored (including on

portable digital media, backup media, and in logs).

But we didnt have to wait long to see it used in the context

of 3.1:

- Keep cardholder data storage to a minimum.

So killing two birds with one stone.

D OW N S I D E
As tokens are replacing the sensitive PANs, any components

processing or storing this information could be removed from

the scope. The downside is all elements of the tokenization

D i di e r

G oda rt

56

system - including the PAN vault and any system component

or process with access to the tokenization system - must be
considered an important part of the CDE and therefore in
scope for PCI compliance.

Additionally, one should not overlook the effort and cost

related to the selection of an appropriate solution supporting all

their platforms as well as the effort and cost of implementation

of such a solution in their environment.

G U I DA N C E A N D R E G U L AT I O N
The council quickly understood the urgency of establishing

guidance and regulation in this area. The result is available in the

council library under the title: PCI Tokenization guidelines

57

P C I

D S S

12
MIND THE GAP

NCE THE SCOPE of the assessment is deter-

mined, our next stop on the PCI roadmap is the

gap analysis process.

OBJECTIVE
Identify gaps between where we stand and where we want

(or need) to be in terms of compliance. This process provides a

foundation for measuring the investment of time, money and

human resources thats required to achieve a particular outcome;

in this case, PCI compliance.

59

P C I

D S S

WHO SHOULD PERFORM A GAP

A N A LY S I S ?
Though there is no obligation from the council to perform

such an analysis, I would recommend that all entities subjected

to compliance perform this exercise regardless of their level

or type. For those subjected to on-site audits it will efficiently

prepare you for the QSA visit. For others, it will sustain the

self-assessment process. In both cases, it could be driven either

internally or through the expert eyes of external parties.

H OW LO N G D O E S I T TA K E TO P E R F O R M
S U C H A N A LY S I S ?
Dont underestimate it! A gap analysis process could last

between a few days to several months, depending upon the

scope, the level of control of the environment - meaning the

internal business and technical knowledge and expertise - and
finally the level of understanding of PCI DSS. I would also add
the openness mind and attitude of the participants.

D i di e r

G oda rt

60

THE PROCESS
A gap analysis process should encompass the following actions:
Identify the DSS requirements pertaining to the entities
(see merchant types).

Identify the actors: individuals sharing business or

technical expertise of the environment and who should
take part to the exercise.

Determine compliance status: discuss the compliance

status of each component in scope against relevant
requirements through brainstorming sessions and
interviews with the actors.

Document the rationale for compliance; dont limit

yourself to a Yes, justify in detail why, in your opinion,

you meet compliance. Attach proofs of compliance.
Describe compensating controls.

Identify ambiguous areas to be further investigated

with the assistance of the community or experts.

Identify

areas

of

remediation plans.

non-compliance

and

develop

Prioritize the gaps and define a timeline for achieving

compliance and assign ownership.

61

P C I

D S S

O U TC O M E
I generally see the outcome of a gap analysis as a compliance

dashboard providing us with a global view on:

Areas of compliance and associated proofs.

Areas of non-compliance associated to remediation
plans, timeline and ownership.

D i di e r

G oda rt

62

13
COMPENSATING
CONTROLS: MAGIC TRICK
OR MIRAGE?

HERE ARE CIRCUMSTANCES where companies

could face some technical or business impediments

preventing them from implementing the requirements

as explicitly stated in the standard.

Does this mean that these companies could never achieve

and maintain compliance?

There is a common misconception that organizations must

meet the requirements as they are written. This is not the case.
The important thing is that the inherent security objectives
behind each requirement are met. The PCIco and the Payment

Brands provide some flexibility by allowing companies to pull

a rabbit out of their hat. This rabbit is named compensating

controls: a very popular topic these days as more and more

63

P C I

D S S

organizations look at it as a way to achieve compliance. But is

this really the case?

W H AT I S A C O M P E N S AT I N G C O N T R O L ?
A compensating control is a work-around for a security

requirement. In other words: its another way to reach

the objective sustained by a specific security requirement

without satisfying the requirement itself. Understanding
this requirement and its objective is therefore of the utmost

importance in choosing and evaluating a compensating control.

You can refer to Navigating PCI DSS to get an

understanding of the objectives behind each requirement.

FOR WHICH REQUIREMENTS SHOULD

C O M P E N S AT I N G C O N T R O L S B E U S E D ?
With the exception of requirement 3.2 Do not store

sensitive authentication data after authorization - any security

objectives supported by the PCI DSS requirements can be met
with compensating controls.

There is, however, a caveat to the above statement.

Companies must prove that the roadblock to implementing

the requirement is temporary and due to legitimate technical

D i di e r

G oda rt

64

or business constraints. The term temporary is important as

the situation must be reviewed on an annual basis.

What does legitimate mean to the Council? It isnt very

explicit on this. Definitely the cost of implementation isnt a

legitimate constraint for them, but an application running on an

old non-supported operating system (sustained by a migration

roadmap) or the Christmas sale load delaying implementation

are two examples of acceptable legitimate constraints provided

by the Council.

W H AT I S A VA L I D C O M P E N S AT I N G
CONTROL?
To potentially be considered valid, a compensating control

must fulfill the same intent and objective of the requirement its

supposed to replace, with the same or higher level of defense,

and without introducing any other risks (border effects) or with
any additional risks both minimized and documented.

So the root of the issue is whether or not the risk has

been sufficiently addressed: the risk of not implementing

the requirement, and the risk inherent to the selection of the

compensating control.

65

P C I

D S S

H OW D O YO U D O C U M E N T A
C O M P E N S AT I N G C O N T R O L ?
Every compensating control must be supported by a risk

analysis and must be documented as follows:

What is the original objective that one tries to cover?

What are the legitimate constraints preventing meeting
the original requirement?

What is the compensating control?

What are the identified risks posed by the lack of
original control or introduced by the implementation
of the compensating control?

W H O S H O U L D VA L I DAT E A
C O M P E N S AT I N G C O N T R O L ?
According to the standard, QSAs are the ones responsible

for validating the compensating controls, at least for Level 1

merchants and service providers. There are no other validators
than the acquirers themselves for all other merchant levels.

However, the majority of the QSAs are NOT in favor of

compensating controls and would dissuade their customers

from using them. According to them, compensating controls

D i di e r

G oda rt

66

could reveal themselves to be much more costly and difficult

to implement that the requirements they replace. The fact that

QSAs must sign off the compensating controls is probably

another reason for this reluctance.

Additionally, there is no unification for the validation of

the legitimate constraints and compensating controls among

QSAs. A compensating control could be seen validated by one

QSA while being rejected by another.

A central database of historically accepted compensating

controls and legitimate business or technical constraints could

be of some added value for the community.

C O N C LU S I O N
My interviews with the Council, the Brands and the QSAs

on that matter leads me to conclude that due to the stringent

constraints imposed by the PCIco on the selection and use of
compensating controls, combined with the QSAs reluctance to
approve the use of compensating controls, and also the lack of

unification, compensating controls should be considered more

as a mirage than a magic trick.

67

P C I

D S S

14
THE WORLD ISNT PERFECT

CCORDING TO VERIZON, requirement 11 -

Regularly test security systems and processes - is

the one least met, so I thought I would dedicate a few

newsletters to this subject, starting with the definition and

source of vulnerabilities.

The term vulnerabilities is often used in the PCI DSS

standard to mean the following (per the definition given by

the Council):

Flaws or weaknesses which, if exploited, may result in an

intentional or unintentional compromise of a system.

Lets illustrate this by taking our body and soul as the system.

69

P C I

D S S

Examples:
1. As a first example, imag-

ine that Im standing in

front of you holding in my

hand a test tube contain-

ing an explosive product.

I warn you to move care-

fully because this product

is movement sensitive.
Ahh I can see the fear in
your eyes... Suddenly I

shake my handnothing happens. I explain to you that

for this product to be so reactive one needs to add a drop

of a reagent. Now lets imagine that while Im taking to

you someone does so behind my back. What would have

happened when I shook the test tube? Yes, indeed

Sorry, it wasnt my fault!

2. As a second example, lets analyze the following scenario:

A car fatally hits you while you are quietly crossing

the street. Here you are the system. What could have
caused this awful scenario? Bad luck maybe? There are

multiple factors that could have led to this scenario. You

simply crossed without paying attention; you had your

iPod on; the car driver didnt see you, you had a bad day
and you were deep in thought; you are blind, deaf or
both. The environment is also playing a role: Crossing

D i di e r

G oda rt

70

a city boulevard during the peak hours is quite different

to crossing a country street on a Sunday morning. The

factors above are the weaknesses or vulnerabilities that

increase the probability of occurrence of this scenario.

V U L N E R A B I L I T I E S I N I N F O R M AT I O N
SYSTEMS
The world isnt perfect and certainly not as pertains to

information technology. There are a variety of vulnerabilities

across information systems - including computers, network

systems, operating systems, and software applications that

may originated from vendors, system administration activities,

or user activities:

Vendor-originated:

this

includes

software

bugs,

vulnerable services, insecure default configurations, and

web application vulnerabilities.

System

administration-originated:

this

includes

incorrect or unauthorised system configuration changes,

lack of password protection policies.

User-originated: this includes sharing directories,

opening infected documents, selecting easy guessing
password,

downloading

party software.

71

and

installing

P C I

D S S

third

WHY ARENT BUGS FIXED BEFORE

S O F T WA R E R E L E A S E ?
Bugs are a conse-

quence of the nature

of human factors in
the

programming

task. They arise from

oversights or mutual
misunderstandings

made by a software

team during specifi-

cation, design, coding, data entry and documentation.

As computer programs grow more complex, bugs become

more common and difficult to fix. Often programmers spend

more time and effort finding and fixing bugs than writing new
code support. On some projects, more resources can be spent
on testing than in developing the program.

There are various reasons for not fixing bugs:

The developers often dont have time or it is not
economical to fix all non-severe bugs.

The bug could be fixed in a new version.

D i di e r

G oda rt

72

 The changes to the code required to fix the bug could be

large, expensive, or delay finishing the project.

Even seemingly simple fixes bring the chance of

introducing new unknown bugs into the system.

Its not a bug. A misunderstanding has arisen between

expected and provided behavior.

Given the above, it is often considered impossible to write

completely bug-free software of any real complexity. As a

consequence software is released with known or unknown bugs.

Is it a problem? Well lets see in our next newsletter.

73

P C I

D S S

15
NICE LOOK!

N THE NEWSLETTER #14 we discussed why bugs arent

fixed in software before release.

Once software is released and installed within our

environment these weaknesses are on our side. Is it a problem?

Examples:

Lets take the image of a bridge, a

strong and proud bridge. Cars are driving

through it the whole day without being
aware of the presence of a weakness in
its internal structure. In appearance, no

threat, no risk. And then there is a fateful

day when an earthquake intensively shakes

the city. While the bridge was supposed to resist this intensity,
it failed and collapsed, sweeping along a dozen cars and their
passengers into the river.

75

P C I

D S S

A sudden tragedy revealed the hidden threat. Of course, if

people would have known about the weakness they would

probably assess the associated risk and block the bridge, right?

Well, Im not sure because taking such a decision would have

had a huge impact for the city. This is related to the decision
process and is the subject of another newsletter.
Lets take a second example...
Imagine that you stand in a

humid spot infected by mosquitoes

and that you are allergic to their
bites. Fortunately your entire body

is sheltered under your special gear.

However you didnt notice a tiny

tear. Tiny but big enough to let a

mosquito bite you. The consequence will depend of how much

you are allergic to mosquito bites. The merchant you bought it

from would not replace your gear, but suggests you sew it up or
stick on a small piece of material to patch the hole.

T H E C O N S E Q U E N C E S O F S O F T WA R E
BUGS IN OUR ENVIRONMENT
The presence of software bugs or holes within our

environment could create a whole set of issues such as preventing

D i di e r

G oda rt

76

legitimate users from accessing functionalities; impacting the

performance and usability; crashing services or servers; leading

to confidentiality breaches; escalating user privileges; soiling

data integrity. Is this a problem? Well it depends of the severity
of the bugs (what the bug could lead to) and the criticality of
the environment on which they run.

The same bug could reside simultaneously on a production

server and a test server. The same bugs will have the same
consequence on both servers such as leading to crashes, but the
criticality would be more important for the production server

than the test server. This aspect is of the utmost importance

when considering a remediation plan. But before fixing a bug
one must detect it.

As said in the previous newsletter, bugs could be known

or unknown. They could be detected accidentally or through

code analysis and application testing. They could be detected

by company developers or testers, by the users or by malicious

individuals looking for them. Once known they should be fixed.

This fix generally consists in writing a small piece of software
called a patch in the same way the merchant or tailor would
apply a patch on your gear.

Ill let you decide how you would look if your clothes

consisted of as many holes as there are in software. Maybe this

could become a new fashion.

77

P C I

D S S

Once bugs are detected and fixed on the software company

side, they still need to be fixed within our environment and

thats another story.

D i di e r

G oda rt

78

16
IS YOUR ORGANIZATION
BEHAVING LIKE A FASHION
VICTIM OR A CLOWN?

N THE PREVIOUS newsletter we discussed the severity

of the presence of bugs in software, and how these bugs are

handled on the software vendors side. Now lets discuss

the customer organizations side.

W H AT CA N W E D O A B O U T
S O F T WA R E D E F E C T S ?
Software is buggy. This is a fact (See newsletter #14).

Returning to the analogy of protection gear used in our last

newsletter, my son is constantly reminding me that wearing

pants with rips and holes is actually the fashion and I should
accept it. Nevertheless, I find it quite weird that the price of a

79

P C I

D S S

piece of clothing increases with the number of scratches and

holes in it.

Similarly organizations are facing a crucial dilemma:

Either leave holes in software and look

like a fashion victim or wear so many patches

you look like a clown. Mmmm, not a great

choice. The solution is maybe somewhere
in between.

The problem is that, as we discussed in our

last newsletter, holes equal vulnerabilities,

which equal risk for the organization.

The whole process of reducing risks associated with holes

in software is called vulnerability management, a strange

denomination as a vulnerability could be more than a simple
hole in the cloth, I mean in software. Personally I would prefer
to call this process the holes and defects quest.

Vulnerability management plays a major part in the

workload of individuals responsible for security. It is highlighted

by all best practices and guidance manuals, as well as by all

regulations and compliance programs, including PCI. The sixth

and seventh verses of the data security standard bible state:

D i di e r

G oda rt

80

6: You will develop and maintain secure systems and

applications

11: You will regularly test security systems and processes.

W H AT I S I N VO LV E D I N A V U L N E R A B I L I T Y
M A N AG E M E N T P R O G R A M ?

The medical world follows a specific protocol to cure patients:

Diagnose: Identify the patients illness based on symptoms

and a panel of test results.

Determine the risk: What could the impact be for the

patient if the illness is not cured?

Prescribe: Determine what remedy could be applied, if any,

and the potential side effects for the patient.

81

P C I

D S S

Decide: Based on the above data, the doctors and the

patient decide on a treatment plan.

Treatment: The patient applies the prescription.

Control: The doctors perform regular checks to make sure

the cure is on working as expected.

Curing software of vendor vulnerabilities (holes, defects)

follows the same protocol.

Diagnose: Identify the presence of (known) holes/defects

(vulnerabilities) through a set of tests called network/system/

application/database scans.

Determine the risks: Assign a risk level to each identified

vulnerability accounting for the consequences of security

incidents resulting from exploitation of the vulnerability, the

existence of scripts (exploits) facilitating the exploitation,

the nature/sensitivity of the organization, the presence of

compensating controls reducing the exploit intensity, the time

elapsed since the the vulnerability exposure, the existence of

remedies. Penetration testing is a useful tool to help you quantify

the real level of risk associated with the identified vulnerabilities.

D i di e r

G oda rt

82

Prescribe: List all countermeasures leading to remediation

or risk mitigation as well as the additional risks (side effects)

induced by the application of these remedies.

Decide: Based on the above information, determine

prioritization

and

the

assign responsibilities.

more

appropriate

action

plan,

Treatment: Follow action plan.

Control: Verify the effectiveness of the action plan through

regular checks (scans).

83

P C I

D S S

17
WHY ARE MY SCAN
REPORTS SO THICK? IMPACT OF POTENTIAL
VULNERABILITIES
My PCI scan report has more pages than the NASA report
related to the crash of the space shuttle Columbia.

HIS ACERBIC STATEMENT

was made by a merchant com-

plaining about the size of his

external scan reports.

Verse #11.2 of the PCI data security

bible requires organizations subjected

to PCI compliance to run internal and

external network vulnerability scans

at least quarterly on their CDE (card data environment). The

PCIco regards risk relating to the internal and external sides of
the CDE differently. This translates in the subdivision of verse

85

P C I

D S S

11.2 into 11.2.1 (related to internal scanning) and 11.2.2

(related to external scanning). While the level of flexibility and

initiative allocated to companies is indecently large in terms

of internal scanning organizations may basically do whatever

they want external scanning is subjected to more demanding,

structured and explicit rules starting with the mandated use

of an approved scanning vendor (ASV) submitted to annual

certification. When running scans, ASVs must strictly comply

with specific rules published by the PCIco in a document

called: ASV Program Guide Reference.

W H Y A R E E X T E R N A L S CA N N I N G
REPORTS SO THICK?
The major causes of the thickness of a PCI scan report are:
1. The extent of the scan fields.
I wouldnt surprise anyone by stating that the more targets

you have to scan the more thick your report would be.
2. The structure of the scan report

As part of the ASV Program Guide, the PCIco requires

ASVs to report scan results in a specific way. The report must

consist in threefold:

D i di e r

G oda rt

86

a) a short attestation of compliance

b) an executive summary
c) a detailed vulnerability reports.
In terms of structure, the pain part is the executive summary

that is far away from being what one would expect from an
executive summary: short and straight to the point. The PCIco

requires the executive summary to list all detected vulnerabilities

for each target, including the severity level, the CVSS score, the

compliance status (PASS or FAIL) as well as any associated

exception, false positive, or compensating control. Additionally

PCIco requires that the long executive summary be amended

with a consolidated solution/correction plan for each target.

Based on the above, one could easily understand why

an executive summary would be long. One could expect the

executive summary would be split into a real executive summary

and a technical summary limited to the list of detected

vulnerabilities that do not PASS the compliance threshold in

terms of severity and excluding out informational results. Those

are the ASVs recommendations to PCIco.
3. Potential vulnerabilities
What the hell is a potentialvulnerability? Many merchants

ignore it and show suspicion when being told by their ASV

87

P C I

D S S

about it and for good reason as this term is absent from the PCI

glossary and PCI dss bible. However, potential vulnerabilities

weight highly into the causes of the report thickness as well as

into the causes of scan failure and workload associated with the
vulnerability management.

The PCIco introduces this term into the ASV Program

Guide as a vulnerability from which the presence cannot be

determined with certainty. Unfortunately nothing is said about
what the PCIco considers as certainty.

Abstract - ASV Program Guide V2 pg 17:

In addition to confirmed vulnerabilities, ASVs must report

all occurrences of vulnerabilities that have a reasonable level of

identification certainty. When the presence of a vulnerability cannot

be determined with certainty, the potential vulnerability must be

reported as such. Potential vulnerabilities must be scored the same

as confirmed vulnerabilities and must have the same effects on

compliance determination.

D i di e r

G oda rt

88

C O N F I R M E D V E R S U S P OT E N T I A L ?
For a neophyte it could

sound strange to say that an

ASV could be uncertain of the

presence of a vulnerability. Why

is that?

The root of the answer lies

in the blind nature of an external scan. Scans are performed

remotely through the Internet with no privileged (admin)

access to the targets as this would require transmitting admin

credentials through the Internet, which is not a recommended

practice! Furthermore, the signature (name and version) of the

targets could have been voluntarily modified or obfuscated for
the sake of security.

In

the

same

way

SONAR recognizes boats

based on the noise pattern

generated by their engines,

vulnerabilities

could

be

determined with a high

level of certitude based on the response patterns received from

targets. Another bunch of vulnerabilities are reported only

because such service name, such version number and patch

89

P C I

D S S

levels have been (maybe erroneously) determined. Those latest

ones are what the PCIco considers potential vulnerabilities.

However, for the readers of a scan report there is no difference

between confirmed vulnerabilities and potential ones. They are

all falling into the long list of reported vulnerabilities.

Besides impacting the size of the scan report, potential

vulnerabilities are causing a high rate of false positives and

therefore impacting the reliability of the scan results and the

workload of the individuals in charge of verifying the level of

certainty of each vulnerability. They are not considered to add

value by many ASVs. In fact, some ASVs go so far as to play

against the rules by completely ignoring them from their scan
reports in order to increase the level of accuracy of their reports
and customer satisfaction.

Despite their evident low added value and poor impact on

the accuracy of the scans, the thickness of the reports and the

workload, the PCIco persists in requiring ASVs to include

these potential vulnerabilities into their reports

I WA S B L I N D B U T N OW I S E E !
As a suggestion to decrease the level of blindness of external

scan reports and decrease the workload, companies should

consider scanning external targets from the inside as part of

D i di e r

G oda rt

90

their mandatory quarterly internal scans. This secured scan

source allows for authenticated scans with full access to the
targets and is therefore
more reliable. Use the
internal scan reports to
quickly spot false positives

in the external scan reports.

A second, but less practical option is to establish an

encrypted tunnel between the scan source and the scanned

network allowing for the use of authenticated checks.

91

P C I

D S S

18
WHAT TO DO IF
COMPROMISED?

XPERIENCE AND STATISTICS show us that the

unlikely happens, we dont know when, we dont know

how but we know it will occur. So management should

better be concerned by being prepared to face an incident than

by being secure.

Im compliant so I dont care.

The above principle has never

been so true within the context

of PCI where compliance doesnt
really

shelter

organizations

from compromises and therefore penalties.

93

P C I

D S S

Achievement of PCI compliance is a long, costly, and

fastidious journey to the promised land of immunity towards

penalties. To avoid or minimize penalties, compromised

companies must prove that they did everything they could

to prevent, detect, report, and follow up on an incident in

accordance with the, rules.

Payment Brands have stringent rules and fines related to

incident reporting.

For instance, VISA is requiring their members (banks) to

immediately report suspected or confirmed losses or theft of

any transaction data. Members failing to do so are subjected

to a $100,000 fine per incident + $50,000 for any merchant or

service provider that is not compliant at the time of the incident.

A S A M E R C H A N T O R S E RV I C E
P R OV I D E R W H AT D O I H AV E TO D O ?
Upon occurrence of a security breach and/or suspicion

of compromised card data, an overwhelming sense of panic

could paralyze any individual responsible for security and/or

compliance. The fear of responsibilities and business impacts in

terms of penalties and reputation could disconcert more than

one. As mentioned above, the compliance status at the time

of the incident would not be sufficient to keep you sheltered

D i di e r

G oda rt

94

against these fears. You have to act rapidly accordingly to the

procedures. In this domain as indicated by PCI DSS 12.10
preparation is key.

Req 12.10 (PCI DSS) requires merchants and service providers

to be prepared to respond immediately to a breach.

W H AT A R E T H E P R O C E D U R E S ?
Its important to note that the payment brand reporting

procedures and associated fines are applied to members (Banks)

not the merchants and services providers. Unfortunately there
are no publicly available rules applicable for merchants and

service providers in case of compromises. So the first advice

would be to liaise with your bank to determine what are

these procedures and associated milestones as well as specific
reporting templates. Different procedures and report templates

could be required for different payment brands. Act right now

and dont wait for a compromise. You will not have the time.
Such procedures could include the following parts:
Contain, limit the exposure, and monitor.

95

P C I

D S S

 Do not access or alter compromised system(s). Do not

turn the compromised system(s) off. Instead, isolate
compromised systems(s) from the network
Preserve evidence and logs
Document all actions taken.
Be on high alert and monitor traffic on all systems with
cardholder data.

Alert all necessary parties immediately

Internal incident response team
Your Bank (PCI contact)
Law enforcement agency
Make Inventory of compromised data
Make an inventory of potential compromised data and

report it to your bank

Perform Initial investigation and deliver breach report

Perform an initial investigation and provide a breach

report to your bank. This report must help them understand

the breach vectors and potential extent of the compromise as
well as the actions taken to contain and limit exposure. For this

D i di e r

G oda rt

96

investigation merchants could use their own internal resources

or the services of a consulting company.

I S I T M A N DAT E TO U S E A P F I ( P C I
F O R E N S I C I N V E S T I G ATO R ) ?
When deemed necessary by the payment brands, an

independent forensic investigation could be required. In this

case the compromised organization must engage a PFI company

from this list and support the cost. The role of such a company

is to investigate the case and verify the level of responsibility of

the compromised entity.

97

P C I

D S S

19
YOUR PCI LOGBOOK
- WHAT IS REQUIRED
IN TERMS OF LOG
MANAGEMENT?
P>D+R is a well-known

principle in security.

Its a principle that means

that the Protective measures

in place must be strong

enough to resist longer than

the time required to Detect something wrong is happening and

then React.

For example, your door must be strong enough to prevent

a malicious individual from getting in for at least the amount

time required to detect the incident, alert the police, and have
them arrive on site.

99

P C I

D S S

In this context, log management plays a specific role. It helps

limit the risk of occurrence of incidents by detecting upstream

suspicious activities. They help with understanding the modus

operandi of incidents by tracking back the activities.

A little story. Four guards are instructed to watch the

perimeter fence of your organization. The first one falls rapidly

asleep lulled by the silence of the night, the second one, a

passionate writer, logs in his notebook every observation--

including the presence of stars, clouds, the temperature and his

state of mind. The third one, a bit stressed, rings the alarm bell
every time he detects or hears something.

Alert!! This isoh..a rabbit. Im so sorry guys!

The fourth and last guard, an instructed and skilled

professional, writes down specific events he learned to classify

and awakes the garrison only in case of emergency.

As illustrated through the above scenario, audit trails have

their own problems. They are useless if too quiet or too talkative,
and without adequate monitoring. In other words, monitoring

is inefficient if too scarce, too permissive or too alarming. To

be efficient, audit trails must be configured appropriately and
constantly reviewed.

D i di e r

G oda rt

100

In this domain, PCI DSS specifies what events must be

logged (10.2) as well as what data must be recorded for each

events (10.3). PCI DSS also addresses the protection of the

audit trails (10.5) and audit files retention (10.7).

In terms of review, PCI DSS requires audit trails to be

reviewed on a daily basis (10.6)--which is more prescriptive

than SANS Top 20 Critical Security Controls that suggests

biweekly reviews. However SANS goes further than PCI by

suggesting the automation of this tedious process through the
use of SIEM technology.

W H AT I S S I E M T E C H N O LO GY ?
SIEM

stands

Event Management.

for

Security

Information

and

Its the combination of SIM (Security Information

Management) collecting information and doing some basic

analysis and SEM (Security Event management) evaluating

the collected information in search of defined security events.

101

P C I

D S S

W H AT D O E S S I E M T E C H N O LO GY D O ?
SIEM technology allows event logs to be automatically

collected, centralized and managed (analyzed, filtered, classified

and reported) such that security events are reported according

to their level of risk. So a SIEM could be perceived as a kind of

intelligent robot that would observe what is going on, detect

signs of aggression, generate reports, and ring the alarm bells

in case of emergencies (upon detection of critical anomalies).

Technically PCI doesnt require or prevent the use of such

technology, which carries its own problems as well. Some

organizations achieve compliance in regards to log management

without a SIEM, while for others a SIEM technology is deemed

necessary due to the high volume of logs.

H OW D O E S Q S A VA L I DAT E
COMPLIANCE?
To validate implementation, Qualified Security Assessors

(QSA) are required to perform interviews, review the related

policies and procedures and samples log files. Organizations

subjected to compliance must confirm implementation of the

requirements during the interviews and show the policies and
procedures related to log management as well as samples of
audit logs.

D i di e r

G oda rt

102

20
PCI DSS AND SANS TOP
20 CRITICAL SECURITY
CONTROLS:
THE SUMO MATCH.
YO U S A I D M I N I M U M. R E A L LY ?

OW CAN WE be sure that the PCI DSS requirements are sufficient and stay aligned with the evolu-

tion of attacks? This is a fair question raised by Mike

Mitchell VP global network operations at American Express.

On page 5 of PCI DSS V3 one could read that PCI DSS

comprises a minimum set of requirements for protecting cardholder

data, and may be enhanced by additional controls and practices

to further mitigate risks. The term minimum in the above

statement made me anxious and I felt the need to clarify if PCI

DSS was really about the least possible requirements that an

103

P C I

D S S

organization should implement to protect the sensitive data.

Dont we leave something critical on the side?

For this purpose I had the idea to compare PCI DSS

against another guideline considering also the least possible set

of security measures that one should consider to implement

an effective defense against known attacks, namely the SANS

Top 20 Critical Security Controls. Through this analysis I was
looking for answers to the following questions:

What are the connectivities between PCI DSS and

SANS Top 20 Critical Security Controls?

Which controls map which requirements?

Which of PCI DSS or SANS is the most prescriptive,
the more demanding?

What are the gaps and how wide are they?

And finally: Whats the value of PCI DSS on a
security scale?

This newsletter provides you some insights into the outcome

of this analysis.

D i di e r

G oda rt

104

PCI or SANS: whos gonna win?

O N M Y R I G H T, P C I D S S
The bible, as I used to call it, is considered by the security

community as one of the more pragmatic and prescriptive

standard on the field. PCI DSS is organized into 6 domains,

12 requirements, about 200 sub-requirements and about 500
validation points. PCI DSS contrasts with other standards such
as ISO 27002, FISMA or HIPPA by the way it tells you what

to do, how to do it, how to validate implementation and even

how to prioritize your roadmap.

105

P C I

D S S

O N M Y L E F T, S A N S TO P 2 0 S E C U R I T Y
SECURITY CONTROLS
SANS identified a subset of security control activities that

security responsible individuals can focus on as their top shared

priority for cyber security based on attacks occurring today

and those anticipated in the near future. These Top 20 Critical

Security Controls were agreed upon by a consortium including

NSA, US Cert, DoD JTF-GNO, Department of Energy

Nuclear Laboratories, Department of State, DoD Cyber

Crime Center plus the top commercial forensics experts and

pen testers that serve the banking and critical infrastructure

communities.They map directly to about one-third of the
controls identified in NIST Special Publication 800-53 rev 4

and correlate to the highest technical and operational threat

areas for the federal agency enterprise environment as well as
private sector enterprise environments.

This tedious analysis revealed important gaps in both PCI

DSS and SANS Top 20 Critical Security Controls when

compared again each other.

D i di e r

G oda rt

106

T H E P C I D S S V E R S U S S A N S TO P 2 0
C R I T I CA L S E C U R I T Y C O N T R O L S
PERSPECTIVE
40% Is the value of PCI DSS along the SANS Top 20

critical security controls axis.

On the total of 190 security sub-controls constituting the

SANS Top 20 Critical Security Controls, 28 are partially

covered in PCI DSS, 59 are fully covered while 103 of these
sub-controls arent covered by PCI DSS.

If PCI addresses all SANS Top 20 Critical Security

Controls with the exception of #2- Inventory of authorized

and unauthorized software, this study reveals a poor coverage

107

P C I

D S S

in PCI DSS at the level of the technical security sub-controls

of SANS.

T H E TO P T H R E E C O N T R O L S B E S T
C OV E R E D I N P C I D S S A R E:
#18- Incident Response Capability (100% of matches)
#16- Account Monitoring and Control (58%)
#14- Maintenance, Monitoring, and Analysis of Audit Logs.

T H E L E A S T C OV E R E D C O N T R O L S I N
P C I D S S A R E:
#1-Inventory of authorized and unauthorized devices and

software

#2-Inventory of authorized and unauthorized device and

software

#4-Continuous vulnerability Assessment and remediation

#5- Malware defense
#15 - Controlled Access based on the need to know.

D i di e r

G oda rt

108

The other controls are covered with an average of 42%.

T H E S A N S TO P 2 0 C R I T I CA L S E C U R I T Y
CONTROLS VERSUS PCI DSS
PERSPECTIVE
49% Is the value of SANS Top 20 Critical Security Controls

along the PCI DSS axis.

On a total of 180 sub-requirements constituting the PCI

DSS 12 requirements, 8 are not applicable within the context

of SANS Top 20 Critical Security Controls, 21 are partially

covered by SANS, 73 are fully covered and 78 are not covered
by SANS.

109

P C I

D S S

The study reveals that PCI DSS is much better structured

and covers a wider spectrum of security domains than SANS

Top 20 Critical Security Controls. Physical protection, policies

and procedures, line and data encryption are poorly or not

addressed by SANS Top 20.

T H E B E S T C OV E R E D R E Q U I R E M E N T S I N
S A N S TO P 2 0 A R E:
#5 - Use and regularly update anti-virus software or

programs (100%)

#11 - Regularly test security systems and processes

#1 - Install and maintain a firewall configuration to protect

sensitive data (90%)

#2 - Do not use vendor-supplied defaults for system

passwords (88%)

D i di e r

G oda rt

110

T H E L E A S T C OV E R E D R E Q U I R E M E N T S I N
S A N S TO P 2 0 A R E:
#3 - Protect stored sensitive data (4%)
#9 - Restrict physical access to sensitive data (10%)
#12 - Maintain a policy that addresses information security

for all personnel (24%)

#7 - Restrict access to sensitive data by business need to

know (28%).

The other requirements are covered in SANS Top 20 with

an average of 61%.

A potential explanation for these deviations is the fact that

PCI DSS is feeding a compliance program that ought to be

flexible and affordable by a variety of profiles with different

level of knowledges while SANS Top 20 Critical Security

111

P C I

D S S

Controls are concerned about security and target a more

specialized audience.

According to Mike Mitchell, VP global network operations

at American Express. PCIco objective is to integrate Security

in organizations everyday business. This study underlines

that neither of PCI DSS or SANS Top 20 Critical Security

Controls seem to cover the least sufficient enough measures to

defend against know attacks. Therefore, the community would

greatly benefit of a new standard combining the best of PCI
DSS and the SANS Top 20 Critical Security Controls. Are
there candidates for such an enterprise?

I would like to conclude with this great statement of Bob

Novak, Enterprise/IT Architecture and Security:

I have used PCI as a framework in the past to help jump-

start security programs. I have used PCI for this purpose because
technologist can understand PCIs simplistic requirements and
can self-assess and self-correct easily where PCI is concerned. If

confronted with security controls (i.e. SANS, etc.), however, the eyes

of technologists seem to glaze over and they do not know where

to start. The security controls need to be translated for them into

language they understand or their efforts stagnate. Thus I consider

PCI a helper framework to precede SANS, NIST, CobIT, etc. in a

two-phased evolution to a viable security program.

D i di e r

G oda rt

112

21
QUALIFIED INTERNAL
SCANNING STAFF USING
APPROPRIATE SCANNING
TOOLS - WHAT DOES
THAT MEAN?

VERY

CUSTOMER,

(MERCHANTS,

Service

Providers), should be acquainted with the fact that

they must assign their quarterly external scans to an

Approved Scanning Vendor certified by the PCI Council.

What is less known is that external scans conducted after
network changes and in between quarterly scans, as well as

quarterly internal scans, may be performed by the companys

internal staff as long as they are qualified and use appropriate tools.

113

P C I

D S S

 Q UA L I F I E D S TA F F , A P P R O P R I AT E
TO O L S , W H AT D O E S T H AT M E A N ?
So far the PCI Council has been sparing with clarification

of those terms. If your Organization is subjected to on-site

audits its up to the auditors, (QSA or ISA), to determine the

pertinance of the scan solutions and the level of qualification

of your staff. If you arent subject to on-site audits, these aspects

could be evaluated by a forensic investigator upon compromise.

On both cases, youd better be on the safe track.

While we are waiting for clarification from PCIco, let me

share with you my personal understanding of what is expected

from internal, Qualified, staff and, Appropriate, tools within

the context of quarterly and adhoc internal scans.

Q UA L I F I E D S TA F F
Ive never laid an egg in my life.

And yet I feel more qualified than

a chicken to judge the quality of an

omelette - Max Favalelli

To be considered qualified, your

internal staff should be continuously

educated, (trained, certified + collect of CPE points), within

D i di e r

G oda rt

114

the context of IT network scanning and IT vulnerability

management. More specifically, they should possess up-to-date

technical knowledge, skills, and ability to identify, assess, and
report IT related vulnerabilities and misconfiguration through
the use of your appropriate scanning tools.

In addition to the technical abilities, your staff should be

familiar with the following considerations applicable to ASV

such as:

Scope determination
Management of false positives/false negatives,
Determination of CVSS scoring and their exceptions
Determination of the severity levels based on the NVD
and CVSS scoring

Management of interferences such as IDS/IPS,

Firewalls

Determination of PASS/FAIL status.

Vulnerabilities and misconfigurations leading to

immediate failure such as the identification of default

accounts and passwords.

Quality Assurance

115

P C I

D S S

A P P R O P R I AT E TO O L S
A bad workman always use bad tools - Quebec quote.
The scanning tools are as important

as the knowledge, skills, and ability of

the staff. To be considered, appropriate,

a scanning tool should fit the PCI
requirements that are described in the
ASV program guide.
Be non-disruptive
Perform host discovery
Perform service discovery on all TCP and common
UDP ports

Perform OS and Service fingerprinting

Cover all platforms used on the organization IT
infrastructure

Report

vulnerabilities

that

have

reasonable

level of identification certainty and all the others

(Potential vulnerabilities)

Regularly updated (baseline of vulnerabilities).

Perform authentication checks

D i di e r

G oda rt

116

 Report vulnerabilities and misconfigurations on:

firewall, operating systems, database servers, web servers,

application servers, DNS servers, Mail servers, Web

applications, Common services, Wireless access points.

Detect built-in accounts backdoors and other malicious
programs

Detect the presence of TLS and associated encryption

& signature algorithms, certificate validity

Detect remote software

Report associated CVSS score
Determine PCI Severity and Compliance according to
CVSS scoring

Fail any vulnerability and misconfigration associated

with a CVSS score equal to 4 or above.

Provide guidance to solve identified issues

Provide a risk score for all vulnerabilities.
Pass any Denial of service vulnerability.
Fail any vulnerability and misconfigration associated
with a CVSS score equal to 4 or above.

Fail the following issued independently of the

CVSS Score:

117

P C I

D S S

Default accounts and passwords,

DNS unrestricted zone transfer

Unvalidated parameters that lead to SQL injection attacks

Cross-site scripting (XSS) flaws

Directory traversal vulnerabilities

HTTP response splitting/header injection

Backdoors, malware, rootkits, and Trojans

SSL version 2.0 or earlier version

Results should preferably be presented through a high level

and detailed perspectives.

The High level perspective should include the overall

compliance as well as the component compliance listed

by IP address and of course the scan date and name of

the manager of the scanning team.
The

detailed

perspective

should

include

all

vulnerabilities along with the affected IP(s), detailed

information, fixing guidances, CVSS score, PCI

Severity, Compliance status and a note in case of

exception or false/positive.

D i di e r

G oda rt

118

Note: ASV scanning solutions have been configured in such

a way to support the above requirements. The best tactic would

be to choose one of these solutions which are available for

internal usage.

REFERENCE
ASV program guide

119

P C I

D S S

22
DONT GET LOST IN
TRANSLATION WITH
EXECUTIVES.
GET THEM LISTENING.
I need people and I need funding to do my job properly.
Executives dont get it - They want me to bulletproof their
systems but dont want to listen.

OES THIS SOUND

familiar?

Of

course,

such moaning fills the

room of security gathering ses-

sions such as the any local PCI

Community meeting.

IT security responsible persons

usually point to Executives as

a major impediment to their

mission. Why is that? I think that

121

P C I

D S S

Executives and IT Security DO work toward the same goal:

Securing the business. They differ in terms of focus, interests,

beliefs, perspectives, way of working, and languages. In such

circumstances it shouldnt surprise anyone that Executives

and IT Security are somehow lost in translation. Sorry I dont
understand what you are saying, are you speaking Business?

How can we avoid this? How can we move these two

camps closer?

I N VO LV E E X E C U T I V E S I N K E Y S E C U R I T Y
G OV E R N A N C E AC T I V I T I E S.
According to a study from the Carnegie Melon Cylab on

How Boards & Senior Executives are managing Cyber Risks

(see link at the bottom): Executives tends to:

overlook security among their top agenda items.

not review the policies that are set.
not look at the roles and responsibilities assigned to
key personnel.

not review security incidents

delegate these IT things to experts.

D i di e r

G oda rt

122

One way to make Executives sensitive to security is to

involve them in key security governance activities. So although

not explicitly required by PCI DSS, it would be wise to establish

coordination meetings with Executives (at least twice a year)

for the endorsement of key materials such as these:
IT Risk analysis,
security roadmap,
security policies
assignment of security related responsibilities.

A D O P T T H E I R L A N G UAG E A N D
P R OTO C O L S.
Executives DO listen but people responsible for IT Security

need to learn how to communicate effectively with them.

In this context, here are some advices shared by John South,

CISO for Heartland Payment Systems in an interview: How

to talk security to the board of directors.

Dont be afraid to discuss security issues openly so they

can understand what impact those issues may have.

Getting them to understand the issues and to make a

decision is usually a matter of managing time rather

123

P C I

D S S

than managing information. So stay focused and go

straight to the points.

Keep in mind that Executives see things from a business

perspective as opposed to a technical perspective.

Think like a business person

Put everything in a manner that allows them to quickly
see the big picture.

Encapsulate your security story into a business case.

Show them what impact it has for the company, what
impact it has for operation; what are the remediation
plan(s) and associated costs.

Use scorecards, dashboards and colors.

Make sure they get all the information they need to

take a decision BUT banish all technical terms, designs,

and irrelevant info.

As Quoted by Einstein If you cant explain it simply,

you dont understand it well enough, Use only words
that a six year old child could understand.

Drill your presentation with non-technical audiences

such as sale or marketing people.

D i di e r

G oda rt

124

The

principles

application
could

of

be

these

quite

challenging. Make sure to include

trainings

in

your

individual

development plan to develop your

presentation and communication

skills. Learn to expose business

cases in a very short presentation with the minimum

necessary information.

125

P C I

D S S

23
INTRODUCTION TO
RISK ASSESSMENT

F YOU WENT to work this morn-

ing, you took a risk. If you rode your

bicycle, walked, or drove a car, you

took a risk. If you put your money in a

bank, or in stocks, or under a mattress,

you took other types of risk. If you
bought a lottery ticket at the news-

stand or gambled at a casino over the

weekend, you were engaging in activities that involve an element of chance something intimately connected with risk.

PCI DSS Requirement 12.2 requires organizations

to establish an annual process that identifies threats and

vulnerabilities, and results in a formal risk assessment. In this

newsletter I would like to address this notion of risk assessment.

127

P C I

D S S

THE BEGINNINGS
The term risk seems to take its source from a navigation term

used by the Greek sailors, Rhizikon which meant root, stone,

cut of the firm land and was a metaphor for difficulty to avoid

in the sea. The Chinese added the notion of opportunity.

Indeed, the word for risk in Chinese is constructed from two
symbols. Danger and Opportunity which is more in line with
our modern understanding of risk assessment: Identification
and evaluation of dangers that could prevent us to reach our

objectives. Italians add a layer with the word risicare which

means to dare. In this sense, risk is a choice rather than a fate,

a decision to take action to avoid/prevent the dangers along

our way. This latest notion completes this picture: Identifying,

Evaluating + Decision = Risk management.

If this ability to define what may happen in the future and

to choose among alternatives lies at the heart of contemporary

societies, back in old time the notion of risk didnt exist. All

cause (positive or negative) was a direct consequence of Gods

decision. People left their fate within the hands of God and if

D i di e r

G oda rt

128

something wrong occurred it was undeniably not due to a lack of

careless or preparation but just the sign of Gods anger. Nothing

could have been done to prevent this misfortune or could be

done to prevent it in the future except maybe some bloody

sacrifices on the altar, and even nowadays, some organizations

seem to continue a head-to-head against the fates.

We had to wait until the Renaissance when people broke

loose from the constraints of the past and subjected long

held beliefs to open challenge to see the first attempts to take

our destiny within our hands. We did this by calculating the

probability of certain events in order to find the risk behind

certain actions. From then until today, the story of risk has been

marked by persistent tension between those who assert that

the best decisions are based on quantification and numbers,

determined by the patterns of the past, and those who base

their decisions on more subjective degrees of belief about the

uncertain future.

DEFINITIONS
Here is how NIST defines Risk, Information Security

Risk, and Risk assessment in its Guide for Conducting Risk

Assessment Sept 2012.

129

P C I

D S S

Risk is a measure of the extent to which an entity is threatened

by a potential circumstance or event, and is typically a function

of: the adverse impacts that would arise if the circumstance or

event occurs; and the likelihood of occurrence.

Information security risks are those risks that arise from the

loss of confidentiality, integrity, or availability of information or

information systems and reflect the potential adverse impacts

to organizational operations, organizational assets, individuals,

other organizations, and the Nation.

Risk assessment is the process of identifying, estimating, and

prioritizing information security risks. Assessing risk requires

the careful analysis of threat and vulnerability information to

determine the extent to which circumstances or events could

adversely impact an organization and the likelihood that such

circumstances or events will occur.

Let me illustrate this notion by sharing with you what

the scientist who developed the rocket that launched the first

Apollo mission to the moon said: You want a valve that doesnt
leak and you try everything possible to develop one. But the real

world provides you with a leaky valve. You have to determine how
much leaking you can then tolerate. Without a command of risk
assessment, engineers could never have designed the great

bridges that span our widest rivers, homes would still be heated

D i di e r

G oda rt

130

by fireplaces, electric power utilities would not exist, no airplane

would fly and space travel would be just a dream.

T H E I M P O R TA N C E O F T I M E
Risk and time are opposite sides of the same coin, for if there

were no tomorrow there would be no risk. Time transforms

risk, and the nature of risk is shaped by the time horizon: the
future is the playing field.

Periodic review and monitoring of risk assessments allows

organizations to keep up to date with business changes and

provides a mechanism to evaluate those changes against

the evolving threat landscape, emerging trends, and new
technologies along the timeline.

G U I D E L I N E S & M E T H O D O LO G I E S
A number of risk assessment guidelines and methodologies

in the context of IT and Security are available on the

field including:

The ISO Risk assessment Guideline - 27005

NIST Guide for conducting Risk assessment Sept
2012

131

P C I

D S S

 The Factor Analysis of Information Risk (FAIR)

The Australian/New Zealand Standard AS/NZS 4360
The french Guideline MEHARI
The

Operationally

Critical

Threat, Asset, and

Vulnerability Evaluation - OCTAVE

The PCI DSS Risk Assessment Guidelines

C O R E AC T I V I T I E S
In the context of PCI, organizations are free to select any

of those methodologies or establish their own as long as it

incorporates the following core activities:

Definition of the purpose of the risk assessment in terms

of the information that the assessment is intended to

produce and the decisions the assessment is intended
to support.

Definition of the risk assessment in terms of

organizational applicability, time frame supported, and
architectural/technology considerations.

Determination of specific assumptions and constraints

under which the risk assessment is conducted.

D i di e r

G oda rt

132

 Identification of critical cyber assets supporting

business operations. A cyber asset could: network
components, servers, applications & software, data and
individuals. In the context of PCI, cyber assets are any

system component used to store, process or transmit

cardholder data.

Identification of the threat events to those assets.

A threat event is any circumstance or event with the
potential to adversely impact business operations and

assets, individuals, other organizations, or the nation

through an information system via unauthorized access,

destruction, disclosure, or modification of information,
and/or denial of service.

Identification of the vulnerabilities. A vulnerability is

a weakness in an information system, system security

procedures, internal controls, or implementation that
could be exploited by a threat source. A threat source

is characterized as: the intent and method targeted at

the exploitation of a vulnerability; or a situation and
method that may accidentally exploit a vulnerability.

Evaluation of the likelihood. The likelihood of

occurrence is a weighted risk factor based on an analysis

of the probability that a given threat event is capable of

exploiting a given vulnerability (or set of vulnerabilities).

133

P C I

D S S

 Evaluation of the impact. The level of impact from

a threat event is the magnitude of harm that can

be expected to result from the consequences of

unauthorized disclosure of information, unauthorized

modification of information, unauthorized destruction

of information, or loss of information or information

system availability. Examples of impact are: damage

to image or reputation; financial loss; inability to

successfully execute a specific mission/business; loss

of current or future mission/business effectiveness due

to the loss of data confidentiality; loss of confidence

in critical information due to loss of data or system
integrity; or unavailability or degradation of information
or information systems.

Determination of the Risk level. The risk level is a

function of the likelihood of a threat events occurrence

and potential adverse impact should the event occur.

Determination of the Risk tolerance. Organizations

determine risk that are acceptable or residual risk and

those that are not acceptable.

Development of a risk mitigation plan to address

unacceptable identified risks.

Communication of risk assessment results to designated

organizational stakeholders to support risk acceptation

and mitigation plan.

D i di e r

G oda rt

134

 Maintenance of the assessment. Review and Update

existing risk assessment using the results from ongoing

monitoring of risk factors.

135

P C I

D S S

24
PCICO STRENGTHENS THE
SCOPING RULES

HIS PAGE SUPPLEMENTS our newsletter

#7 - Defining the Scope

of the PCI assessment

In terms of scope definition

here is what PCI says:

PCI DSS requirements apply to all system components,

defined as any network component, server, or application that

is included in or connected to the cardholder data environment

(CDE). The scope of a PCI DSS assessment could be

reduced using adequate network segmentation but what is an

adequate segmentation?

137

P C I

D S S

A D E Q UAT E S E G M E N TAT I O N
PCI SSC recently clarified that to be considered, adequate,

segmentation must isolate systems that store, process, or transmit

cardholder data from those that do not in such a way that the
latest ones (out of scope systems), even if compromised, cannot
impact the security of the former ones (in scope systems).

In other words, if a system component can impact in any way

and at any level the security of the CDE, this system component
must be considered in scope for the PCI DSS assessment.

PCI SSC states that restricting access by IP or port, (through

a firewall for instance) does not automatically remove systems/

networks from scope since there is still connectivity.

In such conditions is the physical separation of network

environment not the only certitude of an adequate segmentation?

As usually PCI SSC gives the last word to the QSA who should
confirm that a system cannot impact the security of the CDE
before determining it is out of scope.

This clarification of the term, adequate segmentation,

brings another question: How does one validate that a system

cannot impact the security? Hopefully, PCI SSC is working on

additional guidance.

D i di e r

G oda rt

138

Is encrypted data considered out of scope?

PCI SSC clarified that by default encrypted cardholder

data is in scope for PCI DSS since it can be decrypted with

the right cryptographic key. Even storage of encrypted data

without access to the decryption keys does not automatically

result in the data, or the merchant, being out of scope. So in

which conditions can an entity remove their encrypted data

from the scope?

According to PCI SSC encrypted data may be deemed out

of scope for a particular entity if, and only if, it is validated that
the entity does not have the ability to decrypt it, meaning:

that the entity does not have cryptographic keys anywhere

in their environment and that the entitys systems, processes,

or personnel do not have access to the environment where

139

P C I

D S S

decryption keys are located and do not have the ability to

retrieve decryption keys. Now PCI SSC has to clarified what

are the validation mechanisms.

All applicable PCI DSS requirements apply if encrypted

cardholder data is stored on a system or media that also

contains the decryption key or if encrypted data is stored in the

same environment as the decryption key or if encrypted data is

accessible to an entity that also has access to the decryption key.

In all circumstances, systems performing encryption and/or

decryption of cardholder data, and any systems performing key

management functions, are always considered in scope.

D i di e r

G oda rt

140

25
A NEW STANDARD IS BORN.

FTER HAVING COAUTHORED

the first

version of the PCI DSS

and having designed and led the

ASV

certification

program

on

behalf of PCIco, Ive been assigned

with another critical mission for a

secret department at Mastercard,

the Global Vendor Certification

Program. My role was to write a set of logical security require-

ments to minimize the risks pertaining to the personalization

of credit cards.

That was back in 2009. Its interesting to see that nowadays

these specs follow the same destiny as the Data Security

Standard (DSS) and the PIN Transaction Security (PTS)

standard. The Payment Brands, mostly VISA and MasterCard,

141

P C I

D S S

eventually decided to combine their sources under the umbrella

of PCI SSC. Audit processes and compliance management will
stay under the supervision of each Payment Brand.

THE CONTEXT
As you can imagine, your cards do not appear in your wallet

by the manifestation of a Holy spirit (although that would be

cool!!). There are organizations out there whose business and
expertise is to manufacture and personalize magnetic-stripe
and chip cards on behalf of Issuing banks.

Imagine hundreds or thousands of cards and associated

details located on such sites and you will have a good sense of
the associated risks. In term of data the standards focus on the
protection of:

Secret data: All symmetric (e.g., Triple DES, AES) and

private asymmetric keys (e.g., RSA)except keys used only

for encryption of cardholder dataare secret data and must be

managed in accordance with the key management secret data

(8.0) section of this document. Examples:
Chip personalization keys
PIN Key and the key used to generate CVVs, CVCs

D i di e r

G oda rt

142

Confidential data: Cardholder data and keys used to encrypt

cardholder data are confidential data and must be managed

in accordance with Key management confidential data (9.0)

section of this document
Examples:
PAN, expiry, service code, cardholder name
SSL keys
Vendor evidence preserving data
Such vendors are therefore subjected to stringent physical

and logical security rules which are validated yearly. Non

compliance to these rules has an heavy impact on the business:

Removal from the list of approved card vendors used by the

Issuers. I had several opportunities to audit such premises. Quite

impressive in fact, the processes, the machines and the security.

T H E S TA N DA R D S
Logical standard
This standard describes the logical security requirements

required of vendors that personalize cards or manipulate card

data during the preparation of payment system cards. All systems
and business processes associated with card personalization

143

P C I

D S S

must comply with these requirements. The logical standard is

quite comprehensive (and more demanding than PCI DSS) the

main difference resides in a heavy section on Key management

(section #8 and #9). There are 9 sections, 46 subsections and

about 420 requirements.

You will find here under an overview of the structure of

this standard.

2. Roles and Responsibilities

2.1 Information Security Personnel
2.2 Assignment of Security Duties
3. Security Policy and Procedures
3.1 Information Security Policy
3.2 Security Procedures
3.3 Incident Response Plans and Forensics Data Security
4. Data Security
4.1 Classification
4.2 Encryption
4.3 Access to Cardholder Data
4.4 Transmission of Cardholder Data

D i di e r

G oda rt

144

4.5 Retention and Deletion of Cardholder Data

4.6 Media Handling
4.7 Contactless Personalization Network Security
5. Network Security
5.1 Personalization Network
5.2 General Requirements
5.3 Network Devices
5.4 Firewalls
5.5 Remote Access
5.6 Wireless Networks
5.7 Security Testing and Monitoring
6. System Security
6.1 General
6.2 Change Management
6.3 Configuration and Patch Management
6.4 Audit Logs
6.5 Software Design and Development
6.6 Software implementation

145

P C I

D S S

7. User Management and System Access Control

7.1 User Management
7.2 Password Control
7.3 Session Locking
7.4 Account Locking
8. Key Management: Secret Data
8.1 General Principles
8.2 Symmetric Keys
8.3 Asymmetric Keys
8.4 Key Management Security Administration
8.4.1 General Requirements
8.4.2 Key Manager
8.4.3 Key Custodians
8.4.4 Key Management Device PINS
8.5 Key Generation
8.6 Key Distribution
8.7 Key Loading
8.8 Key Storage

D i di e r

G oda rt

146

8.9 Key Usage

8.10 KeyBackup/Recovery.
8.11 Key Destruction
8.12 Key Management Audit Trail
8.13 Key Compromise
8.14 Key Management Security Hardware
9. Key Management: Confidential Data
10. PIN Distribution via Electronic Methods

P H Y S I CA L S TA N DA R D
The Physical Standard manual is a comprehensive source

of information for approved card vendors (manufacturers,

personalizers,

pre-personalizers,

chip

embedders,

data

preparation vendors and fulfillment vendors). The contents

of this manual specify the physical security requirements and

procedures that vendors must follow before, during, and after

the following processes:

Card manufacturing
Magnetic-stripe card encoding and embossing
Card personalization

147

P C I

D S S

 Chip initializing or pre-personalization

Chip embedding
Chip personalization
Card storing
Shipping
Mailing

D i di e r

G oda rt

148

26
PCIP IS IT WORTH IT?

N ADDITION TO, ASV, QSA, P2PE QSA, ISA,PFI

and QIR, PCI SSC proposed their PCIP (Payment Card

Industry Professionals) certification.

WHY?
Firstly, to answer a valid concern from the QSA and ISA

employees. QSA and ISA certifications are not assigned to

individuals but to the couple (company, employee). Therefore

the QSA/ISA employee status is lost whenever the individuals
leave their employers. This fact is poorly known among the

industry where job postings refer too often to looking for a

certified QSA. There is no individual certified QSA nor ISA.

According to the Council, PCIP offers an industry credential

that travels along with you and your career. This doesnt change
the fact that independently of their PCIP status, former QSAs

149

P C I

D S S

and ISAs have to go through the certification process when

hired by another company.

Secondly, organizations subjected to compliance are

supported by security professionals along their PCI journey

(training, gap analysis, specific advices, solution integration,

compliance management, pre-audit, and so on). In this

context, a certification could provide a kind of assurance of

their level of understanding of the PCI matter.

W H AT I S T H E V I E W O F P C I c o ?
The PCIP sale pitch lists the following advantages to

become certified.

Be part of the PCIP community

Get an individual credential recognized by the industry
Get your PCI knowledge recognized
Support your organization or
compliance efforts

customers ongoing

Enhance your credibility

Get competitive advantage
Get public recognition of your professional achievement

D i di e r

G oda rt

150

Clearly PCIco wants to create a PCIP community by

attracting individuals working within the PCI sphere: entry-

level and seasoned security professionals, managers, executives,

independent consultants and eligible QSA and ISA individuals.
A huge number of certificates in perspective.

W H AT I S T H E V I E W O F T H E S E C U R I T Y
COMMUNITY?
People who do not have a QSA or ISA certification, see

this as an opportunity. Here is what Don Turnblade, PCIP

certified, says about this certification: In effect, the PCIP is useful

for showing an approved level of understanding of the PCI DSS
standards. Unless I took the QSA training from a QSA certified

company, it would not allow me to audit or attest to PCI DSS

compliance. However, it would make me a credible advisor for audit

preparedness/pre-audit solutions advising and does not need to be

attached to a QSA certified company as a consultant. Also, a PCI

DSS QSA company could be quickly assured that if I would work

with them, I have a credible level of PCI DSS QSA understanding.

The only concern with it is that it is relatively unknown but we

could trust the Council to push it through the PCI community.

Probably within five years from now, PCIP would be required
for any PCI job such as CISSP.

151

P C I

D S S

However QSAs and ISAs who may apply for the PCIP

credential and qualification without completing PCIP-specific

exams or training, dont really see any added value in this

certification as a proof of their knowledge and experience.

H OW TO G E T Q UA L I F I E D ?
The qualification process is straightforward.
You apply (Submit online application). Make sure to

possess a base level of knowledge and awareness of information

technology, network security, network architecture, and payment

industry. As part of the application process candidates must

submit their resume or CV evidencing at least 2 years of work
experience in an IT or IT-related role. This is to ensure they

have the knowledge and experience to understand the training.

You pay the non-refundable fee (Application fee + training

fee + Exam fee). This fee could range from $790 to $ 3635

depending on wether you take the training or not and wether or

not you work for a participating organization which is strange
for a individual certification!

You complete the on-line course (This is optional).

Candidates has 30 days access to the online course. Course

content includes:

D i di e r

G oda rt

152

1. Principles of PCI DSS, PA-DSS, PTS, P2PE, and PIN

Security

2. Understanding PCI DSS requirements and intent

3. Overview of basic payment industry terminology
4. Appropriate uses of compensating controls
5. How and when to use Self-Assessment Questionnaires
(SAQs)

6. Recognizing how new technologies affect the PCI

(P2PE, tokenization, mobile, cloud)

7. PCI Code of Professional Responsibility

8. Case study application
9. Resources available to stay current
You take the on-site exam (this is not optional ), a computer-

based PCIP exam at a PearsonVUE test center. The Pearson

VUE Testing Networks includes over 5,000 testing centers in

over 165 countries. The test is 90 minutes in length with 60

questions. Most people complete it in 40 to 45. The passing

score is 75%. Suggestion: For planning purposes, assume the

test needs an average of one answer per minute, skip problem

questions if a minute worth of reasoning did not help and go

back to them with the final 30 minutes for best guess selections.
Here is what some people say about the test.

153

P C I

D S S

If you have a solid understanding of ALL the sections in the

DSS and review some of the material regarding P2P encryption

and virtualization, etc, you should have no problem passing the test.
Its a fairly easy test for someone who is familiar with the

requirements. I would add that you should have familiarity with

the difference between certain networking protocols such as WEP

vs WPA (i.e. which is secure and which is not), but that is covered
in the requirements as well. What is not necessarily covered in the

requirements is that you should also be familiar with payment card

processing, such as authorization, completion and settlement and

at what points the consumer, merchant, acquirer and bank process

the transaction.

I was able to complete it with a passing grade in one pass in 45

minutes. Eliminating two options out of four was rather easy to do.
My own sense was that 3 to 6 questions were quick kills for every

one question requiring elimination skills to make a best answer. A

small list of questions, no more than 6 total had me off balance. It

would not be wise to assume a trivial reading of the standard would

be sufficient preparation.

The exam is similar to the recertification exams that a PCI DSS

QSA would take each year. I modeled my study for that exam from
such training materials, and this worked well.

D i di e r

G oda rt

154

R E Q UA L I F I CAT I O N
PCIPs must re-qualify every two years in order to continue

to maintain their status and be listed on the PCI website.

155

P C I

D S S

27
SHOULD I DISABLE MY
PROTECTION SYSTEM FOR
ASV SCANS?

N THE CONTEXT of
intrusion detection and pre-

vention, PCI DSS requires

implementation/configuration
of Firewalls (Req 1), Anti-virus

(Req 5) and Intrusion detec-

tion systems (IDS) (Req 11.4).

Optionally, organizations are invited to consider the use of

Intrusion Prevention Systems (IPS) in place or in addition

to IDS (Req 11.4) as well as Web Application Firewalls
(Req 6.6).

The first group of required protection systems is known as

static systems. They do not dynamically modify their behavior.

They maintain consistent, static behavior based on rules or

157

P C I

D S S

signatures. One may compare them to the egyptian sphinx.

Impressive, proud, but indifferent to the context.
Example of static protection systems:
Intrusion detection systems (IDS) that log events,
track context or have a multifaceted approach to

detecting attacks, but action is limited to alerting (there

is no intervention)

Firewalls that are configured to block certain ports all

the time but keep other ports open all the time

VPN servers that reject entities with invalid credentials

but permit entities with valid credentials

Antivirus that blocks, quarantines, or deletes all known

malware based on a database of defined signatures but

permits all other perceived clean files

Logging/monitoring systems, event and log aggregators,

reporting engines.

The optional IPS and Web Application Firewalls are

considered to be active systems. They dynamically modify their

behavior based on information gathered traffic patterns.

D i di e r

G oda rt

158

One may compare them to profilers scrutinizing the crowd.

Other examples of active protection systems:

Firewalls that shun/block an IP address upon detection

of a port scan from that IP address

Next generation firewalls that shun/block IP address

ranges based on previous network traffic patterns

Spam filters that blacklist a sending IP address based

on certain previous SMTP commands originating from

that address.

Anti-virus that uses patterns/behavior recognition

W H AT I M PAC T I S T H E R E O N Q UA R T E R LY
S CA N S ?
11.2.2 requires quarterly external vulnerability scans by an

Approved Scanning Vendor (ASV). The intent is to identify

all potential vulnerabilities from the hacker perspective. There

159

P C I

D S S

is however a huge distinction between ASV scans and real

attacks. The objective of real attackers is to intrude networks

without being noticed. They take their time and use various
stealth techniques to counter static protection systems and

evade active mechanisms. The objective of the ASV scans is

more humble: Identify the majority of potential issues in the

shortest, and therefore most economical, time window. They
cant afford the use of stealth techniques and dont bypass static

protection systems. Like an elephant in a porcelain shop they

awake all active mechanisms along their route, with an obvious
impact on the accuracy of their reports.

To ensure a clear scanning path, PCI SSC asks organizations

to ensure that their whatever static or active protection devices

do not interfere with the ASV scans. More specifically they are
required to configure intrusion detection systems (IDSs) and

intrusion prevention systems (IPSs) so they do not interfere

with the ASVs scan. This obligation generates quite some
discussions between ASVs and their customers. In an attempt

to calm down the game, PCI SSC brought them around the
table in order to find a way to perform quarterly scans that do
not unnecessarily expose the scan customers network but also
do not limit the final results of the scans.

D i di e r

G oda rt

160

RULES FOR ASV S AND THEIR

C U S TO M E R S
The ASV Program Guide prescribes rules for ASVs and

organizations in regards to blocked or filtered scans making the

distinction between static and active protection systems.

A S V O B L I G AT I O N S

ASVs must continue validate that scans have not been

blocked or filtered but this time only by active protection system.

Filtering or blocking actions by static protection systems should
be discarded.

Would a scan be filtered or blocked through the action of an

active device, ASVs are required to fail the scans, report the scan
as inconclusive and clearly describe the conditions resulting
in an inconclusive scan under Exceptions, False Positives, or

Compensating Controls. Detection of such filtering/blocking

events its kind of hard. There are no clear defined techniques. It

depends on the type of devices in place and their configurations.

So without clarification from PCI SSC one could expect more
complaints and discussions.

161

P C I

D S S

O R G A N I Z AT I O N S O B L I G AT I O N S
Organizations subjected to compliance must continue

to ensure that their protection devices do not interfere with

the ASV scan but only for active protection devices. Static

protection systems or static rules would not have to be changed.

Of course, applied changes would only be required for the
duration of the scan. PCI SSC encourages organizations to
work with the ASV to:

Determine proper temporary configuration changes to

prevent or remove interference during a scan.

Agree on a time for the scan window each quarter to

minimize how long changed configurations are in place.

Conduct the scan during a maintenance window under

the scan customers standard change control processes,

with full monitoring during the ASV scan.

Configure the active protection systems to monitor and

log, but not to act against, the originating IP address(es)
of the ASV.

Reapply the standard secure configurations as soon as

the scan is complete.

In case of inconsistent scans (failed) due to blocked or

filtered traffic, the scan customer may work with the ASV

D i di e r

G oda rt

162

to implement one or more of the following options until a

complete scan is achieved.

Scan customer provides the ASV with sufficient written

supporting evidence to support their assertion that the

scan wasnt actually blocked. Scan customer and ASV

work together to resolve scanning issues and schedule

additional scan(s), as necessary, in order for the scan
to complete.

Scan customer and ASV agree on a method that allows

the ASV scan solution to complete a scan without

interference. For example, through implementation of a

secure connection between the ASV and scan customer

(such as an IPsec VPN tunnel), or installation of ASV

scan solution (such as an appliance or agent) at the scan
customers site.

163

P C I

D S S

28
THE PCI LIBRARY - WHAT
DOCS ARE REQUIRED FOR
COMPLIANCE?

OMPLIANCE
PROGRAMS
ARE heavily based

on documentation and PCI

does not make an exception.

Technical and non-technical

documents are a major part of the PCI journey and certainly

of the compliance audit. Documents (technical description,

diagram, policies, procedures, standards, audit trails, scan
reports, pen test report, risk analysis report, test report,) are
the auditors food.

Therefore, beside the technical specificities, no one should

neglect or underestimate the effort and time necessary to set

165

P C I

D S S

up and maintain their PCI library. Its a huge part of any

PCI project.

If documentation is so important, why is there no official list

of required documents on the PCI Standard Web site? Answer:

It would be too easy! Organizations have to make their own
interpretation of the requirements in order to uncover the
associated list of documents.

To solve this gap, I decided to complete this exercise once

for all. Browse my PCI Library on my PCI-GO web site for

this list of document.

D i di e r

G oda rt

166

29
DO ALL PCI DSS
REQUIREMENTS APPLY?

F R E Q U E N T LYA S S I S T
MEDIUM SIZE organi-

zations to align with PCI.

The gap analysis and design

phase raised a number of concerns from their side. All of the

concerns started as something

similar to: Why do we need this? It induces more risks.

Implementing protection mechanisms without considering

their added values and impact on the environment and the

business does not make sense. Security is a risk mitigation and

management discipline and all security responsible individuals
know perfectly well that the right security balance for their

environment is somewhere between the complete ignorance of

a risk and its total protection.

167

P C I

D S S

Security could be considered as layers of clothes one could

decide to slip on or not according to the environment and their

sensitivity. Compliance however must be seen as the uniform
that MUST be slipped on independently of our environment
and our own sensitivity.

Note: The PCI Council defined 9 types associated with the

way organizations handle and process cardholder data (see

newsletter #5). If they are used to determine which sections of

the PCI bible are applicable all rules within these sections are
applicable whatever the entity environment, nature and size.
This fact is enforced by the Council in such terms:
Decisions about applicability of PCI DSS requirements are not

to be based on an entitys perception of the risk of not implementing

the requirement. Organizations may not choose which PCI DSS

requirements they want to implement, and risk assessments cannot

be used as a means of avoiding or bypassing applicable PCI
DSS requirements.

This makes us think as Risk analysis is one of the PCI-

DSS requirement. Let me be clear, I am not saying that risk

analysis is not important, it is definitely a key element of

a security program. Im just wondering the value of such a

requirement if it could not be used to justify applicability of a

requirement. The only risk assessment that makes sense within

D i di e r

G oda rt

168

the context of PCI compliance is the risk of non compliance.

Can my organization afford to not comply?

Practically, its never white or black. Organizations could

discuss with their acquiring bank potential waivers or an

implementation roadmap of several years. Service providers do
not have such opportunity.

T H E P E N T E S T CA S E
One of the points argued by this organization was the need

for an internal pen test required under PCI 11.3. This is an

excellent case study for

Why do we need this? It

induces more risks. Here

are highlights extracted

from an opinion poll on
this topic:

A pen test is a validation

of the security controls in place, proof that the security

design choices that were made are sound

A large number of companies were hacked out of

business by relying entirely on the vulnerability scans

to report the security of their external applications

and infrastructure.

169

P C I

D S S

 Although its an expensive burden, its absolutely

necessary to have penetration tests done. At least an
external one.

There should be very little risk introduced by pen test

activity unless the penetration testing company is very

sloppy or incompetent. Unfortunately in the context of

PCI this is the case. There are far too many shoddy pen
testers who have brought down entire networks and/

or denied services to critical infrastructure due to their

pentesting/security knowledge. There is no list of

certified pen test companies organizations could refer

to. According to the Council any qualified individual
could perform this job. However nothing is said on

what Qualified means and how this qualification

should be assessed. Furthermore QSAs have very little

ability to judge or reject their work.

In the current context, (PCI rules), running a pen test just for

the purpose of checking a box doesnt really bring any value. On

the contrary it generates more risks than it helps to minimize;

Pen tests are an expensive burden that organizations could
attempt to minimize through the selection of cheap sloppy

testers with the associated risks. Pen tests are however a serious

and necessary activity for the validation of the security controls

and design requiring a careful selection of professional testers.

As a minimum: the rules of engagement and experience of the

D i di e r

G oda rt

170

individual testers must be scrutinized. Additionally whenever

possible organizations should allocate an internal resource

to oversee the pen test and request the pen test be stopped if
something goes wrong.

There is no chance to pass PCI Compliance without running

an external pen test. Its a MUST. However QSAs are more

divided about the requirement for internal testing especially

when the case is clearly justified and documented. Examples:

No internal threats, high risk of business disruption, isolated
segment, no Web application.

Alternatively you may want to test the idea suggested by the

above picture: Oh Yes Mr. QSA, I tested several pens this year
and they are all working perfectly!

171

P C I

D S S

30
TRAININGS YOUR
ORGANIZATION MUST
DELIVER TO COMPLY
WITH PCI DSS

CI-DSS REQUIRES
ORGANIZATIONS
subjected to compli-

ance to deliver three specific

trainings, namely: Security

Awareness, Secure Coding

and Incident response. This

newsletter describes what you should know about them in

terms of What, Who and How.

173

P C I

D S S

S E C U R I T Y AWA R E N E S S
Associated PCI DSS requirement: 12.6
Audience: Any individual having access to data or system

components part of the PCI scope.

Objectives: In all domains, awareness of the risks and

available safeguards are the first line of defense. According to

NIST Special Publication 800-16, awareness is not training.

The purpose of awareness presentations is simply to focus
attention on security. Awareness relies on reaching broad

audiences with attractive packaging techniques. Training is

more formal, having a goal of building knowledge and skills to

facilitate the job performance. Having said that the objective of

a security awareness is to focus attention of individuals on the

threats they could potentially face in their day to day job, their

critical position and vulnerabilities within the security chain,

get their deliberate collaboration, make them understand the

security rules (policies and procedures) and the importance of

applying and respecting them in their day to day activities.
Associated PCI DSS Controls:
Organizations must Implement a formal security
awareness program. The program must be endorsed by
the senior management, be documented and address at

D i di e r

G oda rt

174

least the following topics: Audience, content, channel

of communication and supporting materials (multiple

methods of communicating awareness and educating

personnel is required), execution plan, and measures
of quality.

Organizations must ensure that personnel attend

awareness training upon hire and at least annually.

All personnel must acknowledge, in writing or

electronically, at least annually that they have read and

understand the information security policy.

Associated

QSA

Validation

processes:

Compliance

with these controls is validated through the review of the

documentation (Security Awareness Program and associated

procedures), acknowledgment forms and personnel interviews.

Organizations have carte-blanche is what concerns

the content of this training and the delivery form (on-site,

Webcast,).

Note: My personal opinion is that the majority of security

awareness sessions are quite boring! They dont talk the users
language and dont address THEIR concerns. Its then not a

surprise that the majority of users behaves gingerly when called

to duty. The security awareness sessions talk about security and

rules, a subject that, lets be honest here, bother the majority

175

P C I

D S S

of the people. In such conditions, what is the best way to get

them engaged, retaining the information and more importantly

get them willingly to change their mind, behavior and applying

the rules? For me, the best way is to make sure that have they
have fun, enjoying the moment, spending a good times and

therefore the main driver of this session should not be the

content but the way we are communicating it. When Im giving
such sessions I make sure to apply the following quotes :

If you cant explain a concept to a six years old child, its

because you dont understand and master it yourself
Alfred Einstein
Nothing is definitely lost while there is a good story to tell
Alexandro Baricco.
You cannot teach a man anything. You can only help him
discover it within himself.
Galileo Galilei

So use simple concepts, simple words that a six years old

child would understand. Make humor your strengths and tell

a lot of exciting stories. Further reading: Security Awareness

Guidance on the PCI Security Standard web site.

D i di e r

G oda rt

176

SECURE CODING
Associated Requirement: 6.5 - Develop applications based

on secure coding guidelines.

Audience: Developers of custom application used within the

PCI scope.

Objectives: Ensure that developers understand the threats

when it comes to building secure applications and are aware of

common application security threats in applications today.
Associated PCI-DSS Controls:

Organizations software development processes must

incorporate training in secure coding techniques

for developers based on industry best practices and

guidance. These trainings must be applicable to the

particular technology in their environment. This

control applies to any developers of (Web or no Web

related applications) applications. There are however
no requirement in terms of renewal of this training or
follow up such as for the security awareness.

Associated QSA Validation processes: Compliance with

this control is validated by:

177

P C I

D S S

 Verifying that the software development processes

require

training

in

secure

coding

techniques

for developers, based on industry best practices

and guidance.

Identifying the industry best practices and guidance

that training is based on.

Interviewing developers to test their knowledge in

secure development techniques.

Here as well we have carte-blanche in what concerns the

content and the delivery form (on-site, Webcast, self-study,).

The problem that many businesses are facing, however, is,
What is a Secure Coding training and where can I get it?
The essence of training is to allow error without consequence.
Orson Scott Card, Enders Game

Secure coding is the practice of writing programs that

are resistant to attack by malicious or mischievous people

or programs. Most secure coding trainings that you can find

within the context of PCI are based on OWASP Top 10 guide

but dont get it wrong as this control does not limit itself to

Web application. The training must be aligned with the

development technology used internally (C, C++, Java, perl,

php,). It must cover the most common programming flaws

D i di e r

G oda rt

178

that affect that technology as well as provide secure solutions to

coding problems.

INCIDENT RESPONSE
Associated requirements: 12.10.4 - Provide appropriate

training to staff with security breach response responsibilities.

Audience: Staff who are responsible for managing

incident response.

Objectives: Ensures they are properly trained on how your

organization should handle incidents.

Associated PCI-DSS Controls:

Security policies must incorporate a statement requiring

that staff with responsibilities for security breach
response are periodically trained.

Security incident response procedures must indicate

what need to be done to manage and respond

to incidents.

The Incident response plan/procedure must be tested

annually. This could consist in the training itself !

179

P C I

D S S

Associated QSA Validation process: Compliance with this

control is validated by:

Verifying that the incident response plan includes:

Roles, responsibilities, and communication strategies,

specific incident response procedures, business recovery
and continuity procedures

Interviewing personnel to confirm that the incident

response plan is tested according to the defined

procedures

Reviewing document requiring that staff with security

breach responsibilities are periodically trained.

Interviewing personnel to test their level of knowledge

of the incident response procedure.

The control doesnt say anything about the content, the

delivery form and periodicity of this training. However as the

incident response plan is specific to each organization, one

could assume that the training material would consist in the

incident response procedures and the training would consist in

the Incident response plan test.

D i di e r

G oda rt

180

A F T E R WO R D S
Strangely enough, one could have expected that the PCI-

DSS training catalog be more voluminous. Indeed nothing is

required for individuals with system and security administrative,

operational or managing roles such as system administrators,

network administrators, security operators, vulnerability
managers, risk manager, and even CISO. Probably a forgivable

oversight from the Council that could be filled in a near future!

To close this newsletter let me quote Veronica Roth in

Insurgent - No matter how long you train someone to be brave,

you never know if they are or not until something real happens.

181

P C I

D S S

31
PCI DSS
CRYPTO-FRAMEWORK

TRONG CRYPTOGRAPHY IS referred to by PCI

DSS through the following requirements:

2.3 - Encrypt all non-console administrative access

using strong cryptography. Use technologies such as SSH,

VPN, or TLS for web- based management and other nonconsole administrative access.

183

P C I

D S S

4.1 - Use strong cryptography and security protocols (for

example, TLS, IPSEC, SSH, etc.) to safeguard sensitive

cardholder data during transmission over open, public networks.

Cryptographic solutions are also suggested as a potential

solution for: 3.4 - Render PAN unreadable anywhere it is

stored (including on portable digital media, backup media, and
in logs)

W H AT I S M E A N T B Y S T R O N G
C RY P TO G R A P H Y ?
Cryptography is the art of

transforming information so

that it can not be understood

by unauthorized parties. Of
course, this transformation

is meant to be resistant to
attacks so that you can have

fair assurance that your secrets

are safe... at least for a specific

period of time. This is what is

meant by Strong Cryptography. It consists of three parts:

D i di e r

G oda rt

184

 The use of industry-tested and accepted algorithms

(transforming machines), along with strong key lengths

The presence of resistant protection mechanisms

limiting access to the keys

The use of proper key management processes

and procedures.

Organizations subjected to DSS must prove compliance

with these three points.

W H AT I S M E A N T B Y P R O P E R K E Y
M A N AG E M E N T A N D K E Y P R OT E C T I O N ?
This is covered by:
3.5 Document and implement procedures to protect

keys used to secure stored cardholder data against disclosure

and misuse.

3.6 Fully document and implement all key-management

processes and procedures for cryptographic keys used for

encryption of cardholder data.

This last one further includes:

185

P C I

D S S

3.6.1 Generation of strong cryptographic keys according to

best practices.

3.6.2 Secure cryptographic key distribution

3.6.3 Secure cryptographic key storage. PCI doesnt

specifically require the use of hardware secured module for this

purpose. However their use would greatly facilitate validation
from your auditor.

3.6.4 Periodic cryptographic key changes.

3.6.5 Retirement or replacement of keys as deemed necessary

when the integrity of the key has been weakened or keys are
suspected of being compromised

3.6.6 Split knowledge and establishment of dual control of

cryptographic keys.
3.6.7

Prevention

cryptographic keys.

D i di e r

G oda rt

of

unauthorized

186

substitution

of

3.6.8 Requirement for cryptographic key custodians to

sign a form stating that they understand and accept their keycustodian responsibilities.

W H AT I S A C RY P TO - F R A M E WO R K ?
A crypto-framework is a set of rules, principles and tools

designed to support the management and protection of

cryptographic keys within an organization. Its purpose is to

improve the efficiency, quality, robustness, and traceability of
the processes involved in the management and protection of
crypto keys. It provides a structure and a frame, while it draws

the limits of the crypto playground. Every crypto service used

within the organization would benefit from this.

WHY IS IT NEEDED?
PCI DSS does not explicitly mention it; however reading

between the lines there is no doubt that a framework would

greatly facilitate compliance with the keys protection and keys
management requirements above.

187

P C I

D S S

W H AT S H O U L D B E PA R T O F A
C RY P TO - F R A M E WO R K ?
A

crypto-framework

following components:

should

at

least

include

the

Procedures: Set of procedures defining the high level

processes and detailed technical procedures for the management

of the keys. These should answer to the following questions:

What must be done, by who, when and How must it be
done and eventually how to record execution of the tasks. As

mentioned above processes and procedures should exists for

the following crypto activities: Key Generation, distribution,

usage, replacement, archiving, Destruction,Incident response
for key compromised.

Roles and responsibilities for whomever is assigned to the

cryptographic operations, including key custodians.

Standards: Key Classification, approved cryptographic keys,

protocols, and methods; Standards associated with various

technology in use (i.e TLS, IPSEC, Bit Locker, SSH,)

Key inventory: Depending on the number of keys a simple

spreadsheet, or a more complex key management tool would be

needed for the maintenance of the inventory.

D i di e r

G oda rt

188

Key metadata: Attributes that identifies a particular key

and specifies the appropriate usage and management of that

key. Example of attributes are: Key identifier; Key location, Key
owner responsible for the use and management of the key; Set

of algorithms that can be used with the key; Key usage; Key

length; Key custodians who have access to the key; Key validity
period also called crypto period;

State machines: The list of states that a key could take

through is life: Generated, Distributed, Used, Retired/Replaced,

Revoked, Archived, Destroyed. As well as the condition of
transition between each of these sates.

Network Diagram showing the location and classes of keys

within the infrastructure.

Key management logs (who did what and when)

Trainings: Introduction to Cryptography, Key management

training

W H AT A R E T H E M I N I M U M D O C U M E N T S
YO U S H O U L D H AV E R E A DY F O R YO U R
P C I AU D I T ?
If you dont opt for the crypto-framework approach, here are

the minimum documents you should have ready for your audit:

189

P C I

D S S

 Inventory of keys used within the PCI environment.

(Check our PCI Library for a Key inventory template)

Keys attributes with a minimum of the key length,

algorithms, crypto period, status, key custodians, and
location (Same remark as above)

List of Key Custodians having access to the keys (Same

remark as above)

Key custodians responsibility acknowledgement forms

Functional processes and technical procedures for the

generation, distribution, secure storage, protection,

replacement and compromised keys

D i di e r

G oda rt

190

32
MONEY FOR NOTHING

TARTING
THIS
NEWSLETTER with
two

famous

songs

in mind: Money by Pink

Floyd and Money for nothing by Dire Straits.

If I ask you to give me the most common PCI keywords that

come to mind, you will most probably answer: Security, Credit

Card, Compliance andCost.

MONEY is definitely a key argument both for the PCI

supporters and the PCI critics. The former emphasize the cost

for the organization in case of a breach while the latter underline

the associated cost of implementation and maintenance. In

both cases, PCI requires us to open our wallet.

191

P C I

D S S

T H E C O S T O F P C I I M P L E M E N TAT I O N
Implementing PCI is certainly not free even for a smallest

of the merchants. The cost of implementation encompasses the

following parts:

A. Initial scope and gap analysis: This includes the scope

determination and documentation, the gap analysis against the

bible, and the remediation action and cost plans.

B. Becoming compliant: This includes the cost associated to:

Acquisition and implementation of technology - network segregation, servers, firewalls, routers, tokenization technology (optional), Web application firewalls

(optional), Central log management, patch management, file integrity, encryption technology, access management, anti-virus technology.

The cleaning, sanitization of the environment:

Identification, cleaning, masking of PAN.

The secure operations: Audit log review, incident man-

agement, key management, patch management, user

management, following up with the communities

Specific periodic activities: external scanning (ASVs),

internal scanning, penetration testing, patching, wire-

D i di e r

G oda rt

192

less detection, code-review (optional), security awareness sessions, trainings

The alignment of policy, procedures and standards with

the PCI requirements

Physically securing the premises according to the

standard

The support structure: project management, communication & reporting

Compliance validation: On-site audit/self-assessment.

C. Maintenance cost Recurring annual cost to remain PCI

compliant: Quarterly scans, annual penetration test, annual

on-site audits or self-assessment, continuous monitoring of

logs and alerts, vulnerability managements, risk assessment,

PCI program management & reporting, review of policy, and
standards and procedures.

How large expense is depends on a number of factors;

The business type, number of transactions processed annually,

existing IT infrastructure, and credit/debit card processing and
storage practices. The following table provide an indication of
these expenses for each merchant level.

193

P C I

D S S

Level

Initial

Becoming

scope

compliant

Maintenance

Level1

$250,000

$550,000

$250,000

Level 3 & 4

$50,000

$81,000

$35,000

Level 2

$125,000

$260,000

$100,000

source: payplum http://www.payplum.com/#!pci-costs/c1ed1

T H E C O S T O F A B R E AC H
Direct cost
Here are the direct costs generally associated with a breach:
Forensics cost. Once an organization subjected to PCI

compliance is even suspected of a breach, a team of

PCI-DSS certified forensics security examiners swoops

in to review and inspect its business practices. This cost

could be somewhere between $8,000 and $20,000 for a

Level 4 merchant.

Non-Compliance Fines. The Card Brands are very

subjective about these fines that could range between

$5,000 to $100,000 (or more). For the record the

payment brands fine the acquiring bank that most

D i di e r

G oda rt

194

likely passes this fine on downstream till it eventually

hits the breached organization. Additionally monthly

fines could be applied until full compliance is achieved.

Card replacement cost: This is the cost associated to
the replacement of all compromised cards. This cost is
estimated between Between $3 to $25 per card.

Jeremy King, European director of the PCI Security Standards

Council defended the standard, claiming that the average cost per

record of cardholder data lost in the UK is 79 ($126) per record.

[From PCI DSS: is the cure worse than the disease? | ITworld]. For
the record: Gartner estimates that the cost of a data security breach
can range from $90 to $305 per record.
Indirect cost
The bill is lengthened with the following indirect costs:
Productivity loss. During the forensic investigation
that can take anywhere from a few days to several

weeks, depending on the complexity of the systems

the business could be brought to an absolute standstill

while the examiners comb through your policies,

records, computer and phone systems, and employees
and eat away at your productivity, sales, and profits.

195

P C I

D S S

 Closure of business from fines and/or loss of ability to

process cards.

Revenue loss: Loss of sales from customers who realize

youre not compliant.

Compliance Cost: All breached organizations are

required to deal with non-compliance issues within a

specific timeframe. See above the implementation costs.

Business disruption. While dealing with the noncompliance issue, staff is not working on specific
business tasks.

On-site Audit. All breached organization are subjected

to yearly on-site audit.

Fines, penalties and other settlement costs represent the

least costly consequences of compliance failure - The True Cost of

Compliance | Benchmark Study of Multinational Organizations |

Ponemon Institute | January 2011.

Compliance is Cheaper Than Non-Compliance - On average,

non-compliance cost is 2.65 times the cost of compliance - The

True Cost of Compliance | Benchmark Study of Multinational
Organizations | Ponemon Institute | January 2011.

D i di e r

G oda rt

196

ADDITIONAL RESOURCES
Free Cost breach calculator - Beta from Netvigilance
The True Cost of Compliance: A Benchmark Study of

Multinational Organizations

197

P C I

D S S

33
KEY TAKE-AWAY FROM THE
PCI COMMUNITY
MEETING 2013

HAVE BEEN ATTENDING the PCI Community meet-

ings since the early days. I remember each one of them.

Not really the content, but about the people representing

PCIco, the brands, organizations subjected to compliance,

and the security communities (QSAs, ASVs, PFIs, solution providers). They are my key rational for attending such

great events. Getting in touch with the community, network-

ing, sharing and exchanging on our field experience is a great

opportunity and in that matter this year was awesome.

For your eyes only, here are my key take-away from the 2013

European PCI Community meeting.

199

P C I

D S S

W H AT H A S B E E N S A I D
Its all about education, education and education - Tony
Blare

Complexity brings fantastic opportunities for criminals

There is a link between the level of education and the
probability of breaches within an organization

PCI is the best way to protect your organization against

cyber security attack

Card-not-present is 70% of the card fraud

PCI is not on its way to extinction
Communication between IT and Executive stays the
major issue in information security.

There is a disruption between the cost of an attack and

the associated financial impact.

Crime on the internet attracts people who would never

get involved in physical organized crime.

96 % of hackers are male and the majority of individuals

in information security cyber security are men.

A lot of security companies are selling material not

really appropriated to protect organizations.

D i di e r

G oda rt

200

 We must not underestimate the capacity and willingness

of black hats involved professionally in cyber crimes.

The most difficult part of hacking is not getting into the

systems but is not getting caught

There is a new group of developers that need to be

trained

Just one tiny percent of breached organizations actually

identified it by looking through their logs.

Cheap hosting providers could have poor security.

Expensive hosting service providers could also have
poor security but very good lawyers - Jacob A.Ansari

Organizations should invest in the people and

effort for log analysis before looking at a fancy log

analysis solution.

Hackers dont have discussions about scoping! Anything

a hacker could use against you is in scope- Joe Pierini

We dont lie to auditors... They just dont ask the right

questions. - A merchant

Poor encryption key management is the rule rather

than the exception as per QSA

201

P C I

D S S

T H E S TAT E O F P C I
According to J. King, the state of PCI is really good.
The importance of PCI continues to grow with the
rising of global card usage and associated risks.

DSS is now translated in 8 different languages including

Russian

Global participation: 40 countries attending the

community meeting this year

36 participating organizations in APAC regions

750 organizations have at least one ISA

W H AT S N E W I N D S S V 3 . 0 ?
The 3 key focuses within the DSS V3.0 standard are
Education, Flexibility and Shared responsibilities.

In scope for V3.0 are People, processes and technologies

A new section Business as usual (not subjected to the
compliance) is added.

Clarification that sampling is not an implementation

option. Just for testing purpose.

Testing procedures have been broken down

D i di e r

G oda rt

202

 Updated a number of testing procedures to enhance

consistency and interpretation.

The council clarified having the documentation ready is

not sufficient to proof implementation.

Security policies have been taken away from req 12 to

be inserted in their relevant sections

The scoping guidance has been incorporated.

Emphasizes heavily on training and education.
A new column guidance is added (currently provided
through Navigating DSS).

Improved requirements and guidance on wifi.

New definition of service providers and new requirement
addressing supplier responsibility matrix

W H AT S N E W I N R O C V 3 . 0
Testing procedures aligned with DSS V3.0
New options for finding at the sub-requirement level: In
place, not in place, in place with compensating control.

Appendix table where auditors (QSA/ISA) must list all

the reviewed documentation.

203

P C I

D S S

 Appendix table where auditors (QSA/ISA) must list all

interviewed individuals.

W H AT S E X P E C T E D I N A S V VA L I DAT I O N
REQUIREMENTS 3.0
The ASV qualification requirements will be updated

to include:

Terminology alignment
Requirement for internal separation of duties
Additional Insurance coverage
Requirement for manual quality assurance process
Requirement for protection of the scan solution

P E N E T R AT I O N T E S T I N G
V3.0 requires a penetration testing methodology that
is followed

QSA/ISA must ensure that such methodology is in

place and followed

Penetration testing must now be used to test the

effectiveness of network segmentation

D i di e r

G oda rt

204

I N -S C O P E A N D O U T- O F-S C O P E
C O N S I D E R AT I O N
PCIco clarified that to be considered out of scope a
component must be isolated from the CDE and would
not compromise the security of cardholder data.

To be out of scope a component must be proved as no

value for the attacker

EMV does not protect against card-not-present

transactions and are in therefore in scope for PCI DSS.

For PCIco, Segmentation = Isolation.

Firewall and access control can not be considered as an
isolation method.

Every DSS requirements may not apply to all

in-scope systems.

Applicable

requirements

system functions.

may

vary

based

on

Because redirection is taking place at the level of the

merchant web server, merchant web sites that redirect

the customer to payment providers must be considered
in scope even if the merchants do not see, process or

store cardholder data. PCIco is working on a new SAQ

for these merchants. In the meantime, merchants in

205

P C I

D S S

such situation should inquire their payment brands

about the SAQ they should complete.
Top tips for PCI scoping:
The five golden rules of scoping according to PCIco:
1. Think outside the box. Talk to all departments, consider
all technologies involved.

2. Risk assessments as a scoping aid

3. Update scope as part of BAU
4. Trust vendors but verify .
5. Confirm your segmentation

MOBILE
Mobile is one of the next big things for PCI. Mobile
environment is changing so fast. Mobile phone is
not secure.

PCI Mobile task force (60 members) provides very

good guidances on how to use and accept payment
using mobile. Three published guidelines on mobile.

Until the time mobile would be secured, card data

must be encrypted at the points of interaction and go

D i di e r

G oda rt

206

encrypted through the mobile network. Mobile should

only be used as a transmitter.

TO K E N I Z AT I O N
For PCIco tokenization is used in the context of PAN

eradication and not to complete a financial transaction.

PCIco is working on four technical standards.

1. General Principle
2. Reversible tokens
3. Irreversible tokens
4. Implementation requirements

C LO U D
Business relationship is complex in cloud. We see
hosting provider outsourcing to other providers

Compliance in cloud is dependent on third parties

PCIco released a best practice on Cloud and compliance.

207

P C I

D S S

F O R E N S I C I N V E S T I G AT I O N
Forensic investigation is used to identify common
factors or trends in attacks.

Data forensic is still at a very low level of development.

Determining the extend of a breach is not straightforward.
Keep IT people away from forensic investigations. Let
the specialists deal with it.

More aggressive malware are coming including

on mobiles. A lot of Android malware cases have
been detected.

AT M S
ATM is a recognized attack vector from organized
crime

ATM best practices released by PCICO cover basic on

how ATMs work and the security principles

The majority of ATMs runs over XP.

D i di e r

G oda rt

208

34
PCI DSS VERSION 3
CHANGES AND IMPACT SHOULD YOU CARE?

M HERE AGAIN with a song

in mind: Why should I care?

PCI DSS V3 is mandatory as of

January 2015. But, should you care?

Should you prepare yourselves? Well,

it depends.

In this newsletter, you will learn what has changed and what

the impact is for companies already in compliance with PCI

DSS version 2 (V2).

Low: Nothing or no much to do (for companies already

in compliance with V2).

209

P C I

D S S

 Medium: Implementation could require some effort

for the development of additional documentation, for
implementation of new processes, or for the execution
of new activities.

High: Dont wait, as implementation will require a lot

of efforts and budget allocation.

SCOPE
Merchant websites that redirect the customer to payment
providers are now explicitly in scope of PCI DSS as of

version 3. (Impact: High for this category of merchants,

Low for others.)

ALIGNMENT WITH TESTING

PROCEDURES IN PCI DSS VERSION 2
( I M PAC T: LOW )
Some testing procedures in V2 go further than the

associated requirements. PCI DSS Version 3 corrects this

by making sure that each testing procedure is associated to
a requirement. Companies already in compliance with V2
should no be impacted by these new requirements, namely:

2.2.3 Implement additional security features for unsecured

services and protocoles

D i di e r

G oda rt

210

3.5.2 Protection of secret and private keys

4.1 Safeguard sensitive data during transmission
6.5 Train developers
10.6.3 Handling of exceptions and anomalies found during
review

11.1 Process for wireless detection

11.1.2 Incident response plan for WAP detection
11.2.1 Qualified people
11.2.2 Rescans as needed
11.2.3 Qualified people
11.3.3 Correct and retest (pen test)

TRANSFER OF POLICIES AND

O P E R AT I O N A L P R O C E D U R E S I N TO
S E C T I O N S ( I M PAC T: LOW )
The requirement V2 12.2 Develop daily operational security

procedures that are consistent with requirements in this

211

P C I

D S S

specification is now incorporated at the level of each specific

section of PCI DSS V3. Companies already in compliance

with V2 12.2 should not be impacted. Associated new

requirements: 1.5, 3.7, 4.3, 5.4, 7.3, 8.8, 9.10, 10.8, 11.6.

N OT E S T R A N S F O R M E D I N TO
R E Q U I R E M E N T S ( I M PAC T: M E D I U M )
Some requirements in V2 incorporate guidance notes that
have been transformed into specific requirements in V3. As

these guidances become requirements, there is potentially

a medium impact for companies already in compliance.

Associated new requirements:

2.2.3 - Implement additional security features for unsecured

services and protocoles

3.5.2 - Protection of secret and private keys

F L E X I B I L I T Y ( I M PAC T: LOW TO
MEDIUM)
V3 adds some flexibility in the choice of the solution by
adapting the requirements.

D i di e r

G oda rt

212

1.3.4 Prevent Internal IP into the DMZ -> Implement antispoofing measures (Low)

10.6.1 Components for which logs must be reviewed daily

(Low)

10.6.2 Review periodically other logs based on risk

management strategy (Medium)

11.5 file-integrity monitoring -> by change-detection

to alert personnel to unauthorized modification of critical
system files (Low)

ADDITIONAL DOCUMENTS AND

P R O C E S S E S R E Q U I R E D ( I M PAC T: LOW
TO H I G H )
The following new requirements are associated with new
documentation, new processes, or new activity:
1.1.3 Data Flow diagram (High)
2.4 Maintain an inventory of system components
5.1.2 Periodic evaluation of systems not commonly affected
by malware (Medium)

213

P C I

D S S

6.5.10 Test for broken authentication and session

management (Medium)

7.1.1 Define access needs for each role (High)

8.1 Define and implement policies and procedure for proper
user identification management (Medium)

8.4 Additional list of guidance and instruction to be

communicated (Low)

8.5.1 Service providers must use unique authentication

credential when connecting remotely to their customer

premises (Medium-High)

8.6 Protect other authentication mechanisms (than

passwords) appropriately (Low)

11.1.1Inventory of WAP (Medium)

11.3 Implement a methodology for penetration testing
(High)

11.4 Validate any segmentation and scope-reduction

controls (High)

D i di e r

G oda rt

214

11.5.1 Incident response process for change-detection alert

(Medium)

12.9 Acknowledgement of responsibility for Service

providers (Medium)

OT H E R C L A R I F I CAT I O N S ( I M PAC T: LOW

TO M E D I U M )
Additional clarifications brought by PCI DSS Version 3:
1.1.2 Diagram showing all connections TO CDE -> All

connections BETWEEN the CED and other networks

(Medium)

1.4 Personal Firewall configuration (Low)

6.3.2 Code review (Low)

N E W R E Q U I R E M E N T S F O R CA R D PRESENT MERCHANTS
These new requirements are related to the protection of
payment devices:

9.9 Physically protect payment devices (Medium)

215

P C I

D S S

9.9.1 Inventory of payment devices (Medium)

9.9.2 Inspect device for tampering or substitution (Medium)
9.9.3 Provide inspection device training (Medium)

D i di e r

G oda rt

216

35
PATCH MANAGEMENT, HOW
TO COMPLY WITH PCI.

N THE NEWSLETTER #15 I

addressed the problem of flaws in

our working environments. As a

follow up Im covering here the topic

of patch management and its applicability within the context of PCI, a

domain of 49,5% compliance rate as per Verizon.

W H AT S A PATC H ?
In the same way a needlewoman would apply a piece of

cloth to repair a hole in your favorite coat, a patch or fix is a

piece of software that can be applied to correct an issue in our
software/operating systems.

217

P C I

D S S

W H Y I S I T I M P O R TA N T ?
Like we lock our home doors and windows to prevent

unauthorized accesses, patching is necessary to prevent

individuals or malware intruding into our systems by exploiting
the associated flaws/vulnerabilities.

H OW TO I D E N T I F Y A P P L I CA B L E
PATC H E S ?
The most trustworthy source of information related to

patches releases are the vendor bulletins or announcements

to which the organization should subscribe for each type of

system components and softwares owned.

Vulnerability scan reports are another source that is

frequently used. In addition to the list of vulnerabilities they

provide a list of missing patches as part of the consolidated

solution correction plan for each IP scanned. However, using

it as unique source of information is not recommended as

it will put the organization in a never-ending catching-up

mode and create noticeable delays in the implementation

of patches. Having said that vulnerability scans are however

recommended to:

D i di e r

G oda rt

218

 Validate the presence of vulnerabilities and therefore

applicability of patches

Confirm the level of criticality of patches

Validate implementation of patches.

W H AT A R E T H E A S S O C I AT E D P C I
REQUIREMENTS?
PCI DSS V3.0 - 6.2 requires that you ensure that all system

components and software have applicable vendor-supplied

patches installed within an appropriate timescale according

to prioritized risk with critical patches installed one month

of release.

The application and validation of 6.2 requirement is closely

associated to 6.1and 6.4.5

6.1 Establish a process to identify security vulnerabilities,

using reputable outside sources for security vulnerability

information, and assign a risk ranking (for example, as high,

medium, or low) to newly discovered security vulnerabilities.
6.4.5 Document and apply change control procedures for the

implementation of security patches and software modifications.

Procedures must include the following:

219

P C I

D S S

6.4.5.1 Documentation of impact.

6.4.5.2 Documented change approval by authorized parties.
6.4.5.3 Functionality testing to verify that the change does

not adversely impact the security of the system.

6.4.5.4 Back-out procedures.

W H AT I S M E A N T B Y C R I T I CA L ?
According to PCI DSS 6.1 A patch should be considered

critical if it addresses vulnerabilities that pose an imminent

threat to the environment, impact critical systems, and/or
would result in a potential compromise if not addressed.

H OW TO A S S E S S T H E C R I T I CA L I T Y O F
A PATC H ?
The best source for the determination of the level of criticality

of a security related patch is probably the vendor itself. They

will likely know the severity of the vulnerability addressed.

However, the criticality analysis of a patch should also consider
the criticality of the systems impacted,

the business risk

associated to the implementation of the patches (Patches are

D i di e r

G oda rt

220

also a threat agent) as well as the level of security measures in

place that could reduce the probability of exploitation.
Which systems must be patched?
PCI requires that all system components and all applications

in the card data environment must be patches.

S H O U L D A L L PATC H E S B E
IMPLEMENTED?
PCI requires to install ALL vendor-supplied patches

applicable to the environment. However blindly deploying

all patches

could be the source of system corruption or

unavailability - foundation of the following caution principle

Never touch a running system. For this reason the go/no

go decision for the implementation should be based on the

outcome of a risk analysis balancing the criticality of associated

vulnerabilities, the potential side effects on the assets and
implemented mitigation measures.

It must be noted that PCI doesnt let the door open for

waivers in this matter. ALL patches must be applied. Meaning

that the non-installation per se of a patch would lead to a non-

compliance. Hopefully, PCI lets organizations defining their

appropriate installation timescale (based on the risk analysis). So

221

P C I

D S S

one should prefer delaying installation than officially deciding

to not implement it. Of course the rational behind any decision
must be documented and validated by the management.

W H E N S H O U L D A PATC H B E D E P LOY E D ?
As mentioned above PCI requires installation of patched

within an appropriate timescale according to prioritized risk,

with critical patches installed one month of release.

This is real challenges for IT that should perform the

associated activities within the usual well known constraints limited resources, budget and time. The complexity of patching
is narrowly linked to the size of the environment. In some

organization the 30 days timescale applicable to critical patches

is just not doable. To stay in compliance, organizations could

be tempted to downgrade a critical patch to a high risk patch.

W H AT A R E T H E Q S A C H E C K S ?
To assess your compliance with this control QSAs will verify

that you have documented and applied processes covering:

Installation of applicable critical vendor-supplied security

patches within one month of release.

D i di e r

G oda rt

222

Installation of all applicable vendor-supplied security

patches within an appropriate time frame (for example, within

three months)

For this purpose QSAs will:

Examine

your

policies

and

procedures

related

to

security-patch installation, the identification and ranking of

vulnerabilities and change control.

Select a sample of system components and softwares in

scope

Compare the list of security patches installed on the

sample system components with the most recent vendor

security-patches

To support their assessment QSAs must report

The list of documents reviewed
The contain of the selected sample set
Their findings for each component of the sample sets
How to be prepared?
Make sure to:

223

P C I

D S S

 Have a general policy covering the need for patch

management as per PCI rules

Have a documented procedure for the identification of

new vulnerabilities including using reputable outside

sources

Have a documented procedure for the risk ranking of

the new vulnerabilities

Have a documented procedure covering the change

control in case of patching.

Have documented procedures (for each type of system

components in scope) defining who is involved in

patching activities, what need to be done, when should

it be done, and How. The following processes should
be addressed:

Patches

Identification

Vendor bulletins)

(i.e.

list

of

Validation of their applicability (i.e. Crosscheck with scan report)

Determination of the criticality levels

(Based on risk analysis)

Compatibility testing with systems and

controls already in place

D i di e r

G oda rt

224

 Roll-out plan definition (taking into

account potential releases roadmaps)

Exception Handling for patches that

could not be installed as per policy (for

whatever reasons).

Roll-out execution (hopefully through an

automated solution)

Installation
and

validation

documentation

for exception)

(I.e

(Logs,

scan)

rationals

Have a list of patches sources

Have a log of applied patches (date, systems,
patches Id, criticality level, approval)

Have a documentation of rationals for

non-applied patches.

Make sure systems and softwares in scope

have the latest patches installed.

225

P C I

D S S

36
CONTROL YOUR
PRIVILEGED ACCOUNTS
- HOW TO CONTAIN THE
KEYS TO THE KINGDOM
PROBLEM
W H AT S A P R I V I L E G E D AC C O U N T ?

HE TERM PRIVILEGED
account, also known as High
Privileged account or Super

user refers to any type of account

that holds special or extra permissions within the enterprise systems.

They are generally categorized as:

227

P C I

D S S

IT administrative accounts used to install or configure.

E.g.UNIX root, Windows Administrator accounts or accounts

associated with database ownership and network components.

Identity and access management accounts used to manage

users and roles.

Application accounts: The application accounts used to

access databases or other applications/systems

Emergency Accounts: Special accounts used when elevated

privileges are required to fix urgent matters.

T H E K E Y TO T H E K I N G D O M P R O B L E M
According to Verizon, many organizations do not have

any solution to control usage of privileged accounts . Usage of

shared/generic privileged accounts is a common bad practice at
the top of auditor findings

Privileged accounts provide a kind of unlimited power to

the ones who are in their possession. Beside the accidental and
disastrous damages resulting from erroneous usages of highly

risky commands, such privileges open the way to malicious

activities under the radar. Equipped with their super power,

administrators can conceal their actions in various ways such as

D i di e r

G oda rt

228

stopping/modifying or deleting the logs, hide behind a shared

accounts or put on Harry Potters invisibility cloak through a
sudo root command.

History is full of examples of individuals having diverted

their privileges for their own profits. After all, arent we all

subjected to temptation? In that case, who in your opinion

is the more guilty: the ones having misused their privileges

or the ones having assigned them with unlimited and

uncontrolled privileges?

Additionally, as reported by Verizon, shared privileged

accounts are unfortunately a quite common finding. In this

case, password changes become a nightmare as it needs some

sort of coordination. Additionally, any account lockout (due to

wrong password entries) can be catastrophic. Consequently, in

these shared environment passwords are generally not changed
and the associated accounts never lockout.

So its not a good practice to give the key to the kingdom to

someone or worse a copy of the key to a group of persons even if

they look quite innocent. On the name of the We never know

, the principle of precaution should be applicable here.

For these reasons, it should not be surprising that the usage,

management, and monitoring of these accounts are at the the

229

P C I

D S S

top of the auditors findings list and are an essential component

of PCI DSS compliance.

A S S O C I AT E D P C I R E Q U I R E M E N T S
The following requirements are associated to the control of

privileges accounts:

7.1 Limit access to system components and cardholder data

to only those individuals whose job requires such access.

7.1.1 Restriction of access rights to privileged user Ids to

least privileges necessary to perform their job

7.1.2 Assignment of privileges is based on individual

personnels job classification and function.

8.5 Do not use group, shared, or generic IDs, passwords, or

other authentication methods as follows:

Generic user IDs are disabled or removed.

Shared user IDs do not exist for system administration
and other critical functions.

Shared and generic user IDs are not used to administer

any system components.

D i di e r

G oda rt

230

10.2.2 Implement automated audit trails for all system

components to reconstruct All actions taken by any individual

with root or administrative privileges

10.2.3 Implement automated audit trails for all system

components to reconstruct Access to all audit trails

10.2.6 Implement automated audit trails for all system

components to reconstruct Initialization of the audit logs

10.5 Secure audit trails so they cannot be altered.

10.5.1 Limit viewing of audit trails to those with a job-

related need.

10.5.2 Protect audit trail files from unauthorized modifications.

W H AT TO D O A N D H OW TO C O M P LY ?
Complying with the above PCI requirements is a brainteaser

without considering implementation of a PAM (Privileged

Accounts Management) solution. They generally consist of
the following parts:

1. Control of access through a password vault/gateway. IT

staff are personally authenticated prior to requesting,

approving, or gaining access to a privileged account. This

231

P C I

D S S

ensures accountability for changes they may make using

that account.

2. Periodic randomization of the passwords associated

with privileged accounts. This means that they cannot

be shared or stored in plaintext files.

3. Restriction of commands/actions to the minimum

necessary. Privileged commands are limited and invisible
administrators prevented.

4. Real time capture and forward of executed commands/

actions to a central place for logging and monitoring

purpose. At the minimum: who connected to which

account on which system at what time from what

device, which commands have been executed, and in

some cases, key logging and even full screen captures of

the whole sessions.

For big merchants/organizations implementation of an

enterprise-level PAM solution is probably the only way to

constraint their key to the Kingdom problem. Unfortunately
most of these solutions are probably not affordable for small/

medium organizations, leaving them in a certain no-compliance

land. Some of them tempt to approach compliance through the

use of group/team password managers (which does not answer

the whole spectrum of the problem) and many organizations
do not have any privileged account or password management
solution at all.

D i di e r

G oda rt

232

Small companies could potentially decide to implement a

strict dual control on all administrative activities that would

be acceptable for PCI compliance. However such solution is

probably not applicable in a time where we see more and more

individuals assigned to multi-tasking than a task assigned to
two individuals.

PA M P R O D U C T S
Such product class has experienced explosive growth in

the past years. There are several leading Privileged Account

Management solutions available that have mature enterprise

functionality including: CyberArk -Enterprise Password

Vault, BeyondTrust-PowerBroker, Hitachi ID Privilged
Access Manager, Avecto - Privege Guard, Centrify-

DirectAuthorize and Directaudit, Dell One Identity solutions,

CA-ControlMinder.

233

P C I

D S S

37
AND PCI SAID GET
PEN-TESTED!

HIS NEWSLETTER CLARIFIES what is expected to

comply with PCI DSS 11.3: Penetration testing.

W H Y I S P E N -T E S T N E E D E D ?
In the same way that wellness checks support a doctors

diagnosis by determining whats wrong or not working as

expected (a.k.a. an analysis) and establish the appropriate

treatment (a.k.a. a remediation plan), penetration testing
aims to:

Determine and validate a diagnosis by determining the

genuineness and severity of identified vulnerabilities

Validate that defense mechanisms against external and

internal attack vectors are working appropriately. In

235

P C I

D S S

other words, checking to see that the security controls

meant to detect and block security issues and alert the
appropriate responsible actually work.

W H Y S CA N N I N G I S N OT E N O U G H ?
Scanners are used to identify potential anomalies or

deviations against a defined normality. They help answering to

the question: Is there something wrong? The use of scanners

is however not sufficient to determine if these anomalies

comprise a real danger.

In this context, penetration testing is used to answer

the next question: So what? It helps clarifying the level of

danger an anomaly presents, or the level of exploitability of

IT vulnerabilities. If scanners help uncover potential issues,

penetration tests help validating the reality of these findings in

term of risks for the entity and priorities in term of remediation.

P E N E T R AT I O N T E S T I N G F O R P C I
COMPLIANCE
Conduction of penetration testing is a pre-requisite for

meeting compliance with PCI DSS V3 for type A-EP, D, S

and C organisations (see Merchant types). They must:

D i di e r

G oda rt

236

1. Have a documented, validated and applied methodology

for penetration testing (DSS 11.3.1)

2. Perform penetration testing at least annually and after

any significant infrastructure or application upgrade or
modification (DSS 11.3.1, 11.3.2, 11.3.4)

3. Correct and validate correction of reported exploitable

vulnerabilities. (DSS 11.3.3)

FROM WHICH PERSPECTIVE?

Penetration tests must be performed through the

following perspectives:

1. From public networks forming the external perimeter of

the CDE (Requirement: 11.3)

2. From any non-CDE LAN that has access to the CDE

perimeter (Requirement: 11.3.2)

3. From any non-CDE LAN that is entirely segmented

from the CDE (Requirement: 11.3.4). The intent of this

assessment is to validate the scope-reduction controls

between the non-CDE LANs and the CDE perimeter.

237

P C I

D S S

Note: Type C organizations must only comply with PCI

DSS 1.3.4.

W H AT H A P P E N S D U R I N G A P E N T E S T ?
Penetration testers will try to get unauthorized access to

components within the CDE, including security network

devices, servers, databases and application written by or for the

organization. Beside any critical systems outside of the CDE,

boundaries that could affect the security of the CDE must also
be targeted. Common examples of critical systems would be a

DNS server, Active Directory Server, NTP server, and/or an

Update server.

D i di e r

G oda rt

238

WHO CONDUCTS THE PEN TEST?

Organizations subjected to penetration testing may use

either internal resources or third party testers who must be

qualified for such job. The term qualified being left to the
QSA appreciation.

H OW D O YO U P R OV E C O M P L I A N C E ?
Make sure to have the following materials ready:
Documented penetration methodology covering the
various sections listed in the standard;

Documented and validated scope of penetration tests

and how it was determined;

List of executed pen tests with the following information:

Test date, Internal or External, Initial versus re-test, Pen

tester Id, scope in terms of IPs, Number of exploitable

vulnerabilities reported, link to reports;
Last reports;
Remediation plan (for identified issues) (Actions
and planning);

Documented

evidences

testers qualifications.

239

of

the

P C I

penetration

D S S

38
THE HOLY GRAIL VS ROCFISSION: THE ONLY WAY TO
REACH COMPLIANCE

BIG THANKS TO Andy

Barratt

Director,

Managing

Europe

and

QSA, Coalfire for his contribution

to this newsletter.

Any darn fool can make something complex; it takes a

genius to make something simple.
Peter Seeger

If you are the glorious knight responsible for getting

your company up to mandatory compliance levels (and keep

it there), you could potentially feel desperate facing this

enormous and tedious undertaking. This is especially true for

service providers, large and complex organizations. The ROC

(Report On Compliance) quest could well be compared to the

241

P C I

D S S

one for the Holy Grail, an endless day, a money- and timeconsuming black hole. This sounds quite pessimistic but it
is realistic. The quest is so time-, effort- and money-consuming
that organizations decide to give up and accept the risk of
non-compliance.

And what could we say about the army of QSAs (Qualified

Security Assessors), required to validate compliance of such

environments? How could they effectively take responsibility,

execute their mission with the expected quality without having

to live, sleep and eat with their customers? And what relevance
could we possibly expect from a several-hundred page ROC?

Definitely in complex environments, the usual ONE ROC

approach just doesnt work. Its long, if not endless and tedious,
and leads to unmanageable projects, poor outcomes, and lots

of frustration. It requires an army of QSAs and a mountain of

evidence. Not surprising that in such conditions, compliance

projects do not serve security. On the contrary, they can

often initiate a negative security cycle, as there is definitely no

incentive to compliance.

T H E R O C - F I S S I O N A P P R OAC H
In physics, fission is the act of splitting a nucleus of an atom

into nuclei of lighter atoms. ROC-fissioning is the name I

D i di e r

G oda rt

242

give to the act of splitting the object of a ROC, defined by the

PCI scope, into smaller objects (parts of the scope). Each part
being more manageable nearly independent of each other and
associated to its own ROC (nuclei).

I S T H I S A P P R OAC H VA L I DAT E D B Y
PCICO?
Although not specifically advertised by PCIco, the payment

brands and the acquirers, ROC-Fissioning is definitely

approved/supported and encouraged. The topic was even at

the heart of a major presentation and discussion at the latest

PCI Community meeting. To Andy Barratt (above-mentioned

contributor to this article), splitting the ROCs is the only way for
large organizations to reach compliance. Andy also mentioned
one of his customers having up to 16 different ROCs (nuclei).

W H AT A R E T H E P R E- R E Q U I S I T E S ?
This approach requires that:
The global CDE scope be documented
Each portion ROC(nuclei) be clearly documented in
terms of the scope/ object of the assessment and what
is excluded from it (from the original scope).

243

P C I

D S S

 The object of the ROC (nuclei) be firewall-off/

segregated from the rest of the scope.

Acquirer agreement be received

H OW TO AC H I E V E R O C - F I S S I O N ?
Most of the large service providers uses this approach to

segregate their services. One Service = One specific ROC

allowing them to deliver to their customers the ROC associated

to the service offered. But there is a panel of other ways to
ROC-fission the complexity of an assessment by:
Payment channels
Assets managed by different entities
Business units
Regions
Assets
Network subnets

D i di e r

G oda rt

244

W H AT A R E T H E B E N E F I T S ?
In the same way than the fission releases energy, ROC-

fissioning

releases the burden associated to complex

compliance projects.

Here are some of the benefits:

Manageable audits, better preparation, better outcome
Reduce the audit efforts and time while increasing the
quality

Reach compliance faster and therefore send a positive

message to customers and acquirers

Moderate/limit the size of ROCs

Break down the cost of compliance
Reduce the size of the QSA army
Get the right stakeholder involved and therefore get
them more accountable and interested

Limited impact in case of breach. With one ROC, the

complete organization compliance is impacted. With

multiple ROCs (nuclei), the compliance impact is

limited to the ROCs associated to the breach.

245

P C I

D S S

A R E T H E R E C O N S TO T H I S A P P R OAC H ?
Andy doesnt see any cons to this approach. Of course, it

requires more audits but this is not a bad thing. As mentioned

above the efforts, cost and time associated to each audit are
drastically reduced for a better and faster outcome.

D i di e r

G oda rt

246

39
THE 7 GOLDEN RULES FOR
MAINTAINING COMPLIANCE

IVE YOURSELF AND

your team a tap on the

back. You finally got it,

your longed-for positive Report On

Compliance (ROC) is eventually lay-

ing on the management desk. You can

now proclaim yourself PCI compli-

ant, forget about these compliance

futilities till next year and go back to your important duties.

We should not delude ourselves. Getting seasonal

compliance is indeed the aim/vision of a large part of the PCI

community that sees in a PCI self-assessment or positive ROC,

a business-enabler and/or penalties waiver. Of course, the state

of their security controls will probably fall off in between two

assessments and preparing (cleaning the mess) for their next

247

P C I

D S S

audit could be energy-consuming but who care? Not them.

Mission completed!

W H E N T H E CAT S AWAY T H E M I C E W I L L
P L AY
Research

conducted

by

Verizon showed that many of the

organizations that were assessed as

being non-compliant at the time
of their breach had successfully

complied during their previous PCI

back into non-compliance.

D i di e r

G oda rt

DSS assessment and had lapsed

248

THE INTEND OF PCI

PCI expects organizations to maintain a continuous state of

compliance throughout the year and not seeking point-in-time

validation.

T H E G U I DA N C E F O R M A I N TA I N I N G
COMPLIANCE
For organizations that want to protect themselves and their

customers from potential losses or damages resulting from a data

breach, or just be in full compliance with the intend of PCI, the

Council with the contribution of the community released the:

Best Practices for Maintaining PCI DSS Compliance. Here are
the 7 major rules extracted from this guidance.

G O L D E N R U L E S F O R M A I N TA I N I N G
COMPLIANCE
Rule 1 - Commitment to Maintaining Compliance
Executive sponsorship is critical if organizations want

to be successful in implementing ongoing PCI DSS

compliance programs.

249

P C I

D S S

Rule 2 - Assign Ownership for Coordinating and monitoring

security activities

A compliance manager should be assigned overall

responsibility for coordinating and monitoring execution of

regular security activities such as patching systems, security-log

reviews, wireless network scans, internal/external vulnerability

scans and internal/external penetration tests are performed

as required. Additionally, the compliance manager should be

responsible for collecting, collating, and storing evidence to
demonstrate ongoing PCI DSS security controls are operating
effectively on a continuous basis.

Rule 3 - Emphasize Security and Risk, Not Just Compliance

Focus on building a culture of security and protecting an

organizations information assets and IT infrastructure, and

allow compliance to be achieved as a consequence. Using

risk as the basis for selecting security controls may allow an

organization to tailor specific security controls differently to
meet varying levels of organizational risk.

3.1 Use Risk to Balance Business Priorities with Security

Needs

Maintaining compliance with PCI DSS requires resources

and financial investment. Using risk as the basis for measuring

D i di e r

G oda rt

250

security effectiveness can make it easier for security teams to

justify the expenditures necessary for building a comprehensive
security and compliance program.

3.2 Integrate PCI DSS controls into a larger, common set

of security controls defining a security framework adapted to

your organization needs. When PCI DSS is integrated into an

organizations overall risk-based security framework, it makes it

easier to incorporate specific PCI DSS activities into the normal

day-to-day operations of the security team. This, in turn, helps

to ensure these activities are conducted on a regular, ongoing

basis, which can make maintaining PCI DSS compliance a

much more manageable task.

Rule 4 - Develop strategies to continuously monitor and

document the implementation, effectiveness, adequacy, and status of

all of your security controls.

Develop processes for performing periodic reviews of all

relevant security controls to confirm that:

PCI DSS requirements continue to be in place and operating

effectively, and

Personnel continue to follow appropriate security procedures.

Rule 5 - Detect and Respond to Security Control Failures

251

P C I

D S S

It is critical that organizations are able to detect failures in

security controls during the control-review or control-monitoring

processes. It is also imperative that organizations have processes

for responding to security control failures in a timely manner.

In some cases, security control failures could constitute a formal
security incident, and require a more formal incident response.
Rule 6- Develop Performance Metrics to Measure Success
Organizations should quantify their ability to sustain

security practices and PCI DSS compliance by developing a

set of metrics that summarize the performance of their security

controls and security program. Risk reduction is a key metric

for illustrating overall security-program effectiveness but

metrics can provide meaningful indicators of security status at

other levels within the security program as well.

Rule 7 - Adjust the Program to Address Changes

Have sound change-management practices to keep up

with the changing threat landscape and to maintain ongoing

compliance with PCI DSS.

7.1 Organization changes

Failure to consider how such changes may impact the

organizations risk environment and/or PCI DSS scope

D i di e r

G oda rt

252

could leave key business functions vulnerable to compromise

or non- compliance. Examples of organization changes to

consider: Merge, internal restructuring, corporate spin-offs,

bankruptcies and liquidations, loss of key IT security personnel,
and outsourcing arrangement

7.2 Changes in operational environment - network

architecture or infrastructures -

Organizations should evaluate how any changes to the

operating environments might impact the scope or status of the

organizations PCI DSS compliance. Examples are: Deployment

of new systems or applications, changes in system or network
configurations, or changes in overall system topologies.
7.3 Changes in technologies
Organizations should also review general technologies

supporting the card data environment at least annually to

confirm that they continue to support the security needs of the

organization.

RESOURCES
PCI Best Practices for maintaining Compliance

253

P C I

D S S