P R AC T I C A L G U I D L I N S F O R C O M P L I A N C

Y J FF MAN

Ta le of Content
CHAPT R 1

PCI Securit Attitude v . Compliance

CHAPT R 2

The Truth ehind Three PCI M th

CHAPT R 3

Five Recommendation for PCI Compliance and

C er ecurit
CHAPT R 4

e t Practice : Keeping Malware Out

CHAPT R 5

e t Practice : ncr ption and Tokenization

GLOSSARY

Glo ar of Term
A OUT

A out the Author

1
PCI S CURITY
AT T I T U D

2014 WAS LA

VS. COMPLIANC

L D Y MANY a the ear of the reach ecau e of

the numerou major retailer and merchant who reported

compromi e mo tl due to pecialized malware that targeted
retail point of ale (POS)

tem . The perva ivene

left man a king, How do I keep m

u ine

of the e attack

from experiencing the

Next ig Retail reach? There are man per pective on thi

u ject, ut a an information ecurit profe ional who ha
pecialized in compliance with the Pa ment Card Indu tr (PCI)
Data Securit Standard (DSS) for more than a decade, Id like to hare
m thought a out the tate of

tem protection in the retail

indu tr and how to afeguard our u ine .

In o much that I read, there too much empha i on whether a
reached retailer wa certi ed a PCI compliant. I thi important?
Of cour e, it i . ut a e /no reading on certi cation fail to addre
a general attitude of merchant toward the whole PCI proce . I have
een a Quali ed Securit A e or (QSA) ince the inception of the

PCI tandard and I can tell ou that, too often, the attitude of m
cu tomer conve ed a en e of Let get thi over with... or The
audit of the month i wa ting m time... or even Ju t tell me what I
need to do to pa .
There are certainl exception . ut Ive worked with too man
companie that dont reall em race the impact that ucce ful PCI
ecurit

tandard implementation can have on their overall ecurit

po ture not impl for the protection of credit card data, ut for
the protection of their entire enterpri e. The principle of PCI
compliance can e applied equall e ectivel to the c

er ecurit

polic for all our IT operation . Thi notion i frequentl lo t on

merchant

ecau e the

pend an inordinate amount of time

attempting to limit the cope of the a e ment. Thi t picall

mean , If ou dont have to look at a et of

tem , then I dont have

to ecure them... Mo t of u would agree that thi i the wrong

approach.

Securit i omething ou do continuou l and

diligentl ; not omething ou check o on a to do li t
and then it ack and relax
I came into PCI a a veteran information ecurit con ultant with a
Department of Defen e (DoD) ackground. I am al o a trained
cr ptanal
awarene

t. M client alwa

got a health do e of ecurit

in general. ut I wa particularl intere ted in educating

them a out how PCI control had come a out and what the meant
in other word , clarif ing the context. Frequentl , at the conclu ion
of the a e ment, cu tomer will tell me, That wa the toughe t

a e ment [audit] weve ever een through. ut it wa de nitel

worthwhile ecau e we need to e more ecure. The PCI tandard
are not perfect, ut holi ticall the are the mo t exacting and
comprehen ive et of ecurit control I have een out ide of the
DoD. In fact, I elieve the

tand up ver well a a framework for an

ecurit program.
Unfortunatel , the are rarel perceived a

uch. The PCI indu tr

promote thi mi guided approach to implif ing compliance and

reducing cope. Yet, too man companie get wrapped around the e
directive and quickl lo e ight of the igger picture: ecurit !
Ca e in point: I often heard from the ecurit /IT folk at client ite
that PCI tandard are onl a tarting point. The

elieved that PCI

repre ent a are minimum approach and that a real ecurit focu ed program would go much further and require much more.
However, the ame organization

truggled to meet all of the

requirement and ucce full demon trate compliance.

How can a tandard deliver no more than the are minimum, et till
e di cult to achieve? In large part, it

ecau e ecurit i a out

attitude/po ture/mind et/culture rather than the achievement of a

predetermined, perceived tate. Securit i

omething ou do

