PCI COMPLIANCE GUIDELINESThoroughly Explained2018

www.LBMCInformationSecurity.com

Introduction

Chapter 1:

Chapter 2:

Chapter 3:

Chapter 4:

Chapter 5:

Chapter 6:

Conclusion

2

3

6

9

12

14

16

21

CONTENTS

About LBMC Information Security22

Glossary23

What is PCI DSS? How did it get started, and why is it important?

How does the Report on Compliance process work, and where is PCI heading in the future?

How do merchants demonstrate PCI compliance?

How can businesses assess their compliance readiness?

How can merchants secure their card data effectively and close compliance gaps?

PCI Version 3.2.1 – What’s New?

1

INTRODUCTION

If you store, process, or transmit credit card data, yourbusiness is subject to the Payment Card Industry DataSecurity Standards (or PCI DSS), a set of security rulesdesigned to curb costly breaches and thefts across theindustry.

There are a lot of myths out there about PCI – and thosemyths can lead merchants to make costly mistakes. In thisguide, we’ll explore exactly how the PCI DSS works, why itmatters, and how to make compliance as smooth aspossible.

2

CHAPTER 1:

The PCI DSS consists of over 300individual requirements, and everymerchant — from mom and popsoda shops to big- name chainretailers — must abide by everysingle one of those requirements.But many merchants misunderstandthe rules: how they work, whoenforces them, and why they matterin the first place. In fact, it mightsurprise you to learn the many typesof organizations to whom PCIapplies. PCI also applies to serviceproviders. The PCI Council defines aservice provider as: a business entitythat is not a payment brand that isdirectly involved in the processing,storage, or transmission ofcardholder data on behalf ofanother entity. This also includescompanies that provide services thatcontrol or could impact the securityof cardholder data.

So the first step in compliance isclearing up any confusion as towhether or not PCI applies to yourorganization, and, if so, how itapplies.

What is the PCI DSS, exactly, andwhat makes it so important?

WHAT IS PCI DSS?

STANDARD ORIGINSIn the early years of the 21st century,the major credit card brands faced arising tide of fraud for which theyheld primary liability. Consumerswere liable to card issuers for up tofifty dollars, but the brands wereresponsible for any furtherfraudulent charges — and this wasbecoming a significant expense.

The major card brands decided tocompel change at the merchant-levelby creating standard security rules toprevent thefts both physical anddigital. Initially, each of the cardbrands implemented their own(sometimes inconsistent) sets ofrules, including:✓ The Visa Cardholder Information

Security Program (CISP)✓ The MasterCard Site Data

Protection (SDP)✓ The American Express Data

Security Operating Policy (DSOP)

3

Just keeping the acronyms andabbreviations straight could be achallenge! Unsurprisingly, thedifferent sets of rules created aconfusing tangle of compliancerequirements for merchants. So in2004, the card brands workedtogether to create a singleinformation security standard: thePCI DSS. In 2006, the brands allpitched in to create the PCI SecurityStandards Council, an independententity charged with developing,managing, and educating merchantsand banks on the standards.

And that brings us to the next keypiece of the standards puzzle: theacquiring banks (or “acquirers”),charged with ensuring compliancewith the PCI DSS.

MANAGING RISKThe PCI Security Standards Councildoesn’t fine non-compliantmerchants. In fact, it isn’t responsiblefor merchant compliance at all – theCouncil simply issues and updatesthe PCI standards on a regular basis.Many companies believe that the

card brands themselves assess thefines for non-compliance, but in fact,the card brands hold acquiringbanks responsible for theirmerchants’ compliance — and thosebanks, in turn, may assess fines onmerchants at their discretion. As aresult, different banks may choose toenforce the PCI DSS differently,though the PCI Security Standardslay out certain reportingrequirements based on a merchant’scard volume. We’ll cover those ingreater depth in Chapter 2.

It’s natural for many merchants toview the PCI DSS as a chore to bechecked off as quickly as possible.While this approach may fulfill therequirements on a superficial level, itmisses the underlying opportunity toreduce risk more effectively and gainthe most benefit from theinvestments made in securitycontrols and protections. Today, thePCI DSS can be most constructivelydescribed as an evolving set of bestpractices for security.

4Chapter 1: What is PCI DSS?

5

