Archive for the ‘PCI PIN’ Category

Filed Under (Asia-Pacific, Banking, Europe, Merchant, PCI DSS, PCI PIN) by Michael Dahn on June-30-2008

Rob Newby blogs about the statistics and studies on the adoption of PCI compliance in Europe, based on the data points from a Register article with the same focus.  The article states:

European merchants are behind their US counterparts in getting up to speed with the Payment Card Industry’s Data Security Standard (PCI DSS), according to a survey by management tools firm NetIQ.

Rob points out that with a sample population of 65 data points:

… all I can conclude from this survey is that NetIQ customers are ignorant, which isn’t a great advert for them.

There’s a little bit of truth in both opinions (read the NetIQ comments on Rob’s blog.)  It is true that PCI adoption in Europe is slower than that of merchants in the USA, and Asia Pacific is even further, but there a very good reason for this.

You have to factor in that organizations such as APACS has been pushing Chip-PIN for many years now.  France implemented Chip-PIN for the past six years.  This is not to say that the risks are lower, but many different factors play a role.

European PCI DSS Adoption Factors

The first factor is that of education.  Whenever you talk with someone about PCI in Europe this is how the conversation goes:

“I’d like to talk with you about PCI DSS.”
“PCI DSS? What is that?”
“Well it has to do with credit card security…”
“Oh, I don’t need that, I have this Chip-PIN infrastructure.”

It’s hard to get merchants over the fact that they cannot mitigate all the risk of storing credit card data simply by rolling out Chip-PIN terminals.

The second factor affecting merchant compliance in Europe is that in countries such as Spain and Italy a merchant will not have just one or two acquirers but more like 10-12 acquiring banks.  Since each bank only does 1/10 or 1/12 of that merchant’s business it’s a hard business proposition for one of them to take the first step forward and require the merchant to validate their compliance.  The risk is high that a merchant may simply drop that acquirer from their transaction processing channel.

Asia-Pacific PCI DSS Adoption Factors

Within the Asia-Pacific (AP) region merchant adoption of PCI DSS has been slow due to the risk factors.  Each country is different, but as a region the amount of fraud happening “in-country” is rather low.  This means that credit cards compromised and used fraudulently within S. Korea is very low.  The fraud of note is that which is classified as “cross border” fraud.  This is where a credit card compromised within the USA is then used in Australia fraudulently.  Due to these fraud factors, and the historic emphasis on driving service provider compliance within the region, merchants are slower to the game.

That said, I was just in Australia and the number of QSA companies operating in the region is considerably higher both there and in Japan (two of the largest AP countries by transaction volume.)  This increase in auditors shows an increasing demand for compliance validation on behalf of merchants.  Articles that show the “slow” adoption are like trying to buy a car without looking under the hood.  You may look at an older Honda Civic and think you can beat it in a race, but not if it’s got a turbo-charged Acura engine under the hood.

I think the key to remember is that all merchants are at risk and that risk varies by industry, vertical, infrastructure, and so many other factors.  I like Rob’s reminder that:

I am prepared to admit that the spotlight will be on the Tier 1 merchants in the first instance. However, its a bit like relying on everyone else being fatter to avoid heart disease, i.e. stupid.

Popularity: 6% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Approved Scanning Vendor, Card Associations, Merchant, PCI DSS, PCI PIN, PCI SSC, QSA, pa-dss) by Michael Dahn on June-29-2008

In the payments industry there exists the PCI guidelines.  When we refer to PCI we are usually talking about the PCI DSS, although as anyone will tell you there is also the PCI PED, PCI PA-DSS, and others you should be aware of.  But what are the roles and responsibilities within this arena of acronyms?

For many of us we hear things such as PCI DSS, QSA, ASV, SAQ, SAP, and our eyes roll back in our heads.  In fact I was talking with someone to come up with the longest PCI acronym and we came up with head-spinning examples such as “PCI DSS SAQ FAQ”, which is based on the SAP, audited by a QSA.  Baaaaaaaaah!

To clarify some of this we should segment the conversation into compliance documents and validation documents.  The PCI DSS is a set of 12 requirements (the “digital dozen”) that companies must comply with.  If you are a Level 1 merchant (i.e. large company) you are required to validate using the Security Audit Procedures (SAP).  If you are a Level 2-3 merchant (i.e. medium sized company) you are required to validate using the Self-Assessment Questionnaire (SAQ).  Level 4 merchant (i.e. small companies) are not all required to validate, but must comply at all times.

The PCI Security Standards Council (SSC), or the “Council”, is an independent standards body made up of the five participating card brands - American Express, Discover, JCB, MasterCard Worldwide, and Visa Inc.  They oversee the standard itself along with the validation document.  They also qualify a closed list of assessors to perform the PCI audits and the Internet vulnerability scans.  These are called QSAs and ASVs respectively.  More on these later.