continuou l and diligentl ; not omething ou check o on a to do

li t and then it ack and relax. PCI ha all the component to allow
companie to adapt thi

tate of due diligence. ut it i too

commonl pre ented a a point-in-time audit

ju t a out ever

mem er of the PCI communit , e the QSA , the PCI Securit

Council, the merchant them elve or the vendor

elling the quick

x/ u thi and oure done olution .

We can do much etter. Read on and oull nd out how.

2
TH

TRUTH

HIND THR

PCI MYTHS

M RCHANTS AND R TAIL RS face immen e challenge with re pect

to their c

er ecurit po ture ut dont often focu on the

important element . For tarter , the will pend an inordinate

amount of time truggling to reduce the cope of their enterpri e
that need to compl with the PCI DSS. Then, when the are found
to e compliant, the often di cover the hard wa that their are
minimum approach to PCI compliance ha left them till vulnera le
to exploit and attack ut even wor e, the are not equipped to
detect or re pond to the attack . In hort, a are minimum approach
to PCI DSS compliance i not what i ideal for optimal protection.
Given the e concern , con ider the following m th and
mi conception that are creating further complexitie :

M th #1
Hard-to-detect, cu tomized malware targeting peci c retailer point
of ale (POS)

tem

ecame much more prevalent in 2013 and 2014

That true. ut what thi m th overlook i that the vulnera ilitie

commonl

eing exploited

the malware are predominantl old

vulnera ilitie re ident in old (often un upported) operating

tem

that hould have een updated, mitigated, or patched out of the

tem

ear ago. Retailer are ju ti a l concerned a out the

ecurit of their POS

tem

ecau e the are often uilt

part with em edded operating

tem and di tri uted

a third
the

thou and throughout large geographic region . Thi make it hard

to patch the

tem , appl anti-viru /anti-malware olution (while

making ure the are updated automaticall and canned

periodicall ), in tall le integrit monitoring olution , ena le
logging, cop the log to centralized logging erver , etc. all of
which are activitie required

the PCI DSS.

Vulnera ilitie commonl eing exploited

the
malware are predominantl old vulnera ilitie
The up hot: the current variant of POS malware wont work if
tem are updated, ecure and meet PCI tandard .

M th #2
De pite pending con idera le re ource on PCI compliance,
criminal are till ucce full targeting retailer

PCI compliance doe not equate to ecurit .

PCI compliance could equate to ecurit if the tandard were
actuall applied and followed acro

the enterpri e, and not limited

to the egmented cardholder data environment. Which i not to a

reache wouldnt occur, ut merchant would ucce full detect

and thwart more attempted attack . ven if attack are not
prevented, the intru ion can e quickl halted with minimal
damage. The pro lem i that too much time and mone i
technolog

pent on

olution that purport to do the oring heav lifting

and to limit the cope of what need to e ecured. ut the true

locking and tackling a ic of good ecurit require dedicated
individual to appl paranoid due diligence a ove and e ond the
call of dut .

M th #3
There are man moving part of a retail tore network and man
t pe of u er acce ing them, making it more di cult to egment the
cardholder data environment from the re t of the network
There are two pro lem here: Fir t, PCI DSS doe not require
egmentation, particularl a a ecurit

e t practice (defen e-in-

depth) e ond the implied three-level architecture common to ecommerce implementation . Second, when applied, egmentation i
done for the expre

purpo e of reducing the cope of the

a e ment. It often i paired with the idea that we dont have to

ecure the
extend

tem that arent u ject to review. Thi attitude even

e ond an perceived Cardholder Data nvironment to the

tem that a QSA ample ver u the entire et of in- cope

tem . Im ure Im not the onl QSA who di covered that a client
didnt appl mitigation to a pro lem di covered during ampling
e ond the original

tem reviewed and the new

tem

reviewed, if ju t to prove the point. M recommendation i to

egment our network to create ecurit -in-depth, not to limit cope;
and appl the a ic PCI DSS control acro

the entire network.

Segment our network to create ecurit -in-depth, not