The best reason to put security standards in place is because you haveperformed risk assessments and set out to reduce your risk to an acceptablelevel, managing risk for its own sake. By approaching the PCI DSS in the spiritof best security practices, you can use it as expert guidance on security foryour business and your consumers.

In the following chapters, we’ll show you how to do just that.

“The best reason to put security standards in

place is because you have performed risk

assessments and set out to reduce your risk to

an acceptable level, managing risk for its own

sake .”

Chapter 1: What is PCI DSS?

CHAPTER 2:

The PCI Security Standards identifyfour merchant levels, based on thenumber of credit card transactionsyou process.

Understandably, many merchantsinitially worry and wonder aboutwhich level applies to them. But thefact is, it doesn’t really matter whichmerchant level you fall under, atleast on a practical level, becausemerchants must comply with all ofthe PCI requirements regardless oftheir merchant level. All that mattersis the reporting style your acquiringbank requires.

SAQ OR ROCThe term acquiring bank (alsoacquirer, or merchant bank) is usedto refer to the bank that processescredit card transactions on behalf ofa merchant. At minimum, anacquiring bank will expect anymerchant to fill out a self-reportingquestionnaire, called the Self-Assessment Questionnaire (SAQ), onan annual basis. This information iswhat the PCI Standards themselvesrequire of Level 2, 3, and 4merchants, which includes the vastmajority of businesses.

DEMONSTRATING PCI COMPLIANCE

This questionnaire includes yes-or-no questions corresponding to all300+ PCI compliance regulations. Amerchant must answer “yes” or “notapplicable” to every single questionto be in compliance. In the event of abreach, both merchant and acquirerwill have to hope the questionnairehas been filled out correctly;otherwise, they may still be subjectto fines. Mistaken answers, made ingood faith, are unfortunatelycommon.

Some acquirers require moreexacting reporting — specifically, aformal Report on Compliance (orRoC) from a certified auditor. The PCISecurity Standards Council certifiesthird-party security firms as QualifiedSecurity Assessors (QSAs), which iswhat we are at LBMC. We helpmerchants verify that they are ingenuine and complete compliance,and we help them report thatcompliance to acquiring banks andother interested parties.

6

As far as the PCI Security Standardsare concerned, only Level 1merchants (typically big-name chainretailers) have to submit their Reporton Compliance to demonstrate theircompliance status. But manyacquirers require a RoC for smallermerchants, depending on risk andother circumstances.

For acquirers, RoCs can limit riskconsiderably, because a RoCrepresents a third party’s validationof your PCI compliance status, andmany banks take advantage of theopportunity to require thatindependent validation of yoursecurity posture. This is whydetermining your merchant level canbe a bit beside the point: what you’llneed to do depends entirely on youracquirer’s expectations, which maybe more stringent than your leveldictates. If you’re choosing anacquirer, it’s wise to find out whatthey expect for PCI compliance rightup-front.

GETTING YOUR BASES COVEREDNow we’ve got a comprehensivepicture of all the players involved inPCI compliance regulations: The PCISecurity Standards Council, backedby the major card brands, maintainsevolving rules, which acquiring banksenforce upon their merchants.Acquiring banks require either a Self-Assessment Questionnaire or aReport on Compliance, the latter ofwhich is supplied by a QualifiedSecurity Assessor. Acquirers may befined for out-of-compliancemerchants, and may in turn assessfines to the merchant. If a securitybreach occurs at an out-of-compliance merchant, there are alsopenalties assessed to the acquirer,which will likely be passed on themerchant as well.

It’s worth noting that at no pointdoes the government enter theequation. You won’t go to jail fornon-compliance with PCI. (If yourepeatedly flout the rules, you canlose the ability to accept creditcards.) PCI isn’t a law — it’s anindustry-created,

7Chapter 2: Demonstrating PCI Compliance

industry-maintained, and industry-enforced set of regulations. In fact, it’smore granular and prescriptive than comparable government standards likeHIPAA.

Merchants, acquirers, and security experts help to move the guidelinesforward, so as time goes on, once-hazy requirements are clarified. It’simportant to keep up with the PCI requirements regularly to ensure you aremeeting any new or recently clarified control areas. Whether you’re self-assessing or engaging a QSA, the guidelines can ensure that your datasecurity bases are covered.

So how do you start a compliance assessment? In the next chapter, we’llrun through the steps.

8Chapter 2: Demonstrating PCI Compliance

CHAPTER 3:

