PRACTICAL GUID&L IN&S FOR COMPL IANC&

#Y J&FF MAN

Ta)le of Content:

CHAPT&R 1

PCI Securit: Attitude v4. Compliance

CHAPT&R 2

The Truth ehind Three PCI M:th4

CHAPT&R 3

Five Recommendation4 for PCI Compliance and

C:#er4ecurit:

CHAPT&R 4

e4t Practice4: Keeping Malware Out

CHAPT&R 5

e4t Practice4: ncr:ption and Tokenization

GLOSSARY

Glo44ar: of Term4

A#OUT

A#out the Author

2014 WAS LA#&L&D #Y MANY a4 the :ear of the #reach #ecau4e ofthe numerou4 major retailer4 and merchant4 who reported

compromi4e4 mo4tl: due to 4pecialized malware that targeted

retail point of 4ale (POS) 4:4tem4. The perva4ivene44 of the4e attack4

left man: a4king, How do I keep m: #u4ine44 from experiencing the

Next ig Retail reach? There are man: per4pective4 on thi4

4u#ject, #ut a4 an information 4ecurit: profe44ional who ha4

4pecialized in compliance with the Pa:ment Card Indu4tr: (PCI)

Data Securit: Standard (DSS) for more than a decade, Id like to 4hare

m: thought4 a#out the 4tate of 4:4tem4 protection in the retail

indu4tr: and how to 4afeguard :our #u4ine44.

In 4o much that I read, there4 too much empha4i4 on whether a

#reached retailer wa4 certied a4 PCI compliant. I4 thi4 important?

Of cour4e, it i4. ut a :e4/no reading on certication fail4 to addre44

a general attitude of merchant4 toward the whole PCI proce44. I have

#een a Qualied Securit: A44e44or (QSA) 4ince the inception of the

PCI SCURITYATT ITUD& VS . COMPL IANC&

1

PCI 4tandard and I can tell :ou that, too often, the attitude of m:

cu4tomer4 conve:ed a 4en4e of Let4 get thi4 over with... or The

audit of the month i4 wa4ting m: time... or even Ju4t tell me what I

need to do to pa44.

There are certainl: exception4. ut Ive worked with too man:

companie4 that dont reall: em#race the impact that 4ucce44ful PCI

4ecurit: 4tandard implementation can have on their overall 4ecurit:

po4ture not 4impl: for the protection of credit card data, #ut for

the protection of their entire enterpri4e. The principle4 of PCI

compliance can #e applied equall: eectivel: to the c:#er4ecurit:

polic: for all :our IT operation4. Thi4 notion i4 frequentl: lo4t on

merchant4 #ecau4e the: 4pend an inordinate amount of time

attempting to limit the 4cope of the a44e44ment. Thi4 t:picall:

mean4, If :ou dont have to look at a 4et of 4:4tem4, then I dont have

to 4ecure them... Mo4t of u4 would agree that thi4 i4 the wrong

approach.

Securit@ i: :omething @ou do continuou:l@ anddiligentl@; not :omething @ou check o on a to do li:tand then :it )ack and relax

I came into PCI a4 a veteran information 4ecurit: con4ultant with a

Department of Defen4e (DoD) #ackground. I am al4o a trained

cr:ptanal:4t. M: client4 alwa:4 got a health: do4e of 4ecurit:

awarene44 in general. ut I wa4 particularl: intere4ted in educating

them a#out how PCI control4 had come a#out and what the: meant

in other word4, clarif:ing the context. Frequentl:, at the conclu4ion

of the a44e44ment, cu4tomer4 will tell me, That wa4 the toughe4t

a44e44ment [audit] weve ever #een through. ut it wa4 denitel:

worthwhile #ecau4e we need to #e more 4ecure. The PCI 4tandard4

are not perfect, #ut holi4ticall: the: are the mo4t exacting and

comprehen4ive 4et of 4ecurit: control4 I have 4een out4ide of the

DoD. In fact, I #elieve the: 4tand up ver: well a4 a framework for an:

4ecurit: program.

Unfortunatel:, the: are rarel: perceived a4 4uch. The PCI indu4tr:

promote4 thi4 mi4guided approach to 4implif:ing compliance and

reducing 4cope. Yet, too man: companie4 get wrapped around the4e

directive4 and quickl: lo4e 4ight of the #igger picture: 4ecurit:!