to limit cope; and appl the a ic PCI DSS control
acro the entire network
Once we clear up the confu ion ehind the e m th and
mi conception , it ea ier to o tain oth PCI compliance and a
ecure environment. In the next chapter, Ill recommend ve
guideline to help ou move forward with a PCI- a ed c
program.

er ecurit

3
FIV

R COMM NDATIONS

FOR PCI COMPLIANC

AND CY

RS CURITY

NOW THAT YOU UND RSTAND PCI compliance etter, Id like to

hare ve recommendation for c

er ecurit a urance and our

PCI compliance program:

1) Never eparate PCI compliance from our

compan ecurit program
Man organization make the mi take of putting PCI in ome kind of
ox, practicall removed from the ecurit program. ut PCI i a
data ecurit

tandard. How can ou compartmentalize a framework

that wa originall intended to mea ure the maturit of a compan

ecurit program, particularl a related to the protection of
pa ment card data? Thi approach i highl
wa PCI ha

awed and peak to the

een mi applied and mi interpreted.

2) Choo e an independent QSA (Quali ed

Securit A e or) to audit our
tem
Companie need to hire PCI a e or who are experienced

information ecurit profe ional and trul under tand the

pa ment card indu tr

ecurit requirement . Not CPA who

ecame auditor and la t week were conducting audit again t

Sar ane -Oxle , Gramm-Leach- lile Act, Health In urance
Porta ilit and Accounta ilit Act, or ome other regulator
tandard. eware of certi cation a well; a CISSP doe not an
information ecurit profe ional make.
There are potential con ict of intere t if a QSA compan al o
provide additional managed ecurit

ervice or remediation

ervice . While reputa le companie

t thi model, a k our elf: doe

the QSA reall have our compan

e t ecurit intere t in mind,

or i he reall up elling other ervice ?

3) Pa attention to what the PCI Data Securit

Standard (DSS) alread require or trongl
recommend
Man article coun el ou on what to do over and a ove our PCI
compliance initiative to en ure that ou are ecure and wont e the
next victim of a reach. ut oud e urpri ed how man of tho e
ugge tion are actuall alread addre ed

the PCI DSS.

Concentrate on what the PCI DSS oth pre cri e and recommend
and oull e well on our wa to a full

ecure environment a well

a compliance. In particular:

I olate cardholder data through network

egmentation
Segmentation of cardholder data i highl recommended

PCI. The

tandard require the implementation of control that monitor and

re trict network tra c from point-of- ale (POS) regi ter and acko ce

tem . If oure not alread doing o, oure oth in ecure

and non-compliant.

n ure that POS

tem are ingle purpo e

To provide additional ecurit mea ure to POS

tem mu t alread

tem , the

e ingle purpo e. Re tricting acce

to US

port i a great idea and alread a requirement, ut con ider that

mo t PIN Tran action Securit (PTS) / Point of Interaction (POI)
device are plugged into the POS

tem via a US port. ven if ou

di a le all other US port , there till i at lea t one for the POI (not
to mention the occa ional monitor, ke

oard and mou e.) What

prevent an attacker from unplugging an authorized

tem

component or peripheral and taking advantage of that port? The PCI

Council ha an wered thi que tion
ph

requiring more tringent

ical ecurit control for the e POI device in PCI DSS ver ion 3.

Prevent malware in tallation and operation u ing

la ered ecurit mea ure
PCI DSS a

that there mu t e a la ered approach to protecting

application running on POS regi ter in term of external and

internal

tem . All application running on POS regi ter mu t e

PCI-approved (PA-DSS or PCI DSS).

Focu on rapid reach detection and u e context-aware

data anal tic
PCI DSS require dail or automated review of all

tem and event

log to detect maliciou activit . Man of the recent new -worth

reache were not detected in a da and were not even di covered

the reached retailer them elve . Which lead u to m fourth
recommendation.

4) It not enough to acquire and implement

tech tool ou have to under tand them
and know how to u e them
While it true that automation and anal tical tool are important,
acquiring and implementing them i meaningle

unle

our IT or