How can businesses go aboutmaking a thorough assessment oftheir compliance posture?

Even if you’ve already completed aself-assessment questionnaire, evenif you believe in your heart of heartsthat you’re compliant, it’s wise tohave PCI security experts perform areadiness assessment at least once.This process will help you verify thatyou’ve read the PCI DSS rulescorrectly and that your assumptionsare indeed correct.

It is common for merchants tomisinterpret language andmistakenly indicate compliance. Areadiness assessment can help youself-evaluate more confidently in thefuture and help you learn moreabout how and why your securitymeasures work, as well as identifywhen they don’t work. Often, theassessment reveals opportunities tomanage your security more robustlyand cost-effectively in the future.

PCI READINESS ASSESSMENT

THREE STEPS TO READINESSWhat, then, does a typical readinessassessment entail? It consists ofthree steps:

Where in your business process iscredit card data captured, and howis it handled? An assessor will followthe flow of card data through yournetwork, whether it travels to adatabase or a third-party site. They’llalso conduct a thorough search forcard data in unexpected places:stored in a spreadsheet in your file-sharing system, or hanging out onyour email system, for example.

Everywhere card data goes, PCI DSSis the rule of the land. But theopposite is also true: PCI doesn’tcare about systems that don’t have asecurity impact on credit card dataor systems.

9

11: Figure out where cardholder data is stored, processed, or transmitted in your environment.

12: Define the scope for PCI Compliance.

So once you’ve followed the data,you can identify which systems aresubject to DSS rules — and whichones you don’t need to worry about,at least as far as compliance isconcerned. This information mayguide your action plan, which we’lldiscuss in the next chapter, helpingyou save both time and money.

Once you know exactly whichportion of your system is subject toPCI DSS, you can compare the rulesto the reality. In a readinessassessment, this will typically mean aseries of interviews, inspections, andprocess walkthroughs, validating thatall the necessary rules are in place.

AVOIDING THE PITFALLSWhen we perform readinessassessments at LBMC, we seecertain problems crop up again andagain.

For example, PCI requiresbusinesses to conduct quarterlyinternal vulnerability assessments —this means scanning for missingpatches, default passwords, andother cracks in the armor thatthieves or malware could easilyexploit. When you find a weakness,you’re required to review andremediate results tagged as high-risk. Then you’re supposed to runanother scan that shows theproblem has been addressed.

Often, merchants run the scan butdon’t read it. Or if they read it, theydon’t clean up the problem. Or ifthey clean up the problem, theydon’t run the scan again — and theydon’t document the success. Forevery PCI rule (or “control”), you musthave documentation to beconsidered in compliance. This is aneasy and common rule to fall downon.

So we sit down with merchants andlook at their past scans, as well astheir documentation.

10Chapter 3: PCI Readiness Assessment

13: Identify Gaps between your scope and the requirements.

Then we complete the Self-Assessment Questionnaire with them to identifythe true answers to every question. This helps them accurately andconfidently answer “yes” on each control.

But what about those times when a merchant has to close a gap? Whatstrategies can they use to take action? We’ll explore some effective solutionsin Chapter 4.

“When you find a technical security weakness,you’re required to review and remediate resultstagged as high-risk. Then you’re supposed torun another scan that shows the problem hasbeen addressed.”

Chapter 3: PCI Readiness Assessment 11

CHAPTER 4:

If you’ve performed an assessmentand determined that you’re not incompliance, you know that you’re atheightened risk of breach andpenalty.

So what steps can you take to secureyour data effectively withoutbreaking the bank?

WEIGHING RISKIf your gap assessment wasperformed properly, it will haveidentified your highest risk areas.Naturally, you’ll want to addressthese first, prioritizing vulnerabilitiesthat pose the most danger, exposingyour card data or systems directly.Ultimately, your goal is to reduceyour attack profile and buy yourselftime to ensure that you’vecompletely addressed your securityrisks.

AN ACTION PLAN TO CLOSE GAPS

What is the difference between ahigh-risk and low-risk vulnerability? Ifa merchant stores a card’sauthorization data (CVV codes orTrack Data) after the authorizationprocess is complete, that’s animmediate and first-order violation— and it needs to be rectified atonce.

By contrast, if you simply lack properdocumentation for an otherwise up-to-snuff control...well, that’ll need tobe addressed, but it can probablywait until you’ve fried the bigger fish.