The following is a list of documents managed by the PCI SSC:

  • PCI Data Security Standard (compliance)
  • PCI DSS Security Audit Procedures (validation)
  • PCI DSS Self-Assessment Questionnaire (validation)
  • PCI DSS Security Scanning Procedures (for ASVs)
  • PCI PED Standards (compliance and validation)
  • PCI Payment Application Data Security Standard (PA-DSS)
  • as well as endless FAQs, information supplemental, and much more

Other acronyms, include those involved in assisting with the PCI DSS audit.  The Qualified Security Assessor (QSA) includes a list of companies, qualified by the PCI SSC, who assist merchants in validating their compliance against the PCI DSS.  Why would you need one of these companies?  Well, technically, Level 1 merchants can perform the audit with their internal audit department so long as the report is signed off by an officer of the corporation.  The reason companies hire QSAs is for the same reason they hire an external Penetration Tester - expertise and experience.

The Approved Scan Vendors (ASV) include a list of companies, qualified by the PCI SSC, who assist merchants in validating their compliance via the use of Internet vulnerability scans.  Merchants must scan their exposed and in-scope Internet connected systems quarterly and remediate any high risk items.

Roles and Responsibilities

As Martin McKeay aptly noted, we must first understand who is in charge of what before asking questions or making accusations.

The PCI SSC is in charge of setting the rules.  That is it.  They manage the standard, the assessors, and provide information and clarity on both.

The card brands are in charge of enforcement of the standard.  This includes setting merchant levels, service provider levels, and working with the acquiring banks to manage compliance of all merchants.  They also get involved in the event of a compromise.

Now here’s the tricky part - not all card brands are alike.  Visa and MasterCard will never deal directly with a merchant.  Instead they will work through Issuing and Acquiring banks.  Whereas American Express, Discover, and JCB can go either way (working via issuing and acquiring banks or working directly with the merchant.)  Why is any of this important?  Because whoever the merchant’s acquiring bank is, be it Bank of America or American Express, they will define your validation deadline and work with you until you fully validate compliance.

If this still doesn’t make sense or you have further questions be sure to email or call us - both are listed on the homepage of this blog.

Popularity: 8% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (PCI PIN, PCI SSC) by Michael Dahn on February-13-2008

pcissc.gifOn February 11th, the PCI Security Standards Council announced the availability of the Pin Entry Device (PED) approval listing.

The PED Security Requirements are designed to ensure the security of personal identification number (PIN)-based transactions globally and apply to devices that accept PIN
entry for all PIN-based transactions.  The Council has not only taken over responsibility of the PED Security Requirements, but also now maintains the listing of all approved devices and
supporting documents for device makers seeking to ensure their equipment meets this key standard.  It also provides merchants and service providers with a single source of information
on PED equipment that can be used immediately.

Popularity: 25% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (PCI PIN, PCI SSC) by Michael Dahn on February-6-2008

pcico.gifThe PCI SSC announced the release of the PIN Entry Device (PED) standards in conjunction with the latest self-assessment questionnaire (SAQ). The PCI SSC has a long list of resources that you will want to check out, but may be applicable to a shorter list of people.

Remember that the PIN/PED requirements apply to the vendors of these PED devices, but merchants can also see the date their PED devices may expire.  Check out the list of approved PIN Entry Devices and make sure you are using one of those listed. Also, here is a list of the Visa PIN mandates and deadlines.

Popularity: 25% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Card Associations, Merchant, PCI PIN, Payment Applications, Point of Sale, pa-dss) by Michael Dahn on November-7-2007

eftpos.jpgIn early September the PCI SSC added the PIN Entry Device (PED) standard to its dossier of oversight items. Then at the end of September they announced the success of the first ever Community Meeting for Participating Organizations.

Now in early November they start the transition of the Payment Application Best Practices (PABP) from Visa and rename it the Payment Application Data Security Standard (PA-DSS). This follows the heals of the recently released Visa Payment Application Security Mandates.

It is important to focus on this area as it shows a strong push towards the security of smaller merchants (i.e. Level 2-4). It is widely known that many small merchant use similar point of sale (POS) technology and that the greatest risk to those merchants is from the compromise of those systems that store sensitive authentication information.

By turning the best practice document into a standard and then enforcing it with hard deadlines for compliance, the industry is delivering a 1-2 punch to the insecure systems and helping eliminate fraud in the smaller merchant arena.

Popularity: 58% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (PCI PIN, PCI SSC) by pinsecurity on September-15-2007

pcissc.gifWhile it will come as no surprise to regular readers of this blog, the PCI Security Standards Council has officially taken control of the PCI PED standard. The important things to note are that existing certifications will be ‘grandfathered’ into the newly managed system, as will the eight existing PCI PED testing laboratories. It will be interesting to see how this effects the level of understanding that people have of the different PCI standards, as it should expose the PCI PED requirements to a much wider audience.

Popularity: 31% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (PCI DSS, PCI PIN, PCI SSC) by pinsecurity on April-24-2007