IS team are actuall monitoring the tool , tud ing their output ,
and re ponding to u piciou event a the occur.
Over the ear , the mo t ecure compan network I have een are
the one where there are certain individual (or team ) that take it
upon them elve to know their network, the u ine

proce e

and data ow , and the overall operation. The are the one mo t
likel to notice anomalou
o

ehavior either directl or

erving the output of tool that automate the culling of thi t pe

of data and the are the one that mo t often ave the da for
their companie .

5) n ure that our ecurit anal t team i

properl trained and highl valued
O viou l , the e t pe of individual are hard to come

; the dont

grow on tree . The often are not motivated in the wa

that other

are motivated namel , it not alwa

a out the pa check. More

often than not, it i a out recognition and appreciation not even

from within the compan or from management, ut from their peer

in the profe ional communit at large.

Still, PCI attempt to e ta li h a a eline of quali cation for the e
individual . PCI doe not peak to headcount. ut it doe require
that dail operational procedure are a igned to peci c
individual /role individual who receive adequate, ongoing
training in their area of focu . In addition, individual with
incident-handling re pon i ilitie require annual pecialized
training to learn how to properl anal ze and re pond to incident
and event , uch a when to e calate. You cant pa lip ervice to
their hift length either. The have to attentivel monitor and act
upon ecurit alert . If the re fatigued, the ri k overlooking a highpriorit

ituation.

Reali ticall , man retailer out ource the monitoring and detection
re pon i ilitie to managed ecurit

ervice provider . I dont know

how a merchant can e a ured that the provider ha

u cient ta ,

or whether tho e emplo ee are trained to review and detect

anomalou

ehavior (a oppo ed to merel

eing capa le of waiting

for an automated alarm.) When ou out ource re pon i ilit for the
ecurit of our network to a third part , ou are putting our
compan life in omeone el e hand . I thi a

cal nece it ?

Perhap , ut i it reall more co t-e ective in the long run?

In realit , the e ve recommendation onl repre ent the foundation
of optimal PCI compliance and c

er ecurit operation . In the next

two chapter , Ill dig deeper into the detail

that ou mu t incorporate into all of our c

ehind the e t practice

er ecurit initiative .

4
ST PRACTIC S
K

P I N G M A LWA R

TO IMPL M NT A FULLY R ALIZ D c

OUT

er ecurit

trateg that al o

meet PCI compliance tandard , ou hould incorporate e t

practice into our ecurit program. The following guideline are
e t practice that have een proven over time with man retailer
and organization . Where applica le, I have al o li ted their
reference in the PCI DSS.

When educating emplo ee , explain the wh

ehind the what
Mo t of the recommendation in thi
awarene

training (required

ection addre

emplo ee

PCI), in addition to putting lter in

place to lock malware-laden email and uch.

placing increa ed

empha i on emplo ee ehavior , oull igni cantl increa e the

e ectivene

of our other e ort . You need to teach emplo ee

a out the ad thing that the mu t avoid doing not onl what
ehavior

ut wh the

hould e avoided to reduce ri k. In other

word , dont re ort to Dont do it ecau e we a

o lecture .

In tead, tr the po itive approach and engage our emplo ee : You

are a vital contri utor to our u ine . What ou do or dont do
impact our operation ... Dont load up on the FUD factor (fear,
uncertaint and dou t). reak it down into imple term .
Here how thi

e t practice tie

ack to the PCI DSS:

A ure that application developer receive training in ecure

coding technique PCI DSS 6.5.a, 6.5.c
Train tore emplo ee on how to pot u piciou ehavior and
to in pect POS device for evidence of tampering PCI DSS 9.9.3
Provide ongoing ecurit awarene

training 12.6, 12.6.1, 12.6.2

Provide pecialized training to ta with ecurit

re pon e re pon i ilitie PCI DSS 12.10.4

reach

Prevent malware in tallation and operation

Malware prevention activitie focu on ve peci c ta k :
Re trict direct acce

to the cardholder data environment from

the Internet u ing egmentation and trong rewall rule PCI