COMPLIANCE STRATEGIESSometimes, the most effective wayto eliminate compliance gaps is tolook at the big picture. In Chapter 3,we discussed how PCI rules apply toa certain scope of a merchant’ssystems: specifically, anywhere thatcard data travels. Often, only a smallnumber of a business’s systemsprocess or store cardholder data,and this creates an opportunity.

To reduce the scope and burden ofPCI compliance, you can separateyour systems that handle card datafrom everything else — freeing

12

everything else from PCI rules. This issometimes called system andnetwork segmentation. Imagine aphysician’s office, for example;systems related to buildingoperations may have nothingwhatsoever to do with patients’ carddata, so it won’t necessarily makesense to spend the time and moneyto apply the same security controlsthat you would with a paymentsystem. Walling off payment systemsfrom everything else may cost lessthan configuring and enforcing PCI-compliant measures on everysystem.

Sometimes, however, segmentationsimply isn’t practical. At that samephysician’s office, if the vast majorityof computers are connected to bothbuilding operations systems andpayment systems, thensegmentation isn’t going to makemuch sense. The usefulness of thisapproach will depend on thesituation.

THIRD-PARTY PARTNERSMany compliance responsibilitiescan be transferred to third-partyfirms. In fact, a Qualified SecurityAssessor can also provide managedsecurity services or conductpenetration tests, helping you turn

your attention to your business. Likesegmentation, this is a strategy thatshould be considered on a case-by-case basis. For example, smallerorganizations can often make dowith open source software ormanual processes, whereas the costof compliance is often high for largecompanies because of the sheerscope and number of systems intheir cardholder data environment.

It’s important to remember that athird party never takes on fullresponsibility for your compliance.You can’t tell your acquirer,“Someone else is handling it.” You’llhave to coordinate with your partnerto ensure that you have an accuratequestionnaire or RoC. This shouldinclude clearly identifying eachparty’s PCI responsibilities in thecontract with your third party, andregularly checking up on theircompliance efforts.

Which brings us to our final topic:Streamlining the RoC process. We’veseen how self-assessingorganizations can approach PCIcompliance. But if yours is anorganization that requires a Reporton Compliance from a QSA, how canyou make it run more smoothly?

Chapter 4: An Action Plan To Close Gaps 13

CHAPTER 5:

How can businesses streamline theReport on Compliance process? As aQualified Security Assessor, we’veidentified a handful of steps thatmake the process run as smoothlyas possible for merchants.

STEPS TO SUCCESSTypically, a successful RoC processconsists of three basic steps:

For the process to be as efficient aspossible, it needs to be acollaborative process. Try to identifyand partner with a QSA thatdemonstrates a solid understandingof your business environment. TheQSA should also be able to explainits fieldwork protocol clearly.

PCI AUDIT: STREAMLINING THE REPORTON COMPLIANCE (ROC) PROCESS

A Report on Compliance requiresdocumentation for every control —which adds up to quite a lot ofdocumentation indeed. Look foryour QSA to give you plenty of timeto get the documents together. Fourto six weeks is an appropriateamount of lead time.

A QSA should schedule interviewswith your key personnel a few weeksbefore they come on-site, so theycan be conscious of your people’stime while gathering the data theyneed. Regular communication isfundamental, so when the QSAidentifies areas of noncompliance,you can address it as quickly aspossible. As long as an issue isaddressed before the QSA writes itsreport, you should get credit forcompliance. Make certain that youhave a key internal contact regularlymanaging potential issues and

14

11: Identify a Collaborative QSA.

12: Get the documents in order.

13: Talk ahead of time.

handling requests for artifacts ordocumentation from your QSA sonothing falls through the cracks.

What you don’t want in a partner is aQSA that flies out an assessor whospends a few days onsite (or no timeat all), never speaking to you beforeor after. Find a partner who caneducate you throughout the processand that is willing to transferknowledge to your internal team soyou can stay on top of PCI in thefuture. Remember the spirit of PCIDSS is to instill best securitypractices in your company and helpensure that they become apermanent part of your operations.A good partner can help youstrengthen your security and yourconfidence.

LOOKING FORWARDAs we discussed in Chapter 2, thePCI DSS is an evolving set ofstandards. Among the mostimportant rules for choosing a QSAis finding an organization that is intune with the direction of thestandards, and can help you preparefor the future — not simply check offthe boxes for today. For merchantscurrently tracking their securitymeasures to today’s version of theDSS, it would be wise to identify