Ca4e in point: I often heard from the 4ecurit:/IT folk4 at client 4ite4

that PCI 4tandard4 are onl: a 4tarting point. The: #elieved that PCI

repre4ent4 a #are minimum approach and that a real 4ecurit:-

focu4ed program would go much further and require much more.

However, the 4ame organization4 4truggled to meet all of the

requirement4 and 4ucce44full: demon4trate compliance.

How can a 4tandard deliver no more than the #are minimum, :et 4till

#e dicult to achieve? In large part, it4 #ecau4e 4ecurit: i4 a#out

attitude/po4ture/mind4et/culture rather than the achievement of a

predetermined, perceived 4tate. Securit: i4 4omething :ou do

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

li4t and then 4it #ack and relax. PCI ha4 all the component4 to allow

companie4 to adapt thi4 4tate of due diligence. ut it i4 too

commonl: pre4ented a4 a point-in-time audit #: ju4t a#out ever:

mem#er of the PCI communit:, #e the: QSA4, the PCI Securit:

Council, the merchant4 them4elve4 or the vendor4 4elling the quick

x/ #u: thi4 and :oure done 4olution4.

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

M&RCHANTS AND R&TAIL&RS face immen4e challenge4 with re4pect

to their c:#er4ecurit: po4ture #ut dont often focu4 on the

important element4. For 4tarter4, the: will 4pend an inordinate

amount of time 4truggling to reduce the 4cope of their enterpri4e

that need4 to compl: with the PCI DSS. Then, when the: are found

to #e compliant, the: often di4cover the hard wa: that their #are

minimum approach to PCI compliance ha4 left them 4till vulnera#le

to exploit4 and attack4 #ut even wor4e, the: are not equipped to

detect or re4pond to the attack4. In 4hort, a #are minimum approach

to PCI DSS compliance i4 not what i4 ideal for optimal protection.

Given the4e concern4, con4ider the following m:th4 and

mi4conception4 that are creating further complexitie4:

M@th #1Hard-to-detect, cu:tomized malware targeting :pecic retailer point

of :ale (POS) :@:tem: )ecame much more prevalent in 2013 and 2014

TH TRUTH#&HIND THR&& PC I MYTHS

2

That4 true. ut what thi4 m:th overlook4 i4 that the vulnera#ilitie4

commonl: #eing exploited #: the malware are predominantl: old

vulnera#ilitie4 re4ident in old (often un4upported) operating 4:4tem4

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

4:4tem4 :ear4 ago. Retailer4 are ju4tia#l: concerned a#out the

4ecurit: of their POS 4:4tem4 #ecau4e the: are often #uilt #: a third

part: with em#edded operating 4:4tem4 and di4tri#uted #: the

thou4and4 throughout large geographic region4. Thi4 make4 it hard

to patch the 4:4tem4, appl: anti-viru4/anti-malware 4olution4 (while

making 4ure the: are updated automaticall: and 4canned

periodicall:), in4tall le integrit: monitoring 4olution4, ena#le

logging, cop: the log4 to centralized logging 4erver4, etc. all of

which are activitie4 required #: the PCI DSS.

Vulnera)ilitie: commonl@ )eing exploited )@ themalware are predominantl@ old vulnera)ilitie:

The up4hot: the current variant4 of POS malware wont work if

4:4tem4 are updated, 4ecure and meet PCI 4tandard4.

M@th #2De: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 4ecurit: if the 4tandard4 were

actuall: applied and followed acro44 the enterpri4e, and not limited

to the 4egmented cardholder data environment. Which i4 not to 4a:

#reache4 wouldnt occur, #ut merchant4 would 4ucce44full: detect

and thwart more attempted attack4. ven if attack4 are not

prevented, the intru4ion4 can #e quickl: halted with minimal

damage. The pro#lem i4 that too much time and mone: i4 4pent on

technolog: 4olution4 that purport to do the #oring heav: lifting

and to limit the 4cope of what need4 to #e 4ecured. ut the true

#locking and tackling #a4ic4 of good 4ecurit: require4 dedicated

individual4 to appl: paranoid due diligence a#ove and #e:ond the

call of dut:.

M@th #3There are man@ moving part: of a retail :tore network and man@

t@pe: of u:er: acce::ing them, making it more dicult to :egment the

cardholder data environment from the re:t of the network