DSS 1.1.4, 1.1.6, 1.2
Re trict out ound connection from the POS and ack-o ce
tem PCI DSS 1.3.5
Out ound connection

hould e limited to peci c IP

addre e and port on tho e addre e PCI DSS 1.2.1, 1.3.5

Out ound connectivit hould e logged, monitored, and
reviewed PCI DSS 1.2.1, 1.35, 10.2, 12.10, 12.10.3, 12.10.5
Make ure local admini trator pa word are unique acro
tem on the retailer network, and u cientl di cult to

all

gue

PCI DSS 8.2, 8.2.1, 8.5

Detect reache a quickl a po i le

Thi i all a out eing diligent. The PCI DSS require the following
protection :
Implement centralized logging and monitoring with dail
review PCI DSS 10.1-10.6
Note: Log all

tem and event :

All ecurit event

vent log of all

tem component that tore, proce

or

tran mit cardholder data (CHD) and/or en itive

authentication data (SAD) or could impact the ecurit of
CHD and/or SAD
vent log of all critical network component
Log of all erver and
tem component that perform
ecurit function (for example, rewall , intru iondetection
tem /intru ion-prevention
tem (IDS/IPS),
authentication erver , e-commerce redirection erver ,
etc.)
Implement intru ion prevention

tem PCI DSS 11.4

Implement proce e for the detection of tampering with POS

device , to include ph ical and logical detection of US port
PCI DSS 9.9. Note: You cant di a le the US port on POS
tem ecau e that how the PIN Tran action Securit
(PTS)/Point of Interaction (POI) device are t picall connected
(a well a monitor , ke oard , etc.). It i e ential to include

US port in the ph
operation .

ical ecurit review of point of ale

La tl , here are a few word a out whiteli ting olution , which are
in vogue for man retailer a a compen ating control for the
following rea on :
A lack of anti-viru /anti-malware olution and/or the ina ilit
to keep ignature current
An a

ence of timel patch management

A lack of le integrit -monitoring olution

Now that Window XP ha gone out of upport (and em edded
Window XP i next), whiteli ting i often pro ered a compen ation
for the lack of more XP ecurit patche . In man ca e , I u pect
that man un upported XP

tem (particularl POS

tem ) are

alread woefull in ecure ecau e the arent current with the

patche that are alread availa le. What if the tru ted application
were compromi ed at the upplier/vendor facilit ? What if the etto- e-di covered-and-exploited vulnera ilit can execute within the
authorized parameter of the application?

5
ST PRACTIC S
N C R Y P T I O N A N D TO K N I Z AT I O N

FINALLY, ID LIK TO ADDR SS the pro and con of two technolog

olution which promi e to o oad mo t if not all of the urden of
PCI compliance for merchant large and mall. The goal i to create
an environment where properl implemented, the e olution would
greatl reduce the footprint of pa ment card data (namel the
primar account num er or PAN) that make a merchant u ject to
PCI DSS compliance in the r t place.

Dont mi the c er ecurit fore t for the PCI

compliance tree!
What are tho e two olution ? ncr ption peci call point-topoint encr ption (P2P ) and tokenization. The e technologie are
thought to reduce cope

tr ing to promote the argument that

encr pted card data (and the token value) i not cardholder data
therefore the

tem which tran mit, proce , tore the not-

cardholder data are no longer u ject to PCI control . ut that not

reall true. Here wh .

ncr ption
Realit i more complicated than argument a out whether
encr pted card data i nt cardholder data, and therefore not u ject
to PCI review. The PCI Securit Council ha made it ver clear that
encr pted cardholder data can onl
if the merchant (the council a
decr pt the data. Make

e precluded a cardholder data

entit ) doe not have the a ilit to

en e, right? A uming that the encr ption

i ro u t and cr ptographicall

ound, it

afe to a ume that the

encr ption work . The igge t pro lem i that mo t encr ption
algorithm in u e toda are

mmetric algorithm which mean

that the ke u ed to encr pt i the ame ke u ed to decr pt the