items they will need to change asnew versions are announced. An up-to-date QSA will help you be future-aware.

The overarching trajectory of PCIDSS is to help organizations get tothe point where security as a whole,including PCI compliance, is businessas usual. The priority shouldn’t begetting your acquiring bank off yourback — rather, you want athoughtful security strategy topermeate your organization,managing risk for its own sake.

15Chapter 5: PCI Audit: Streamlining the Report on Compliance (RoC) Process

“Remember, thespirit of PCI DSS is toinstill best securitypractices in yourcompany and helpensure that theybecome apermanent part ofyour operations. Agood partner canhelp you strengthenyour security andyour confidence.”

CHAPTER 6:

The newest version of the PCI DSS,version 3.2,1, was released in June2018. It represented a minor updateto the last major version update thatwas released in May 2016 (3.2).After a grace period to allow for theplanning and adoption of some ofthe more rigorous changes from thelast major update, the requirementswent into full effect on February 1,2018. You can find the very latestinformation on PCI compliancedirectly from the PCI Council:https://www.pcisecuritystandards.org/

Most of the changes in the latestversion impose additional securityrequirements and checkpoints foroutside service providers. Serviceproviders often have access to manydifferent organizations’ cardholderdata systems, and therefore are agood target for attackers.Compromising a single serviceprovider can offer access tocardholder data from many otherentities. Many high-profile breaches,such as Home Depot and Target,originated with a third-party serviceprovider. Here are some keychanges, with the associated PCI DSS3.2 reference number:

PCI VERSION 3.2.1 – WHAT’S NEW?

All merchants and service providersmust use multi-factor authenticationfor all non-console administrativeaccess into the Cardholder DataEnvironment (CDE). This means thatall administrative logins to CDEsystems, regardless of whether theyoccur from outside the network orfrom an office location on the entity’sprivate network, must use multi-factor authentication for every login.This change will likely require asignificant effort from manyorganizations that have typicallyutilized multi-factor authenticationfor remote access only.

While technically a new requirementin version 3.2, this specificationsimply requires that an entity ensurethat all changes to in-scopecomponents include all PCIrequirements, and that applicabledocumentation be updated uponcompletion of the change.

16

11: Multi-Factor Authentication – 8.3.1

12: Change Control Process Validation – 6.6

While organizations would have hadto complete this activity anyway inorder to be PCI compliant, theaddition of the control requirementsimply formalizes their efforts andserves as a reminder of the need toensure that all bases are coveredwhen making changes to the CDE.

Secure Sockets Layer (SSL) and earlyversions of the Transport LayerProtocol (TLS) encryption protocolsare no longer considered secure,and must be removed from use inthe PCI CDEs and replaced withcurrent versions. The PCI Council hasadded an appendix (A2) to the PCIv3.2 documentation. Thissupplemental information providesclarity about how to addressmigrations to TLS 1.1 or higher.

The remaining “evolvingrequirements” summarized beloware applicable to service providers.

Service providers are required toimplement a process for the timelydetection and internal reporting (notto customers!) of critical securitycontrol system failures, including butnot limited to:✓ Firewalls and IDS/IPS✓ FIM✓ Anti-virus✓ Physical access controls✓ Logical access controls✓ Audit logging mechanisms✓ Segmentation controls (if used)

This requirement is intended toensure that security monitoringcontrols (that were already requiredto be in place) are functioning asintended and that alerts,notifications, and any instanceswhere the controls did not functionas expected are identified andpromptly addressed.

17Chapter 6: PCI Version 3.2.1 – What’s New?

13: SSL Clarification

14: Reporting Security Control Failures – 10.8.1

If service providers are using anetwork segmentation strategy, asdiscussed in Chapter 4, they mustconfirm PCI DSS scope byperforming penetration testing onsegmentation controls at least everysix months, AND after any changesto segmentation controls/methods.This can be done by a qualifiedinternal employee or third party whois experienced in penetration testing.

Outside service providers arerequired to perform reviews at leastquarterly to confirm personnel arefollowing established securitypolicies and operational procedures.The reviews must cover the followingprocesses:✓ Daily log reviews✓ Firewall rule-set reviews✓ Applying configuration standards

