1163 23c3Security.in.the.cardholder.data.Processing.paperv1.2

8/3/2019 1163 23c3Security.in.the.cardholder.data.Processing.paperv1.2

http://slidepdf.com/reader/full/1163-23c3securityinthecardholderdataprocessingpaperv12 1/8

23c3Securityinthecardholderdataprocessing?!

December2006 ManuelAtug&ThiloW.Pannen Page1of8


ManuelAtugandThiloW.Pannen

SRCSecurityResearch&ConsultingGmbH,Bonn,Germany,[email protected]

Experiencesandlessonslearnedwiththe

PaymentCardIndustryDataSecurityStandard(PCIDSS)

MasterCardandVisahavejointlyreleasedthePCIDataSecurityStandarddefiningsecurityrequire-

mentsfortheprocessingofcarddata.Theaimoftheprogrammesistheprotectionofsensitivecard-

holderdatatofosterthetrustofcustomers,merchantsandtheirserviceprovidersinthepaymentsys-

temsandtolimitprobabilityofcardholderdatacompromises.

SRCisanauditorapprovedbyMasterCardandVisatocarryoutPCISecurityScansandPCISecu-

rityAudits. Currently,SRC servesabout3000merchantsand40 paymentservice providersaroundGermany,Austria,France,Russia,Ukraine,Slovakia,Greece,Israelandothers.

Thestructureofthispaperisasfollows:first,thispaperwillintroducethePCIsecurityrequirements.

Then,thecompany'sexperiencesofseveralhundredsecurityscansanddozensofsecurityauditswill

behighlighted.Finally,anoutlookofthedevelopmentswillbegiven.

1 Introduction

Inviewoftherisingfraudincardpayments,thepaymentschemesMasterCardInternationalandVisa

Internationalhaveinitiatedtheprogrammes MasterCardSiteDataProtection(SDP)andVisaAc-

countInformationSecurity(AIS)inordertoimprovethesecurityofcarddataprocessingandstor-

ageincardprocessingpaymentsystems.

The programmes are targeting members, merchants and service providers that store, process ortransmitcardholderdata.TheyhavetocomplywithoutexceptiontothePaymentCardIndustryData

Security Standard (PCI DSS) which defines the technical and organisational requirements of the

paymentschemes.ThisstandardisalsoendorsedbythecardassociationsAmericanExpress,Din-

ersClub,JCBandDiscover.

EntitiesthatarenotabletodemonstratecompliancewiththePCIDSS(whichcanberegardedasthe

state-of-the-art)atthetimeofacompromisewillfaceindemnityforlosses.

The average losses incurred per card misused fraudulently range between 2.000 EUR and

3.000EUR.Also,afeebetween5EURand15EURmaybechargedforeachcardthathastobere-

issued.Therecouldalsobeadditionalfeesbythepaymentsystemsforinvestigation,litigationand

incidenthandlingforthecompromise.

Anothersignificantandprobablygreaterriskofacompromiseisthelossofreputationandconfidence

ofconsumers.

As wehave seen fromvariouscompromises, businesses also go bust. Theprobably “best” known

exampleisCardSystemsSolutions,acompanythatdiedafteracompromise.

ThePCIDSSconsistsofthefollowingdocuments:

• PCIDataSecurityStandard,

• PCIDSSSelf-AssessmentQuestionnaire,

•

PCIDSSSecurityScanningProcedures,• PCIDSSSecurityAuditProcedures,

accordingto MasterCardandVisa.Thelatestversion1.1wasintroducedinSeptember2006andis

availableathttps://www.pcisecuritystandards.org/ .





Dependingonthenumberoftransactionsperyear,amerchantorserviceproviderwillhaveto vali-

datehiscompliancebymeansofaSelf-Assessment,SecurityScan(s)and/oraSecurityAuditper-

formedbyapprovedauditors(QualifiedSecurityAssessorsresp.ApprovedScanningVendors).