There are two pro#lem4 here: Fir4t, PCI DSS doe4 not require

4egmentation, particularl: a4 a 4ecurit: #e4t practice (defen4e-in-

depth) #e:ond the implied three-level architecture common to e-

commerce implementation4. Second, when applied, 4egmentation i4

done for the expre44 purpo4e of reducing the 4cope of the

a44e44ment. It often i4 paired with the idea that we dont have to

4ecure the 4:4tem4 that arent 4u#ject to review. Thi4 attitude even

extend4 #e:ond an: perceived Cardholder Data nvironment to the

4:4tem4 that a QSA 4ample4 ver4u4 the entire 4et of in-4cope

4:4tem4. Im 4ure Im not the onl: QSA who di4covered that a client

didnt appl: mitigation to a pro#lem di4covered during 4ampling

#e:ond the original 4:4tem4 reviewed and the new 4:4tem4

reviewed, if ju4t to prove the point. M: recommendation i4 to

4egment :our network to create 4ecurit:-in-depth, not to limit 4cope;

and appl: the #a4ic PCI DSS control4 acro44 the entire network.

Segment @our network to create :ecurit@-in-depth, notto limit :cope; and appl@ the )a:ic PCI DSS control:acro:: the entire network

Once we clear up the confu4ion #ehind the4e m:th4 and

mi4conception4, it4 ea4ier to o#tain #oth PCI compliance and a

4ecure environment. In the next chapter, Ill recommend ve

guideline4 to help :ou move forward with a PCI-#a4ed c:#er4ecurit:

program.

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

4hare ve recommendation4 for c:#er4ecurit: a44urance and :our

PCI compliance program:

1) Never :eparate PCI compliance from @our

compan@: :ecurit@ program

Man: organization4 make the mi4take of putting PCI in 4ome kind of

#ox, practicall: removed from the 4ecurit: program. ut PCI i4 a

data 4ecurit: 4tandard. How can :ou compartmentalize a framework

that wa4 originall: intended to mea4ure the maturit: of a compan:4

4ecurit: program, particularl: a4 related to the protection of

pa:ment card data? Thi4 approach i4 highl: awed and 4peak4 to the

wa: PCI ha4 #een mi4applied and mi4interpreted.

2) Choo:e an independent QSA (Qualied

Securit@ A::e::or) to audit @our :@:tem:

Companie4 need to hire PCI a44e44or4 who are experienced

FIV RCOMMNDATIONS

FOR PC I COMPL IANC& AND CY#&RS&CURITY

3

information 4ecurit: profe44ional4 and trul: under4tand the

pa:ment card indu4tr: 4ecurit: requirement4. Not CPA4 who

#ecame auditor4 and la4t week were conducting audit4 again4t

Sar#ane4-Oxle:, Gramm-Leach-lile: Act, Health In4urance

Porta#ilit: and Accounta#ilit: Act, or 4ome other regulator:

4tandard. eware of certication4 a4 well; a CISSP doe4 not an

information 4ecurit: profe44ional make.

There are potential conict4 of intere4t if a QSA compan: al4o

provide4 additional managed 4ecurit: 4ervice4 or remediation

4ervice4. While reputa#le companie4 t thi4 model, a4k :our4elf: doe4

the QSA reall: have :our compan:4 #e4t 4ecurit: intere4t4 in mind,

or i4 he reall: up4elling other 4ervice4?

3) Pa@ attention to what the PCI Data Securit@

Standard (DSS) alread@ require: or :trongl@

recommend:

Man: article4 coun4el :ou on what to do over and a#ove :our PCI

compliance initiative4 to en4ure that :ou are 4ecure and wont #e the

next victim of a #reach. ut :oud #e 4urpri4ed how man: of tho4e

4ugge4tion4 are actuall: alread: addre44ed #: the PCI DSS.

Concentrate on what the PCI DSS #oth pre4cri#e4 and recommend4

and :oull #e well on :our wa: to a full: 4ecure environment a4 well

a4 compliance. In particular:

I4olate cardholder data through network4egmentationSegmentation of cardholder data i4 highl: recommended #: PCI. The

4tandard require4 the implementation of control4 that monitor and

re4trict network trac from point-of-4ale (POS) regi4ter4 and #ack-

oce 4:4tem4. If :oure not alread: doing 4o, :oure #oth in4ecure