to new systems✓ Responding to security alerts✓ Change management processes

The intent here is for serviceproviders to ensure that PCI DSSbecomes “business as usual” in theirorganizations, and that theexecution of control processes is notdone simply to satisfy PCIrequirements, but rather as a regularoperations activity.

Service providers must keep adocumented description of thecrypto-architecture used to protectcardholder data. This helpsmerchants understand how a serviceprovider is encrypting and protectingcardholder data, on their behalf.

18Chapter 6: PCI Version 3.2.1 – What’s New?

15: PCI DSS Penetration Testing to Confirm Scope –11.3.4.1

16: Quarterly Reviews –12.11

17: Security Documentation – 3.5.1

Executive management from third parties must establish responsibility forthe protection of cardholder data and a PCI DSS compliance program thatincludes:✓ Overall accountability for maintaining PCI DSS compliance✓ Defining a charter for a PCI DSS compliance program and

communication to the service provider’s executive management

The intent with this requirement is to ensure that the executivemanagement team of a service provider understands and accepts itsresponsibility for designing, operating, and maintaining a PCI-compliantservice.

19Chapter 6: PCI Version 3.2.1 – What’s New?

18: Executive Management Responsibilities – 12.4.1

SUMMARY OF PCI v3.2.1The revision was published May 17, 2018. The Council has emphasized thatthe revision will be minor and that “there will be no new requirements in thisrevision.”

Rather than introducing new requirements, PCI DSS v3.2.1 is intended“remove the effective date introduced in version 3.2 for several newrequirements and the Secure Sockets Layer (SSL)/early Transport LayerSecurity (TLS) migration requirements.”

As you may know, there were specific new requirements in version 3.2 thatspecify an adoption date of February 1, 2018. These dates have now passedand version 3.2.1 simply removes this wording.

In addition to updating the language around these requirements, therevision is intended to “fix minor typographical errors, punctuation, andformat issues.”

On the whole, PCI DSS v3.2.1 is not a cause for concern. It introduces no newexpectations and falls directly in line with the plan set forth in version 3.2.

20Chapter 6: PCI Version 3.2.1 – What’s New?

CONCLUSIONPCI compliance is complex, but with the right risk management approach itcan be smoothly integrated in your day-to-day operations and become justanother part of doing business.

It’s easy for an employee to accidentally create a rogue wireless accesspoint...but that means your network is vulnerable, potentially allowingintruders to steal card data from the parking lot. It’s easy to forget to installa patch or perform a regular scan. Both of these activities can also leaveyou vulnerable.

Once businesses are aware of, monitoring for, and responsive to the fullspectrum of cybersecurity threats like these, they’ll be prepared to moveconfidently into the future, secure in the knowledge that they’ve protectedtheir customers, their data, and themselves.

21

ABOUT LBMCWhile regulatory compliance is mandatory, so is operating a successfulbusiness. A well-designed information security program provides criticalintelligence about risks facing your business so your executive team canmake well-informed decisions.

As a member of the family of LBMC companies, LBMC Information Securityseparates itself from traditional information security firms by offeringpractical, cost-effective solutions that are customized to your unique riskenvironment. We tailor our assessments and deliverables to yourorganization’s risk tolerance, providing the highest level of risk reduction forthe associated cost. These practical solutions lead to real results and atangible return on investment.

PCI DSS COMPLIANCE SERVICESOur full suite of payments-related data security services helps organizations in every PCI tier achieve compliance today and reduce the risk of non-compliance in the future, including:✓ PCI Readiness Assessment✓ PCI Audit & Report on Compliance✓ PCI Flash Assessment✓ PCI Gap Assessment✓ PCI Consulting (Virtual QSA)✓ PCI Penetration Testing✓ ASV Quarterly Scanning✓ Risk Assessments✓ Web Application Security Pen Testing✓ IDS/IPS Monitoring✓ Cloud-Managed SIEM✓ Card Data Discovery ✓ PCI Training & Education

READY TO DISCUSS YOUR NETWORK SECURITY CONCERNS?Contact us for a free consultation:www.lbmcinformationsecurity.com/contact-us

22

GLOSSARY

TERM

23

DEFINITION

Also referred to as “merchant bank,” “acquiring bank,” or

“acquiring financial institution”. An entity, typically a financial

institution, that processes payment card transactions for

merchants and is defined by a payment brand as an acquirer.