cardholder data.
The point-of-interaction (POI) i where a con umer provide the
pa ment card to the merchant in order to extract the primar
account num er and other required data (the content of the
magnetic tripe). Since the merchant i in po e ion of the POI
device, and the ke i

mmetric, then the merchant ha the a ilit

to decr pt the data (whether the know it or not, or have the

technical acuit to perform the feat).
nter a tandard which addre e thi : Point-to-Point ncr ption
(P2P ), which take place not in ide the POS

tem ut within the

PTS POI device (i.e., the pin pad or the card reader) if and onl if the
reading of the magnetic tripe data and the encr ption of aid data
occur within a hardware encr ption module that i em edded
within the device. Thi ha
encr ption ke

een deemed u cient to take the

out of the hand of the merchant and to invoke the

tatement, the encr pted data i not cardholder data. And the
authorized decr ption ha to e out of the hand of the merchant a
wellt picall the re pon i ilit of a pa ment gatewa or proce or
who in turn tran mit the data onto the ank for authorization.
The r t certi ed P2P

olution onl

ecame availa le in Octo er

2013, and a of the date of thi document there are till ver few
compliant olution li ted. Unle

ou are u ing one of the validated

olution , ou a a merchant dont get to make the it not

cardholder data cope-reducing claim. (If ou have a olution
alread it likel happening in memor . And gue

what? That

where all the memor - craping malware weve een reading a out i
equall adept at tealing the data.)
I am a certi ed cr ptanal

t who u ed to work for the DoD, and I can

tell ou that encr ption i di cult to implement e ectivel . What i

u uall the downfall of cr ptographic olution involving
encr ption i the implementation of the olution it elf. Ca e in point:
the OpenSSL Heart leed vulnera ilit . There wa nothing wrong
with the encr ption, no weak algorithm that could e rute-forced;
even the ke management wa not in que tion. What we aw with
the Heart leed vulnera ilit i the perfect torm of how
implementation of a ecurit protocol wa completel compromi ed
ecau e of a ug in one of the component part , which left the data
that wa

uppo ed to e tran mitted ecurel totall expo ed

ecau e an attacker could recover the ke

connection in the r t place.

u ed to create the ecure

Hacker dont t picall tr to reak encr ption; the do a couple

other thing that are ju t a e ective. Fir t, the tr to teal the ke
o ke management/ke

ecurit

ecome paramount. So with

omething like P2P , thi i prevented on the front-end (POI)

the

u e of em edded cr pto; what remain i the ack-end where

decr ption occur . That not technicall the merchant pro lem.
ut it i , ecau e the up tream entit which i doing the decr ption
i a ervice provider to the merchant and i

u ject to PCI

compliance. All the complexitie of compliance remainthe urden

ha

impl

een hifted one-o to a third part . The other common

practice for hacker attempting to circumvent encr ption i to

exploit weakne e in the implementation of the cr ptographic
tem them elve . Thi i the primar rea on wh

ou wont get a

traight an wer to If I u e encr ption will I e ecure? and wh

get a repl

ou

uch a it depend or the devil i in the detail or if it

implemented correctl .
Speaking of implementation, encr ption i not onl required for the
torage of cardholder data ut al o for tran mi ion of data over
open, pu lic network . Thi i commonl accompli hed u ing the
Secure Socket La er (SSL) protocol. Thi protocol initiall perform
a hand hake with a pu lic ke (certi cate) that provide a ecure
method of haring a

mmetric e ion ke and ultimatel encr pt

the entire communication. Until recentl , SSL wa

o commonl

accepted that the PCI DSS referred to it a an example of a ecure

technolog . However, recent di clo ure of weakne e in the SSLv3
protocol have forced the PCI Council to pu li h a revi ed ver ion of
the PCI DSS (v3.1) which tipulate that SSL ma no longer e u ed in
an

tem that are part of the cardholder data environment. Thi

include not onl we

erver

ut al o remote acce

uch a VPN , other proprietar remote acce

interface for remote admini tration of

technologie

technologie , and we

tem .