and non-compliant.

n4ure that POS 4:4tem4 are 4ingle purpo4eTo provide additional 4ecurit: mea4ure4 to POS 4:4tem4, the

4:4tem4 mu4t alread: #e 4ingle purpo4e. Re4tricting acce44 to US

port4 i4 a great idea and alread: a requirement, #ut con4ider that

mo4t PIN Tran4action Securit: (PTS) / Point of Interaction (POI)

device4 are plugged into the POS 4:4tem via a US port. ven if :ou

di4a#le all other US port4, there 4till i4 at lea4t one for the POI (not

to mention the occa4ional monitor, ke:#oard and mou4e.) What

prevent4 an attacker from unplugging an authorized 4:4tem

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

Council ha4 an4wered thi4 que4tion #: requiring more 4tringent

ph:4ical 4ecurit: control4 for the4e POI device4 in PCI DSS ver4ion 3.

Prevent malware in4tallation and operation u4ingla:ered 4ecurit: mea4ure4PCI DSS 4a:4 that there mu4t #e a la:ered approach to protecting

application4 running on POS regi4ter4 in term4 of external and

internal 4:4tem4. All application4 running on POS regi4ter4 mu4t #e

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

Focu4 on rapid #reach detection and u4e context-awaredata anal:tic4PCI DSS require4 dail: or automated review4 of all 4:4tem and event

log4 to detect maliciou4 activit:. Man: of the recent new4-worth:

#reache4 were not detected in a da: and were not even di4covered #:

the #reached retailer4 them4elve4. Which lead4 u4 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 it4 true that automation and anal:tical tool4 are important,

acquiring and implementing them i4 meaningle44 unle44 :our IT or

IS team4 are actuall: monitoring the tool4, 4tud:ing their output4,

and re4ponding to 4u4piciou4 event4 a4 the: occur.

Over the :ear4, the mo4t 4ecure compan: network4 I have 4een are

the one4 where there are certain individual4 (or team4) that take it

upon them4elve4 to know their network, the #u4ine44 proce44e4

and data ow4, and the overall operation. The: are the one4 mo4t

likel: to notice anomalou4 #ehavior4 either directl: or #:

o#4erving the output4 of tool4 that automate the culling of thi4 t:pe

of data and the: are the one4 that mo4t often 4ave the da: for

their companie4.

5) n:ure that @our :ecurit@ anal@:t team i:

properl@ trained and highl@ valued

O#viou4l:, the4e t:pe4 of individual4 are hard to come #:; the: dont

grow on tree4. The: often are not motivated in the wa:4 that other4

are motivated namel:, it4 not alwa:4 a#out the pa:check. More

often than not, it i4 a#out recognition and appreciation not even

from within the compan: or from management, #ut from their peer4

in the profe44ional communit: at large.

Still, PCI attempt4 to e4ta#li4h a #a4eline of qualication4 for the4e

individual4. PCI doe4 not 4peak to headcount. ut it doe4 require

that dail: operational procedure4 are a44igned to 4pecic

individual4/role4 individual4 who receive adequate, ongoing

training in their area4 of focu4. In addition, individual4 with

incident-handling re4pon4i#ilitie4 require annual 4pecialized

training to learn how to properl: anal:ze and re4pond to incident4

and event4, 4uch a4 when to e4calate. You cant pa: lip 4ervice to

their 4hift length either. The: have to attentivel: monitor and act

upon 4ecurit: alert4. If the:re fatigued, the: ri4k overlooking a high-

priorit: 4ituation.

Reali4ticall:, man: retailer4 out4ource the monitoring and detection

re4pon4i#ilitie4 to managed 4ecurit: 4ervice4 provider4. I dont know

how a merchant can #e a44ured that the provider ha4 4ucient 4ta,

or whether tho4e emplo:ee4 are trained to review and detect

anomalou4 #ehavior (a4 oppo4ed to merel: #eing capa#le of waiting

for an automated alarm.) When :ou out4ource re4pon4i#ilit: for the

4ecurit: of :our network to a third part:, :ou are putting :our

compan:4 life in 4omeone el4e4 hand4. I4 thi4 a 4cal nece44it:?

Perhap4, #ut i4 it reall: more co4t-eective in the long run?

In realit:, the4e ve recommendation4 onl: repre4ent the foundation