Abbreviation for “attestation of compliance.” The AOC is a

form for merchants and service providers to attest to the

results of a PCI DSS assessment, as documented in the Self-

Assessment Questionnaire or Report on Compliance.

Abbreviation for “Approved Scanning Vendor.” An ASV is a

company approved by the PCI SSC to conduct external

vulnerability scanning services for a merchant or service

provider.

A physical device, often attached to a legitimate card-reading

device, designed to illegitimately capture and/or store the

information from a payment card.

Also known as Card Validation Code or Value, or Card SecurityCode. Refers to either: (1) magnetic-stripe data, or (2) printedsecurity features. (1) Data element on a card’s magneticstripe that uses secure cryptographic processes to protectdata integrity on the stripe, and reveals any alteration orcounterfeiting. Referred to as CAV, CVC, CVV, or CSCdepending on payment card brand.

(2) For Discover, JCB, MasterCard, and Visa payment cards, thesecond type of card verification value or code is the rightmostthree-digit value printed in the signature panel area on theback of the card. For American Express payment cards, thecode is a four-digit unembossed number printed above thePAN on the face of the payment cards. The code is uniquelyassociated with each individual piece of plastic and ties thePAN to the plastic.

Acquirer

AOC

ASV

Card Skimmer

Card VerificationCode or Value

TERM

24

DEFINITION

Abbreviation for “cardholder data environment.” The CDEconsists of the people, processes and technology that store,process, or transmit cardholder data or sensitiveauthentication data, and all other systems that are connectedto the same network.

Compensating controls may be considered when an entitycannot meet a requirement explicitly as stated, due tolegitimate technical or documented business constraints, buthas sufficiently mitigated the risk associated with therequirement through implementation of other controls.Compensating controls must:✓ Meet the intent and rigor of the original PCI DSS

requirement;✓ Provide a similar level of defense as the original PCI DSS

requirement;✓ Be “above and beyond” other PCI DSS requirements (not

simply in compliance with other PCI DSS requirements);and

✓ Be commensurate with the additional risk imposed by notadhering to the PCI DSS requirement.

Technique or technology under which certain files or logs aremonitored to detect if they are modified. When critical files orlogs are modified, alerts should be sent to appropriatesecurity personnel.

Abbreviation for “intrusion-detection system.” Software orhardware used to identify and alert on network or systemanomalies or intrusion attempts. Composed of: sensors thatgenerate security events; a console to monitor events andalerts and control the sensors; and a central engine thatrecords events logged by the sensors in a database. Usessystem of rules to generate alerts in response to detectedsecurity events. See IPS:

Abbreviation for “intrusion prevention system.” Beyond anIDS, an IPS takes the additional step of blocking theattempted intrusion.

CDE

Glossary

CompensatingControls

File IntegrityMonitoring (FIM)

IDS

IPS

TERM

25

DEFINITION

In the context of PCI DSS, it is a method of concealing asegment of data when displayed or printed. Masking is usedwhen there is no business requirement to view the entirePAN. Masking relates to protection of PAN when displayed orprinted.

For the purposes of the PCI DSS, a merchant is defined as anyentity that accepts payment cards bearing the logos of any ofthe five members of PCI SSC (American Express, Discover, JCB,MasterCard or Visa) as payment for goods and/or services.Note that a merchant that accepts payment cards as paymentfor goods and/or services can also be a service provider, if theservices sold result in storing, processing, or transmittingcardholder data on behalf of other merchants or serviceproviders. For example, an ISP is a merchant that acceptspayment cards for monthly billing, but also is a serviceprovider if it hosts merchants as customers.

Acronym for “primary account number” and also referred toas “account number.” Unique payment card number (typicallyfor credit or debit cards) that identifies the issuer and theparticular cardholder account.

In the context of PA-DSS, a software application that stores,processes, or transmits cardholder data as part ofauthorization or settlement, where the payment application issold, distributed, or licensed to third parties.

Abbreviation for “Payment Card Industry Data SecurityStandard.”

Acronym for “point of sale.” Hardware and/or software used toprocess payment card transactions at merchant locations.

Abbreviation for “Qualified Security Assessor.” QSAs arequalified by PCI SSC to perform PCI DSS on- site assessments.

Abbreviation for “Report on Compliance.” A report, issued by aPCI QSA, documenting detailed results from an entity’s PCIDSS assessment.