Tokenization
Tokenization i a great wa to improve ecurit

reducing the

touch point of cardholder data. It doe a great jo of eliminating

incidental acce , cop ing, torage and the tockpiling of cardholder
data

well-meaning emplo ee who inadvertentl create a PCI

compliance nightmare. However, if there are folk within the

compan who have to ee the cardholder data, the will need to
launch a de-tokenization procedure. ut how doe the

tem

perform de-tokenizationparticularl how doe it provide

authentication and authorization to the right people? That a
dilemma that doe nt eem to have an u eful ecurit guidance,
other than fuzz

tatement

uch a de-tokenization work if it i

implemented correctl .
Al o, doe de-tokenization mean that the tockpile of token i
meaningle

data that doe nt have to e ecured? Or at lea t not to

the minimal degree required

PCI? That intere ting, ecau e if I

am an attacker, I can a ume that I have free and open acce

to all

the token . Therefore, all that left i to gure out how to detokenize and voila!Ive tolen credit card data. M target then
ecome the de-tokenization method, and the people (and their
tem ) who u e the de-tokenization method.
So, I am not comforta le with di regarding the token . In fact, I

elieve that the rule applied to encr pted data hould e extended to
token : If ou can de-tokenize, it

till card data.

Ultimatel , there are no ilver ullet , and no u

ecurit . Which mean due diligence reign

titute for good

upreme; ou mu t keep

a clo e e e on the network and all data ow . Silver ullet de igned

to make PCI compliance imple or eliminate the need for PCI are
profoundl irre pon i le. If a vendor make
trongl

uch promi e to ou, I

ugge t ou nd another vendor.

Ultimatel , there are no ilver ullet , and no

u titute for good ecurit
all mean , ou ma inve t in P2P and/or tokenization olution
ut do o for the added level of ecurit complexit

ou introduce

to our environmentnot to reduce or eliminate the pain of a PCI

compliance a e ment. Finall , dont write-o or di mi

the PCI

DSS tandard . Recognize them for what the are (and arent) and
leverage the PCI compliance proce

to make our organization a

ecure a it need to e. Sta vigilant!

G
GLOSSARY
CHD - cardholder data
DoD - Department of Defen e
DSS - Data Securit Standard
IDS - intru ion-detection
IPS - intru ion-prevention

tem
tem

P2P - Point-to-Point ncr ption

PAN - Primar Account Num er
PA-DSS - Pa ment Application Data Securit Standard
PCI - Pa ment Card Indu tr

PCI DSS - Pa ment Card Indu tr Data Securit Standard

POI - Point of Interaction
POS - Point-of-Sale
PTS - PIN Tran action Securit
QSA - Quali ed Securit A e or
SAD - en itive authentication data

A
A OUT
A out Je Man
Je ha compiled a rich knowledge a e
in cr ptograph , information ecurit ,
and mo t recentl PCI. With PCI
impacting nearl ever
vertical, he ha

u ine

erved a a QSA and

tru ted advi or for oth VeriSign and

AT&T Con ulting. A an NSA
cr ptographer, he over aw completion
of ome of the r t oftware- a ed cr pto

tem ever produced for

the high-pro le government agenc . Je i currentl a Tena le

Strategi t, pecializing in compliance. Je o er over 30 ear of
information ecurit experience and knowledge to help cu tomer
align Tena le product and ervice with the ecurit

e t practice

that are the foundation of all indu tr and regulator

ecurit

tandard .

A out Tena le Network Securit

Tena le Network Securit provide continuou network monitoring
to identif vulnera ilitie , reduce ri k and en ure compliance. Our
famil of product include Securit Center Continuou View,
which provide the mo t comprehen ive and integrated view of
network health, and Ne u , the glo al tandard in detecting and
a e ing network data. Tena le i relied upon

man of the

world large t corporation , not-for-pro t organization and pu lic

ector agencie , including the entire U.S. Department of Defen e. For
more information, plea e vi it tena le.com.

Note
Some of the following material originall appeared in the Tena le
log or in Wired InnovationIn ight

log.