of optimal PCI compliance and c:#er4ecurit: operation4. In the next

two chapter4, Ill dig deeper into the detail4 #ehind the #e4t practice4

that :ou mu4t incorporate into all of :our c:#er4ecurit: initiative4.

TO IMPL&M&NT A FULLY R&ALIZ&D c:#er4ecurit: 4trateg: that al4o

meet4 PCI compliance 4tandard4, :ou 4hould incorporate #e4t

practice4 into :our 4ecurit: program. The following guideline4 are

#e4t practice4 that have #een proven over time with man: retailer4

and organization4. Where applica#le, I have al4o li4ted their

reference4 in the PCI DSS.

When educating emplo@ee:, explain the wh@)ehind the whatMo4t of the recommendation4 in thi4 4ection addre44 emplo:ee

awarene44 training (required #: PCI), in addition to putting lter4 in

place to #lock malware-laden email and 4uch. : placing increa4ed

empha4i4 on emplo:ee #ehavior4, :oull 4ignicantl: increa4e the

eectivene44 of :our other eort4. You need to teach emplo:ee4

a#out the #ad thing4 that the: mu4t avoid doing not onl: what

#ehavior4 #ut wh: the: 4hould #e avoided to reduce ri4k. In other

word4, dont re4ort to Dont do it #ecau4e we 4a: 4o lecture4.

ST PRACTICSK&&P ING MALWAR& OUT

4

In4tead, tr: the po4itive approach and engage :our emplo:ee4: You

are a vital contri#utor to our #u4ine44. What :ou do or dont do

impact4 our operation4 ... Dont load up on the FUD factor (fear,

uncertaint: and dou#t). reak it down into 4imple term4.

Here4 how thi4 #e4t practice tie4 #ack to the PCI DSS:

A44ure that application developer4 receive training in 4ecurecoding technique4 PCI DSS 6.5.a, 6.5.c

Train 4tore emplo:ee4 on how to 4pot 4u4piciou4 #ehavior4 andto in4pect POS device4 for evidence of tampering PCI DSS 9.9.3

Provide ongoing 4ecurit: awarene44 training 12.6, 12.6.1, 12.6.2

Provide 4pecialized training to 4ta with 4ecurit: #reachre4pon4e re4pon4i#ilitie4 PCI DSS 12.10.4

Prevent malware in:tallation and operationMalware prevention activitie4 focu4 on ve 4pecic ta4k4:

Re4trict direct acce44 to the cardholder data environment fromthe Internet u4ing 4egmentation and 4trong rewall rule4 PCIDSS 1.1.4, 1.1.6, 1.2

Re4trict out#ound connection4 from the POS and #ack-oce4:4tem4 PCI DSS 1.3.5

Out#ound connection4 4hould #e limited to 4pecic IPaddre44e4 and port4 on tho4e addre44e4 PCI DSS 1.2.1, 1.3.5

Out#ound connectivit: 4hould #e logged, monitored, andreviewed PCI DSS 1.2.1, 1.35, 10.2, 12.10, 12.10.3, 12.10.5

Make 4ure local admini4trator pa44word4 are unique acro44 all4:4tem4 on the retailer network, and 4ucientl: dicult to

gue44 PCI DSS 8.2, 8.2.1, 8.5

Detect )reache: a: quickl@ a: po::i)leThi4 i4 all a#out #eing diligent. The PCI DSS require4 the following

protection4:

Implement centralized logging and monitoring with dail:review PCI DSS 10.1-10.6

Note: Log all 4:4tem4 and event4:

All 4ecurit: event4

vent log4 of all 4:4tem component4 that 4tore, proce44 ortran4mit cardholder data (CHD) and/or 4en4itiveauthentication data (SAD) or could impact the 4ecurit: ofCHD and/or SAD

vent log4 of all critical network component4

Log4 of all 4erver4 and 4:4tem component4 that perform4ecurit: function4 (for example, rewall4, intru4ion-detection 4:4tem4/intru4ion-prevention 4:4tem4 (IDS/IPS),authentication 4erver4, e-commerce redirection 4erver4,etc.)

Implement intru4ion prevention 4:4tem4 PCI DSS 11.4