Masking

Glossary

Merchant

PAN

PaymentApplication

PCI DSS

POS

QSA

RoC

TERM

26

DEFINITION

Abbreviation for “Self-Assessment Questionnaire.” Reportingtool used to document self-assessment results from anentity’s PCI DSS assessment. An SAQ can be completed by themerchant itself or in collaboration with a PCI QSA.

Process of identifying all system components, people, andprocesses to be included in a PCI DSS assessment. The firststep of a PCI DSS assessment is to accurately determine thescope of the review.

Security-related information (including but not limited to cardvalidation codes/values, full track data (from the magneticstripe or equivalent on a chip), PINs, and PIN blocks) used toauthenticate cardholders and/or authorize payment cardtransactions.

A business entity that is not a payment brand, directlyinvolved in the processing, storage, or transmission ofcardholder data on behalf of another entity. This also includescompanies that provide services that control or could impactthe security of cardholder data. If an entity provides a servicethat involves only the provision of public network access—such as a telecommunications company providing just thecommunication link—the entity would not be considered aservice provider for that service (although they may beconsidered a service provider for other services).

Any network devices, servers, computing devices, orapplications included in or connected to the cardholder dataenvironment.

Also referred to as “full track data” or “magnetic-stripe data.”Data encoded in the magnetic stripe or chip used forauthentication and/or authorization during paymenttransactions. Can be the magnetic-stripe image on a chip orthe data on the track 1 and/or track 2 portion of the magneticstripe.

SAQ

Glossary

Scoping

Sensitive AuthenticationData

System Components

Track Data

ServiceProvider

PCI RESOURCESBelow is a list of additional reference material from LBMC’s PCI Security team. Each resourcename may be clicked to go directly to the associated web page.

PLANNING FOR COMPLIANCE• 3 Types of Tasks You Should Document for PCI DSS Compliance• 7 Keys to Comprehensive PCI DSS Documentation• Attaining PCI Compliance With Vulnerability Scanning• 6 Myths About PCI Compliance Regulations• Five Steps for Maintaining Compliance in the Cloud• Penetration Testing and PCI Compliance Requirements• Developing an Effective Security Awareness Program: Physical Security, Password Security,

and Phishing

MANAGING PCI COMPLIANCE COSTS AND RISKS• 3 Ways to Reduce the Costs of PCI Compliance Regulations• Reducing PCI Scope, What Makes Good Network Segmentation? (Our most popular blog post)• How to Explain PCI Compliance Penalties to Beginners• PCI Compliance Fees, Fines, and Penalties - What Happens After a Breach• Why the Target Settlement Should Make Merchants and Consumers Nervous

PCI’S EVER-CHANGING CHALLENGES• PCI DSS Version 3.2: What You Need to Know• PCI Version 3.1 - Changes Coming to SSL• PCI 3.1 Compliance Deadline is Here• What Healthcare Organizations Need to Know About PCI 3.1 Compliance for Mobile Payments

PIN-ENTRY DEVICES• Fast Approaching Deadlines to Ensure Point-of-Sale PIN-Entry Devices are Secure• How Does EMV Adoption Relate to PCI Compliance?• PCI Security Standards Council’s Approved PIN Transaction Security (PTS) Devices

PCI SECURITY STANDARDS COUNCIL RESOURCES• Document Library - PCI DSS specifications, terms and abbreviations, and much more• Completing the Self-Assessment Questionnaire• List of Validated Payment Applications• Point-to-Point Encryption (P2PE) Solutions• Point-to-Point Encryption (P2PE) Applications• Point-to-Point Encryption (P2PE) Components for merchants implementing their own

Merchant Managed Solution – MMS

PCI PAYMENT PROTECTION RESOURCES FOR SMALL MERCHANTS• Guide to Safe Payments• Common Payment Systems• Questions to Ask Your Vendors• Glossary of Payment and Information Security Terms

27

PCI COMPLIANCE GUIDELINES EXPLAINEDCopyright © 2018

Published by LBMC Information SecurityNashville, Knoxville, Chattanooga

All rights reserved. Except as permitted under U.S. Copyright Act of 1976, no part of this publication may be reproduced, distributed, or transmitted in any form or by any means, or stored in a database or retrieval system, without the prior written

permission of the publisher. Design by LBMC. Visit our website at www.LBMCInformationSecurity.com