pcissc.gifPCI SSC have placed their most recent webinar online for all to access. Unfortunately, watching the webinar requires a viewer to be installed, which is not the way to win this security professionals heart. However, in this case, it is actually worthwhile. Some of the interesting tidbits that were revealed during the hour plus presentation and ensuing discussion:

  • Although the PCI SSC is currently only concerned with the PCI DSS requirements, it will be quickly expanding beyond this.
  • The existing PCI PED standard will be the first addition to this, with a successful vote to include the standard on Feb 20th of this year.
  • The DSS and PED standards will remain separate, unless pressing need is found to join or share parts of them.

This is interesting news. It shows that the PCI SSC is expanding, and looks to be here for the long term. It is probably only a matter of time before we see the PCI PIN requirements absorbed into PCI SSC as well.

Popularity: 31% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Card Associations, Merchant, PCI PIN) by datasecurity on March-19-2007

pinpad.jpgThere has been some conversation about the recent upset of Hypercom by Verifone. I won’t go into details but it involves the Visa USA PIN security requirements and looming deadlines for PIN pad devices.

Remember that PCI is a standard, but each card brand enforces the standard independently.

Verifone has a PDF on PCI requirements for protecting cardholder data. It shows the dates that Visa USA has published for such PIN-base devices. Here are the published deadlines:

  • Effective December 31, 2007, all VisaNet/Interlink endpoint Acquirer Working Keys (AWK) must use TDES. Merchants directly connected to VisaNet/Interlink must meet this requirement.
  • Effective July 1, 2010, all transactions originating at POS PEDs must be encrypting PINs using TDES from the point of transaction to the issuer (end-to-end).
  • Effective July 1, 2010, all POS PED models must be TDES capable and Visa-approved/lab-evaluated.

By 2010 “All POS PEDs must be Visa-approved/lab-evaluated and using TDES to protect cardholder PINs.”

If you purchase a device prior to one of these deadlines, I believe it can be used after the deadline, but non-compliance devices cannot be sold or purchased after the deadline.

Don’t forget about the PIN/PED security requirements. Ask your vendor if they support these new requirements and use this information in making your next POS device.

Popularity: 30% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (Card Associations, Credit Card Fraud, Merchant, PCI DSS, PCI PIN, Service Provider) by datasecurity on March-2-2007

multiplication.jpgI had an IM chat this morning with Martin McKeay asking why everyone feels there are no teeth to PCI compliance. I worked with him on such a project and wanted his feedback. It seems everyone feels there is no monetary reason for large companies to comply. And those who take that stance would be correct - there is no direct cost, but there are indirect costs.

Let’s consider this for a moment. Not to pick on any one, the card brands can fine a merchant for non-compliance with PCI. (Remember that PCI includes the PCI DSS and the PCI PIN requirements.) This means that each card brand can fine a merchant. (MasterCard does not provide fee numbers, so let’s assume they are the same as Visa’s.)

  • Up to $500,000 per incident (PCI DSS)
  • Up to $500,000 per incident (PCI PIN)

Ok, so let’s say that you accept 3 credit card types and you have the worst compromise possible (storage of both Track and PIN block data.) This means your direct fines would only account for $1m x 3 brands = $3m. And don’t forget the proactive fines for non-compliant merchants.

This is a large issue for small merchants and a small issue for large merchants.

Why should large merchants care? I’ve outlined a number of reasons here. It’s all about the multiples. If a small merchant looses 1,000 credit card numbers the re-issuance costs, fraudulent transactions, and remediation costs will all be (relatively) small. They comply because of the fines.

Large merchants may not see the fines as a big issue but they should care about all the things the smaller merchants don’t worry about. If you take class action lawsuits, re-issuance fees, fraud cost recovery fees, credit report monitoring, remediation costs, and possible FTC monitoring and then multiply it by 20 or 40 million cards you end up with a very, very large number.

I am frustrated when people say there is not a big enough stick, because all they read about are the fines. Even after a compromise, TJX only reported having spent $5m on forensics and fines. Nobody ever sees the longer term costs of compliance because what reasonable merchant would ever publicize these numbers?

You cannot fear what you do not know. Educate yourself about the cost of credit card compromise.

Popularity: 40% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]


Filed Under (PCI PIN) by datasecurity on January-18-2007

pin.jpgFrom our favorite Aussie security engineer:

You’ll want to read and be aware of the PCI PIN security requirements:

http://partnernetwork.visa.com/st/pin/pdfs/PCI_PIN_Security_Requirements.pdf

As well as Visa’s specific notes on ‘Symmetric Key Distribution using Asymmetric Techniques’:

http://partnernetwork.visa.com/st/pin/pdfs/PCI_Normative_Annex_A.pdf

If you are based in America, you may also want to be aware of the ANSI Technical Guideline #3:

http://www.x9.org/standards/free/TG-3_final_2006.doc

and also the VisaUSA PED Testing ATM Bulletin:

http://partnernetwork.visa.com/dv/pin/pdf/Visa_USA_PED_Testing_ATM_Bulletin.pdf

Internationally, you’ll want to be aware of the (Visa) global mandates for the use of approved Encrypting PIN Pads, and Triple DES:

http://partnernetwork.visa.com/dv/mandates/main.jsp

Popularity: 17% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]