Implement proce44e4 for the detection of tampering with POSdevice4, to include ph:4ical and logical detection of US port4 PCI DSS 9.9. Note: You cant di4a#le the US port4 on POS4:4tem4 #ecau4e that4 how the PIN Tran4action Securit:(PTS)/Point of Interaction (POI) device4 are t:picall: connected(a4 well a4 monitor4, ke:#oard4, etc.). It i4 e44ential to include

US port4 in the ph:4ical 4ecurit: review of point of 4aleoperation4.

La4tl:, here are a few word4 a#out whiteli4ting 4olution4, which are

in vogue for man: retailer4 a4 a compen4ating control for the

following rea4on4:

A lack of anti-viru4/anti-malware 4olution4 and/or the ina#ilit:to keep 4ignature4 current

An a#4ence of timel: patch management

A lack of le integrit:-monitoring 4olution4

Now that Window4 XP ha4 gone out of 4upport (and em#edded

Window4 XP i4 next), whiteli4ting i4 often proered a4 compen4ation

for the lack of more XP 4ecurit: patche4. In man: ca4e4, I 4u4pect

that man: un4upported XP 4:4tem4 (particularl: POS 4:4tem4) are

alread: woefull: in4ecure #ecau4e the: arent current with the

patche4 that are alread@ availa#le. What if the tru4ted application4were compromi4ed at the 4upplier/vendor facilit:? What if the :et-

to-#e-di4covered-and-exploited vulnera#ilit: can execute within the

authorized parameter4 of the application?

FINALLY, ID LIK& TO ADDR&SS the pro4 and con4 of two technolog:

4olution4 which promi4e to ooad mo4t if not all of the #urden of

PCI compliance for merchant4 large and 4mall. The goal i4 to create

an environment where properl: implemented, the4e 4olution4 would

greatl: reduce the footprint of pa:ment card data (namel: the

primar: account num#er or PAN) that make4 a merchant 4u#ject to

PCI DSS compliance in the r4t place.

Dont mi:: the c@)er:ecurit@ fore:t for the PCIcompliance tree!What are tho4e two 4olution4? ncr:ption4pecicall: point-to-

point encr:ption (P2P) and tokenization. The4e technologie4 are

thought to reduce :cope #: tr:ing to promote the argument that

encr:pted card data (and the token value) i4 not cardholder data

therefore the 4:4tem4 which tran4mit, proce44, 4tore the not-

cardholder data are no longer 4u#ject to PCI control4. ut that4 not

reall: true. Here4 wh:.

ST PRACTICS&NCRYPT ION AND TOK&NIZAT ION

5

ncr@ptionRealit: i4 more complicated than argument4 a#out whether

encr:pted card data i4nt cardholder data, and therefore not 4u#ject

to PCI review. The PCI Securit: Council ha4 made it ver: clear that

encr:pted cardholder data can onl@ #e precluded a4 cardholder data

if the merchant (the council 4a:4 entit:) doe: not have the a#ilit: to

decr@pt the data. Make4 4en4e, right? A44uming that the encr:ption

i4 ro#u4t and cr:ptographicall: 4ound, it4 4afe to a44ume that the

encr:ption work4. The #igge4t pro#lem i4 that mo4t encr:ption

algorithm4 in u4e toda: are :@mmetric algorithm4which mean4

that the ke: u4ed to encr:pt i4 the 4ame ke: u4ed to decr:pt the

cardholder data.

The point-of-interaction (POI) i4 where a con4umer provide4 the

pa:ment card to the merchant in order to extract the primar:

account num#er and other required data (the content4 of the

magnetic 4tripe). Since the merchant i4 in po44e44ion of the POI

device, and the ke: i4 4:mmetric, then the merchant ha4 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 4tandard which addre44e4 thi4: Point-to-Point ncr:ption

(P2P), which take4 place not in4ide the POS 4:4tem #ut within the

PTS POI device (i.e., the pin pad or the card reader) if and onl@ if the

reading of the magnetic 4tripe data and the encr:ption of 4aid data

occur4 within a hardware encr:ption module that i4 em#edded

within the device. Thi4 ha4 #een deemed 4ucient to take the

encr:ption ke:4 out of the hand4 of the merchant and to invoke the

4tatement, the encr:pted data i4 not cardholder data. And the

authorized decr:ption ha4 to #e out of the hand4 of the merchant a4

wellt:picall: the re4pon4i#ilit: of a pa:ment gatewa: or proce44or

who in turn tran4mit4 the data onto the #ank4 for authorization.