MasterCardandVisacoercivelyenforcedtheimplementationof theprogramSDPresp.AISaccord-ingtothePCIStandardsuntilJune30th2005.

2 ThePCIDataSecurityStandard

The PCI Data SecurityStandardcomprises a set of toolsto ensure the safe handling ofsensitive

cardholderinformation.First,thesensitivedatainpaymentsisdescribed,thenthePCIDataSecurity

Standardanditscomponentsarepresentedinthefollowing.

2.1 Definitionofsensitivecardholderdata

The standard ISO/IEC 7813 “Information technology - Identification cards - Financial transaction

cards ”issuedbytheISO(InternationalOrganizationforStandardization,seehttp://www.iso.org),de-

finesthestructureanddatacontentoff inancialtransactioncards,amongwhichtherearethesensi-

tivedataitemswhichhavetobeprotectedaccordingtothePCIDSS.

ThenextfigureshowstheexampleoftheTrack2magneticstripecontentsaccordingtotheISOstan-

dard.Charactercodesarebasedona5bitmodifiedASCIIformat,thelengthoftrack2canbeupto

40numericdigits.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

PVV DD(incl.CVV)

E

T

X

SVC

S

T

XPAN

S

E

P

EXP

Figure1:Track2dataaccordingtoISO7813

STX: StartSentinel(“;”)

PAN: PrimaryAccountNumber

SEP: Separator(“=”)

EXP: ExpirationDate

SVC: ServiceCode

PVV: PINVerificationValue

DD: Discretionary Data including Card

VerificationValue(CVV)

ETX: EndSentinel(“?”)

2.1.1 FormatofTrack2

PrimaryAccountNumber(PAN)

ThePrimary AccountNumber(PAN)comprises asix-digit IssuerIdentificationNumber(IIN),a vari-

able length(maximum12digits)individualaccountnumberanda checkdigitwhichis computedby

meansofthetheLuhnformula(Mod-10).ThePANcomprisesattheutmost19digits.

CardholderName

Thecardholder’snamecanbe2to26charactersincludingsurname,surnameseparator,firstname

orinitialspacewhenrequired,middlenameorinitialperiod(whenfollowedbytitle),title(whenused).

ServiceCode

Theservicecodeisanumericfieldwiththreesub-fieldsrepresentedbyindividualdigits.Itisusedto

indicatethe issuer’sacceptancecriteriaformagneticstripetransactionsandwhetherarelatedinte-

gratedcircuitsupportingtheequivalentapplicationasidentifiedbythemagneticstripeorembossing

ispresentonthecard.

ExpirationDateTheexpirationdatecomesintheYYMMformat,whereYYrepresentsthelasttwodigitsoftheyear

andMMisthenumericrepresentationofthemonth.





PVV

ThePINVerificationValue(PVV)isadataitemthatthecardholderpossessesforverificationofiden-

tity.ItdoesNOTcontainthePINincleartext,butiscomputedusingcryptographyandverifiedbythe

cardissuerduringauthorisationofatransaction.AccordingtotheISOstandard,thePVVisregarded

asapartofthediscretionarydata.

2.1.2 CVC2/CVV2

ThethreedigitCardValidationCode2(CVC2,MasterCard)orCardVerificationValue2(CVV2,Visa)

isprintedonthecard'ssignaturepanelandshallbeusedforcard-not-presenttransactionslikeMail-

Order/Phone-Order (MOTO) or e-commerce transactions. Presentation of the CVC2 and CVV2

shouldhelpthemerchanttoverifythatthecustomerhastheactualcardathandsduringacard-not-

presenttransaction.Thisdataisnotstoredanywhereelseonthecard.

For AmericanExpress cards, the code isa four-digit unembossed number printed above the card

numberonthefaceofallpaymentcards.Thecodeisuniquelyassociatedwitheachindividualpieceofplasticandtiesthecardaccountnumbertotheplastic.

2.2 PCIDSSrequirementsandcomponents

ThePCIDSSrequiresanyentitytoprotectcardholderdatabyasetoforganisationalandtechnical

measures.

Thestandardappliesto allsystemsandapplicationsthatstore,processor transmitcardholderdata

likeservers,firewalls, routers,wireless access points, network appliancesandother securityappli-

ances.

Whileit isnotallowedtostoreCVC2/CVV2,PVVorfullmagneticstripedataafterauthorisationofa

transactionunderanycircumstances,amerchantorserviceprovidermaystorethePAN,thecard-

holdername,theservicecodeandtheexpirationdate.

Wheneversuchdataisstored,ithastoberenderedunreadablebyoneofthefollowingmeasures:

• onewayhashingofcardholderdata(e.g.SHA,MD5,RIPEMD),

• substitutionofcardholderdatabypseudo-numbercomputedbyindextokensandPADs,

• truncationormaskingofthecardholderdatalike123456xxxxxx7890

• encryptionofcardholderdatawithstrongandpublicmethods(3DES,RSA1024,AES-256).

(AmaskedPANwhichcontainsonlythefirstsixandlastfourdigitsincleartextattheutmostisnot

regardedassensitivedata.)

ThePCIDSScontainstwelverequirementsgroupedundersixheadlines,whichare:

1. BuildandMaintainaSecureNetwork

- Requirement1: Installandmaintainafirewallconfigurationtoprotectdata

- Requirement2: Do notuse vendor-supplied defaults forsystem passwords and

othersecurityparameters

2. ProtectCardholderData

- Requirement3: Protectstoreddata

- Requirement4: Encrypttransmissionofcardholderdataandsensitiveinformation

acrosspublicnetworks

3. MaintainaVulnerabilityManagementProgramme

- Requirement5: Useandregularlyupdateanti-virussoftware

- Requirement6: Developandmaintainsecuresystemsandapplications4. ImplementStrongAccessControlMeasures

- Requirement7: Restrictaccesstodatabybusinessneed-to-know

- Requirement8: AssignauniqueIDtoeachpersonwithcomputeraccess





- Requirement9: Restrictphysicalaccesstocardholderdata

5. RegularlyMonitorandTestNetworks

- Requirement10: Track and monitor all access to network resources and card-

holderdata

- Requirement11: Regularlytestsecuritysystemsandprocesses

6. MaintainanInformationSecurityPolicy

- Requirement12: Maintainapolicythataddressesinformationsecurity

Thisstandarddetailstechnicalrequirementsforthe securestorage, processingandtransmissionof

cardholderdata.

2.2.1 PCISelf-AssessmentQuestionnaire

The PCI Self-Assessment Questionnaire comprises 74 yes/no questions andhasto befilled in by

merchantsorserviceprovidersdependingontheirclassification.

ThepurposeofthePCISelf-AssessmentQuestionnaireistovalidatethecomplianceoftheentitywiththePCIDSS.

2.2.2 PCISecurityScan

TodemonstratecompliancewiththePCIDSS,merchantsandserviceprovidersarerequiredtohave

quarterlyPCISecurityScansconductedasdefinedbyeachpaymentscheme’ssecurityprogramme.

PCISecurityScansarescansconductedovertheInternetandhavetobeperformedbyanApproved

Scanning Vendor in compliance with the requirementsof „PCIDSSSecurityScanning Procedures

1.1“.

ThepurposeofthePCISecurityScan(off-sitevulnerabilityscan)istouncoverwell-knownsecurity

flawsin thearchitectureandtheconfigurationofthesystemanalysedwhichcanbeexploitedtoac-cesscomponentsofthefirewallsystem,serversystemsortheinternalnetwork.

Thesescanshavetobe conducted“non-intrusive”and“non-destructive”sothattheproductionsys-

temsarenotaffected.Therefore,finger-printingtechniquesaremostcommonlyemployed.

Theresultofascanisadetailedreportwhichdescribesthetypeofvulnerabilityorrisk,adiagnosisof

theassociatedissues,andaguidanceonhowtofixthevulnerabilitiesidentified.

The report also categorises the vulnerabilities identified in thescanprocess into fivelevel ranging

from“low”to“urgent”.

ThePCIDSSdoesnotacceptvulnerabilitiesoflevelthreetofive,whichwouldallowanattackerto

gainfullaccesstocardholderdataorcompromisethesystem.

2.2.3 PCISecurityAudit

PCISecurityAuditsareconductedbyaQualifiedSecurityAssessorinaccordancewiththerequire-

mentsof„PCIDSSSecurityAuditProcedures1.1“.

Serviceprovidersorlargemerchantsthatarerequiredtoundergoanannualonsitereview,mustvali-

date compliance on all applications and systems where cardholder data is stored, processed, or

transmitted.

Theauditconsistsofareviewofdocuments(policiesandprocedures)andasiteinspectionduring

whichsamplesaretaken.Alsotheauditorinterviewsselectedpersonneltoscrutinisetheimplementa-tionofthetechnicalandorganisationalmeasuresrequiredbyPCIDSS.





3 TopTensecurityissueswithinthePCISecurityScan

The top ten listof securityissuesprovided inthischapter isbasedontheperformance ofsecurity

scansofseveralthousandIPaddresses.

Ithastobenotedthatthesevulnerabilitiesareclassifiedascritical,i.e.amerchantorserviceproviderwillfailtopassthesecurityscanandtoprovecompliancewiththerequirements.

Pleasenotethatthistoptenlistisasubsetofallvulnerabilitiesdeemedascritical.

3.1 SSLserverhasSSLv2enabled

ThereareknownflawsintheSSLv2protocol.Aman-in-the-middleattackercanforcethecommunica-

tiontoalesssecurelevelandthenattempttobreaktheweakencryption.Theattackercanalsotrun-

cateencryptedmessages.

TheseflawshavebeenfixedinSSLv3(orTLSv1).Mostservers(includingallpopularweb-servers,

mail-servers,etc.)andclients(includingWeb-clientslikeIE,NetscapeNavigatorandMozillaandmail

clients)supportbothSSLv2andSSLv3.However,SSLv2isenabledbydefaultforbackwardcom-patibility.

3.2 SSLserversupportsweakencryption

SSLencryptionciphersareclassifiedbasedonencryptionkeylengthasfollows:

• HIGH-keylengthlargerthan128bits

• MEDIUM-keylengthequalto128bits

• LOW-keylengthsmallerthan128bits

Messages encrypted with LOW encryption ciphers are easy to decrypt. Commercial SSL servers

shouldonlysupportMEDIUMorHIGHstrengthcipherstoguaranteetransactionsecurity.

3.3 OpenSSHlocalSCPshellcommandexecutionSCPisasecurecopyapplicationthatisapartofOpenSSH.Itisusedtocopyfilesfromonecomputer

toanotheroveranencryptedSSHconnection.IfSCPisgivenall-localpathstocopy,itactslikethe

system"cp"command.

OpenSSHissusceptibletoalocalSCPshellcommandexecutionvulnerability.Thisissueisduetoafailureoftheapplicationtoproperlysanitiseuser-suppliedinputpriortoutilisingitina"system()"

functioncall.

IfSCPisusedinanall-localfashion,withoutanyhostnames,itutilisesthe" system()"functionto

executealocalcopyoperation.Byutilisingthe"system()"function,ashellisspawnedtoprocess

thearguments.If filenamesarecreatedthatcontainshellmetacharacters,theywillbeprocessedby

theshellduringthe"system()"functioncall.Attackerscancreatefileswithnamesthatcontainshellmetacharactersalongwithcommandstobeexecuted.IfalocaluserthenutilisesSCPtocopythese

files(likelyduringbulkcopyoperationsinvolvingwildcards),thentheattacker-suppliedcommandswill

beexecutedwiththeprivilegesoftheuserrunningSCP.

3.4 WindowsTCP/IPremotecodeexecutionandDenialofService(MS05-019)

MicrosoftSecurityUpdateMS05-019wasnotinstalled.Thisupdateresolvesdifferentsecurityissues,

e.g.IPValidationVulnerability,ICMPConnectionResetVulnerability,ICMPPathMTUVulnerability,

TCPConnectionResetVulnerabilityandSpoofedConnectionRequestVulnerability.

3.5 Webservervulnerabletocross-sitescriptingattacks

TheWebserverdoesnotfilterscriptembeddingfromlinksdisplayedonaserver'sWebsite.

AmalicioususercanexploitthisvulnerabilitytocauseJavaScriptcommandsorembeddedscriptsto

beexecutedbyanyuserwhoclicksonthehyperlink.Uponclickingthehyperlink,theWebserverwill

generateanerrormessageincludingthespecifiedorembeddedscript.Thespecifiedorembedded





scriptisexecutedintheclient'sbrowserandtreatedascontentoriginatingfromthetargetserverre-

turningtheerrormessage(eventhoughthescriptingmayhaveoriginatedfromanothersiteentirely).

3.6 ManagementInterfacesaccessibleonCiscodevice

ThisvulnerabilityappliestoCiscodeviceswhichuseprotocolssuchasHTTP,TELNET,rlogin,FTP,andSNMPforconfigurationmanagement.Theseservicescanbepubliclyaccessed,andareaninvi-

tationformalicioususerstobreakin.

3.7 CiscoIOSHTTPconfigurationarbitraryadministrativeaccess

CiscoIOScontainsavulnerabilitythatmakesitpossibleforremoteuserstogainlevel15privileges

(theenablelevel,themostprivilegedlevel)onanaffectedCiscodevice.

BysendingacraftedURL,it'spossibletobypassauthenticationandexecuteanycommandonthe

device.Thiswillonlyhappeniftheuserisusingalocaldatabaseforauthentication(usernamesand

passwordsaredefinedonthedeviceitself).ThesameURLwillnotbeeffectiveagainsteveryCisco

IOSsoftwarereleaseandhardwarecombination.However,thereareonlyafewdifferentcombina-

tionstotry,soitwouldbeeasyforanattackertotestthemallinashortperiodoftime.

3.8 Session-Fixationsocialengineeredsessionhijacking

ThisvulnerabilityaffectsaWebapplicationthatusescookies(e.g.sessionIDs)inaninsecureway.

Specifically,thesecurityscannercreateda websessionwiththetargetusinga sessionIDspecified

bythescanneritself.Thetargetapplicationsimplystartedanewsessionwiththisspecifiedsession

ID.Thisissueisgenerallycalled"session-fixation"andisvulnerabletosession-hijackingattacks.

3.9 Webserverusesplain-textformbasedauthentication

TheWebserverusesplain-textformbasedauthentication.Anattackercouldeasilygainaccesstothe

unprotectedauthenticationdata(loginandpassword)byusageofsniffingtechniques.

3.10 MailserveracceptsplaintextcredentialsThe Mail Server responds tothe EHLO command which implies that ituses the ESMTP protocol.

ESMTPusestheAUTHcommandwhichindicatesanauthenticationmechanismtotheserver.Ifthe

serversupportsthe requested authenticationmechanism, itperformsan authentication protocolex-

changetoauthenticateandidentifytheuser.Optionally,italsonegotiatesasecuritylayerforsubse-

quentprotocolinteractions.

TheserveracceptsPLAINorLOGINasoneoftheAUTHparameters.Theauthenticationcredentials

aretransmittedinplaintextoverthenetworkandnoencryptionisperformed.

4 ToptensecurityissueswithinthePCISecurityAudit

ThefollowingtoptenlistiscompiledbySRCauditorsusingtheirexperiencesduringthepreparation

andexecutionofPCIsecurityauditsatcustomers.

4.1 KeyManagement

ThekeymanagementprocessesofthePCIDSSrequiretoprotectthecompletelifecycleofacrypto-

graphickey,beginningatthegeneration,throughdistribution,storage,periodicchangeuntilkeyde-

struction.

Also,thefour-eyesprinciplehastobeputinplacetopreventa„singlepointoffailure“,i.e.nosingle

personcouldgainaccesstoakey.

TheexperienceofSRCshowsthatnoneoronlypartsofthePCIkeymanagementprocessesand

policiesareinplacewhenstartingtheaudit.Also,entitiesdoeithernotfullyunderstandtherequire-

ments,e.g.howto checkfornewlygenerated,weakkeys,ordonotknowhowtoputorganisationalandtechnicalmeasuresinplace(likefour-eyesprinciple).





4.2 Designofnetworkandaccesscontrol

PCIrequirestolimitthepotentialaccesstocriticalapplicationstoaminimum.Thereforeservershave

tobeseparatedbyfirewalls,VLANsorroutersfromthecompanynetworktoreducetheriskofacom-

promise.

Itiscommontohaveonlyasingle,company-widenetworkwhichallowstoconnecttoeveryserver

fromtheLANe.g.from(public)meetingroomtocentralhost.Thisissuecanbeaddressedbyare-

segmentationoftheLANandrestrictionofaccessrules.

4.3 Securitymaintenance

PCIrequiresthatallsystems,systemcomponentsandsoftwarehavethelatestvendor-suppliedsecu-

ritypatchesinstalled.Therelevantpatcheshavetobeinstalledwithin30days.

SRCfoundthatmaintenanceveryoftenfollowsthe“neverchangearunningsystem”approach,which

exposesthesystemstoveryhighrisks.Sometimestheprocessofpatchingasystemisnotconven-

ientforamerchantorserviceprovider,andrequirestore-bootsystemsorswitchintoasingle-user

mode.

Thishesitationtoupdateisveryoftenaccompaniedbythelackofpropertestingfacilities(alsore-

quiredbyPCI).

4.4 Firewallmisconfiguration

PCIrequirestousefirewallsbetweenInternetandDMZandinternalnetworkzones.Alsothefirewall

ruleshavetoemploya“deny-all”policy.Thefirewallmaygrantaccessonlytothoseprotocols,ports

andIPrangesthatarerequiredbybusinessneeds.

SRCfoundmanyexceptionsfromtheseprincipleslike:

• rulesetisnotuptodate,oldruleswerenoteliminated;

• no“denyall”ruleincluded;• unnecessaryprotocolswereabletopassintotheDMZ(P2P,IRC,IDENT);

Veryoften,thereisnotacurrentnetworkdiagramavailable.

4.5 Misuseofcardholderdata

PCIdoesnotallowtouselivecarddatafordevelopmentortestingpurposes.Thisis, unfortunately,

veryoftenthecase,thoughthepaymentsystemsprovidetestcardsonrequest.

4.6 Accesstocardholderdatanotlimited

PCIrequirestolimitaccesstocardholderdataonlytothosewhosejobrequiressuchaccess.This

principle isnotfully enforcedandmany exceptions were found duringtheaudits. Thereasonsare

manifold,sometimes the“I’mthe boss andtherefore need accessto everything”syndrome canbeobserved,inothercasestheaccessruleshavegrownhistoricallyandwerenotshrunk-to-fit.

4.7 Physicalaccess

PCIrequirestophysicallyprotectaccesstocardholderdataortosystemswhichstore,processor

transmitcardholderdata.Thereforesystemcomponentshavetobephysicallyprotectedbydatacen-

trelikemeasures(e.g.CCTV,visitor’sbadgesandlogbook).Alsophysicalaccesstothesecompo-

nentshastoberestricted.Thisisnotlimitedtoelectronicmedia(e.g.harddisks,backuptapes,CD)

butalsoincludesaccesstocardholderdataprintedonpaper.

Thedisposalofanymediahasto besecured bypurging(military wiping),degaussing, incineration,

pulpingorcross-cutshredding.

Veryoften,theseprocessesarenotoronlypartlyimplementedaccordingtoPCIrequirements.Ex-amplesare:racksindatacentreswerenotlocked,nosecuredpaperdisposal,networkjacksinthe

sensitive areas were accessible. Also cardholder data isonly deleted from hard disk, though they

havetobesecurelywiped.





4.8 Internalsecurityscanandpenetrationtests

PCIrequirestocarryoutinternalsecurityscansandpenetrationtestsofsensitiveapplicationsand

systems,inadditionto(external)securityscansconductedbyapprovedscanningvendors.

SRCfoundthateitherthetestsarenotcarriedoutatallor,iftheyarecarriedout,theyoftendonotcomplywithPCIrequirements.

4.9 Intrusiondetectionandfileintegrity

PCIrequirestouseintrusiondetectionsystems(IDS)andfileintegritymonitoringapplications.The

experience of SRCshows that mostmerchantsandserviceproviders were not familiarwith those

systemsandthereforedidnotusethematall.

4.10 Organisationalpoliciesandprocedures

PCIrequiresnotonlytoimplementorganisationalandtechnicalmeasures,butalsotodevelopand

maintainwrittenpoliciesandprocedures.

Examples are: information security policy, password policy, daily operational security procedures,hiring/leavingpolicies,incidentresponseplan.

SRCfoundthatinlargecompaniesthesepoliciesaremainlycommonandputalive,butarenotsub-

jecttoaregularreviewonceimplemented.Ontheotherside,smallcompaniesemploypoliciesre-

quiredwhicharenotdocumented.

5 SummaryandOutlook

The PCI DataSecurity requirements are basedon common senseandindustrybestpractice. Itis

derivedfromtheISO17799(ISO2700x)informationsecuritymanagementstandardandcustomised

totheneedsofthepaymentindustry.

ThoughonecouldhaveexpectedthatmostofthePCIDSSrequirementsarealreadyputinplacefor

vestedinterests,theexperienceandrealityrevealsadifferentpicture.

Thepaymentindustryispushingallentitiesthatstore,processortransmitcardholderdatatovalidate

compliancewiththePCIDSS.Itseemstobeamatteroftimeuntilthefirstentityisstoppedfromac-

ceptingorprocessingcarddatabecauseofnon-compliance.

Theconsolidationinthepaymentmarkethappeningtodayisdrivenbytheneedforinvestmentsin

securitymeasuresandtheincreaseinsecurityrequirementsasthepaymentsystemsareconstantly

monitoringandtrackingtheattacksthattakeplacedaybyday.Theyreservetherighttoquicklyreact

tosecurityincidentsbyraisingthesecuritybar.

Forallthesereasonsitbecomeslessattractiveformerchantstostore,processortransmitcardholder

dataonownsystems,unlessthereisa strongbusinessneed.SRCobservesthatmanymerchants,especiallysmalloneswith,let’ssay,lessthan100.000transactionsperyearandbrand,areincreas-

inglyoutsourcingtransactionprocessingtoserviceproviders.

This development is beneficial to the payment market as the risks of a compromise are reduced.

Cardswillonlybeusedbycustomersiftheyarefullyconfidentinthepaymentsystems.

Merchantswillacceptpaymentcardsonlyifthecostsofacceptancearelow.

PCIDSSseemstobeaneffectivetooltomaintaintheconfidenceofconsumersandmerchantsin

cardpaymentswhichisalsounderpinnedbytheexperiencesofSRC.

Itis likelythatthePCIDSSwillbe amendedinnearfuturebyaso-called“paymentapplicationbest

practices” programme which will require a certification for payment applications. By that, softwarevendorswillbeincludedintotheprogrammesandwillbemandatedtodevelopsoftwarewithregardto

PCIDSS.

Documents

1163 23c3Security.in.the.cardholder.data.Processing.paperv1.2