The r4t certied P2P 4olution onl: #ecame availa#le in Octo#er

2013, and a4 of the date of thi4 document there are 4till ver: few

compliant 4olution4 li4ted. Unle44 :ou are u4ing one of the validated

4olution4, :ou a4 a merchant dont get to make the it4 not

cardholder data 4cope-reducing claim. (If :ou have a 4olution

alread:it4 likel: happening in memor:. And gue44 what? That4

where all the memor:-4craping malware weve #een reading a#out i4

equall: adept at 4tealing the data.)

I am a certied cr:ptanal:4t who u4ed to work for the DoD, and I can

tell :ou that encr:ption i4 dicult to implement eectivel:. What i4

u4uall: the downfall of cr:ptographic 4olution4 involving

encr:ption i4 the implementation of the 4olution it4elf. Ca4e in point:

the OpenSSL Heart#leed vulnera#ilit:. There wa4 nothing wrong

with the encr:ption, no weak algorithm4 that could #e #rute-forced;

even the ke: management wa4 not in que4tion. What we 4aw with

the Heart#leed vulnera#ilit: i4 the perfect 4torm of how

implementation of a 4ecurit: protocol wa4 completel: compromi4ed

#ecau4e of a #ug in one of the component part4, which left the data

that wa4 4uppo4ed to #e tran4mitted 4ecurel: totall: expo4ed

#ecau4e an attacker could recover the ke:4 u4ed to create the 4ecure

connection in the r4t place.

Hacker4 dont t:picall: tr: to #reak encr:ption; the: do a couple

other thing4 that are ju4t a4 eective. Fir4t, the: tr: to 4teal the ke:4

4o ke: management/ke: 4ecurit: #ecome4 paramount. So with

4omething like P2P, thi4 i4 prevented on the front-end (POI) #: the

u4e of em#edded cr:pto; what remain4 i4 the #ack-end where

decr:ption occur4. That4 not technicall: the merchant4 pro#lem.

ut it i4, #ecau4e the up4tream entit: which i4 doing the decr:ption

i4 a 4ervice provider to the merchant and i4 4u#ject to PCI

compliance. All the complexitie4 of compliance remainthe #urden

ha4 4impl: #een 4hifted one-o to a third part:. The other common

practice for hacker4 attempting to circumvent encr:ption i4 to

exploit weakne44e4 in the implementation of the cr:ptographic

4:4tem4 them4elve4. Thi4 i4 the primar: rea4on wh: :ou wont get a

4traight an4wer to If I u4e encr:ption will I #e 4ecure? and wh: :ou

get a repl: 4uch a4 it depend4 or the devil i4 in the detail4 or if it4

implemented correctl:.

Speaking of implementation, encr:ption i4 not onl: required for the

4torage of cardholder data #ut al4o for tran4mi44ion of data over

open, pu#lic network4. Thi4 i4 commonl: accompli4hed u4ing the

Secure Socket4 La:er (SSL) protocol. Thi4 protocol initiall: perform4

a hand4hake with a pu#lic ke: (certicate) that provide4 a 4ecure

method of 4haring a 4:mmetric 4e44ion ke: and ultimatel: encr:pt4

the entire communication. Until recentl:, SSL wa4 4o commonl:

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

technolog:. However, recent di4clo4ure4 of weakne44e4 in the SSLv3

protocol have forced the PCI Council to pu#li4h a revi4ed ver4ion of

the PCI DSS (v3.1) which 4tipulate4 that SSL ma: no longer #e u4ed in

an: 4:4tem4 that are part of the cardholder data environment. Thi4

include4 not onl: we# 4erver4 #ut al4o remote acce44 technologie4

4uch a4 VPN4, other proprietar: remote acce44 technologie4, and we#

interface4 for remote admini4tration of 4:4tem4.

TokenizationTokenization i4 a great wa: to improve 4ecurit: #: reducing the

touch point4 of cardholder data. It doe4 a great jo# of eliminating

incidental acce44, cop:ing, 4torage and the 4tockpiling of cardholder

data #: well-meaning emplo:ee4 who inadvertentl: create a PCI

compliance nightmare. However, if there are folk4 within the

compan: who have to 4ee the cardholder data, the: will need to

launch a de-tokenization procedure. ut how doe4 the 4:4tem

perform de-tokenizationparticularl: how doe4 it provide

authentication and authorization to the right people? That4 a

dilemma that doe4nt 4eem to have an: u4eful 4ecurit: guidance,

other than fuzz: 4tatement4 4uch a4 de-tokenization work4 if it i4

implemented correctl:.

Al4o, doe4 de-tokenization mean that the 4tockpile of token4 i4

meaningle44 data that doe4nt have to #e 4ecured? Or at lea4t not to

the minimal degree required #: PCI? That4 intere4ting, #ecau4e if I

am an attacker, I can a44ume that I have free and open acce44 to all

the token4. Therefore, all that4 left i4 to gure out how to de-

tokenize and voila!Ive 4tolen credit card data. M: target then

#ecome4 the de-tokenization method, and the people (and their

4:4tem4) who u4e the de-tokenization method.

So, I am not comforta#le with di4regarding the token4. In fact, I

#elieve that the rule applied to encr:pted data 4hould #e extended to

token4: If :ou can de-tokenize, it4 4till card data.

Ultimatel:, there are no 4ilver #ullet4, and no 4u#4titute for good

4ecurit:. Which mean4 due diligence reign4 4upreme; :ou mu4t keep

a clo4e e:e on the network and all data ow4. Silver #ullet4 de4igned

to make PCI compliance 4imple or eliminate the need for PCI are

profoundl: irre4pon4i#le. If a vendor make4 4uch promi4e4 to :ou, I

4trongl: 4ugge4t :ou nd another vendor.

Ultimatel@, there are no :ilver )ullet:, and no:u):titute for good :ecurit@

: all mean4, :ou ma: inve4t in P2P and/or tokenization 4olution4

#ut do 4o for the added level of 4ecurit: complexit: :ou introduce

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

compliance a44e44ment. Finall:, dont write-o or di4mi44 the PCI

DSS 4tandard4. Recognize them for what the: are (and arent) and

leverage the PCI compliance proce44 to make :our organization a4

4ecure a4 it need4 to #e. Sta: vigilant!

CHD - cardholder data

DoD - Department of Defen4e

DSS - Data Securit: Standard

IDS - intru4ion-detection 4:4tem4

IPS - intru4ion-prevention 4:4tem4

P2P - Point-to-Point ncr:ption

PAN - Primar: Account Num#er

PA-DSS - Pa:ment Application Data Securit: Standard

PCI - Pa:ment Card Indu4tr:

GLOSSARY

G

PCI DSS - Pa:ment Card Indu4tr: Data Securit: Standard

POI - Point of Interaction

POS - Point-of-Sale

PTS - PIN Tran4action Securit:

QSA - Qualied Securit: A44e44or

SAD - 4en4itive authentication data

A)out Je Man

Je ha4 compiled a rich knowledge #a4e

in cr:ptograph:, information 4ecurit:,

and mo4t recentl: PCI. With PCI

impacting nearl: ever: #u4ine44

vertical, he ha4 4erved a4 a QSA and

tru4ted advi4or for #oth VeriSign and

AT&T Con4ulting. A4 an NSA

cr:ptographer, he over4aw completion

of 4ome of the r4t 4oftware-#a4ed cr:pto4:4tem4 ever produced for

the high-prole government agenc:. Je i4 currentl: a Tena#le

Strategi4t, 4pecializing in compliance. Je oer4 over 30 :ear4 of

information 4ecurit: experience and knowledge to help cu4tomer4

align Tena#le product4 and 4ervice4 with the 4ecurit: #e4t practice4

that are the foundation of all indu4tr: and regulator: 4ecurit:

4tandard4.

AOUT

A

A)out Tena)le Network Securit@

Tena#le Network Securit: provide4 continuou4 network monitoring

to identif: vulnera#ilitie4, reduce ri4k and en4ure compliance. Our

famil: of product4 include4 Securit:Center Continuou4 View,

which provide4 the mo4t comprehen4ive and integrated view of

network health, and Ne44u4, the glo#al 4tandard in detecting and

a44e44ing network data. Tena#le i4 relied upon #: man: of the

world4 large4t corporation4, not-for-prot organization4 and pu#lic

4ector agencie4, including the entire U.S. Department of Defen4e. For

more information, plea4e vi4it tena#le.com.

Note

Some of the following material originall: appeared in the Tena#le

log or in Wired InnovationIn4ight4 #log.