So if you recall, I received an inquiry the other day to take a bit further my post where I was quacking about credit unions.

As a refresher, the gist of that discussion was that I found it to be somewhat lame that credit unions were complaining about how they have stringent technical controls whereas merchants don’t. My meta-point was that merchants (at least for card-based payments) have some very stringent (i.e. technically prescriptive) security controls by virtue of PCI compliance.  Credit unions, on the other hand, by virtue of their regulatory context, have more “interpretive latitude” in how technical security controls get implemented.  Meaning, they should try on PCI compliance before calling out merchants (especially the big ones) for having it soft.

To get some additional context on this point, I reached out to a former colleague who’s now an auditor for credit unions and community banks.  I’ll keep his name off the record – not because he asked me to necessarily, but because he asked that I not identify his employer… and anybody with a browser and a linkedin account can look at my background, guess who he might be, and determine his place of employment.  So let’s just call him “Papa” – for “Papa Smurf”, his nickname when we worked together.  Anyway, mega-thanks to him for going through this with me.

Anyway, below is the record of the discussion I had with him.  I’ll pull out some of the material that I think highlights or negates my point from earlier in a subsequent post (since we really got into detail and covered a lot of ground in our discussion):

Can you briefly describe the type of work that you do with credit unions?

Typically under contract, what we do is a full-scope risk assessment.  Under the current regulations, a credit union, unlike a bank, does not have to have an IT audit.  They are instead required to have an “IT risk assessment”.  This risk assessment looks at approximately 27 control objectives that come out of COBIT.  The objective is the same as an audit – the difference is that during a risk assessment, you don’t collect work papers and the client is responsible to complete specific areas of a risk assessment themselves.

We have credit unions that request an IT audit over and above a risk assessment.  Audit is basically a “black & white” evaluation exercise (you either “have it” or you don’t – you meet the bar or you do not); An IT Audit is based on COBIT, a methodology from ISACA (Information Systems Audit and Control Association) to evaluate the controls  and how they comply with the FFIEC IT Audit guidelines.  A risk assessment on the other hand is based on the National Institute of Standards and Technology’s (NIST) Special Publication 800-30 and follows the guidance provided in the FFIEC Information Security Booklet to evaluate the risks and safeguards in place to support the bank or credit unions Information Security Program.

How many banks and credit unions would you say you’ve worked with in the past two years?

Probably around 24.  About one per month.

What specifically is required of a bank or credit union with respect to security controls?  What standards do they need to adhere to? 

Credit unions are regulated by the NCUA (National Credit Union Association).  The difference is that credit unions are non-profit.  Regulatory-wise, there’s no difference between a credit union and a bank and from a financial aspect, they both provide services to customers/members and the business community such as loans (car, mortgages), savings, checking, etc.  The FFIEC is the inter-agency chartered to provide guidance to all banking institutions.  FFIEC includes OCC, FRB, Federal Deposit, and the NCUA.  It also used to provide governance to OTS, but that’s gone because there are very few thrifts ( savings and loans – think: “It’s a Wonderful Life”).

In terms of our risk assessments, we take into account items from COBIT as well as guidance from PCAOB in addition to industry best practices.  We use  best practices because they change faster due to technology and procedure than the guidance from the FFIEC and elsewhere.  The fact that it is not FFIEC guidance, doesn’t mean it’s not useful for these organization to consider.  For example, we sometimes use the PCI DSS as a best practice guideline for what these organizations should look to from a best practices standpoint.  The DSS has straightforward questions looking for straightforward responses.

What’s the role of the FFIEC examiner handbook?  How much teeth do those controls have?  How do those rules compare to PCI DSS?

FFIEC guidance is high level in terms of technical content.  While it is called ‘guidance’ they are standards and the banks and credit unions must comply with the guidance. They are examined using the FFIEC as the source document for compliance.  PCI is not a regulatory requirement – it is private enterprise (Visa, MC, Amex) that established specific rules that a card issuer/merchant must follow.  That doesn’t mean that nothing goes wrong – all you need to do is look at the  TJ Max and Hannaford incidents.  Under PCI, card issuers/merchants  are required to comply to the requirements and have an annual PCI audit done by persons certified directly by PCI. More than that, I am not sure – nothing in the PCI documentation indicates you will lose your right to be a card merchant but there must be some ramifications.

What happens when a credit union doesn’t comply?

When a credit union is being examined by the NCU, assuming a  full-scope exam, it would include all areas of IT including BCP/DR, handling of member (customer) information, data at rest/in transit, user (employee) access controls, and LAN/WAN networking.  .  However, in the past few years, my take has been that they are focusing more attention on the financial  side rather than IT.  So when it comes to IT – the credit union gets a pass because areas were not examined but that doesn’t mean when we do an audit or risk assessment we will let it pass – we cannot because of the COBIT, NIST, FFIEC, and other guidance factors.

FFIEC guidance – even though it’s guidance – is required for these organizations to meet it.  Incident response for example, is a requirement.  But there’s some interpretive latitude relative to the degree or depth of that plan.

Is there any “wiggle room” when an organization can’t meet the guidance?

The rule of thumb I use relative to Incident Response is a clause in the FFIEC guidance that speaks to “size and complexity”.  A smaller credit union might not have the same level of technical expertise, IT staffing, or funds to purchase something like enCase (the forensic product) to do investigations; they might not have the money to support it, to train users, licensing fees, etc. – you have to measure their response plan and ability to support it based on what makes sense for an organization their size.

However, BCP/DR for example, requires a  recovery and a continuity plan.  They have to have a plan in place.  On the other hand, there is no regulatory requirement for a bank to have a generator.  When I got into this line of work, I thought there was because it makes sense.  However, there isn’t.  When you have a power outage in an area, you’re not opening your doors.  There’s guidance and then there’s a flaw in the guidance.  There are some that do, but many banks and credit unions do not.

What’s the role of GLBA?

GLBA says that customer information (name, ssn, etc.) otherwise referred to as non-public personal information and it must be protected.  This is information that is not commonly found such as in a telephone bill, a telephone book, or a car rental agreement.  The primary objective of an information security risk assessment is to identify, evaluate, and prioritize threats to information assets and vulnerabilities in the control environment.  The risk assessment represents the foundation of the Information Security Program and is an ongoing process that highlights needed program enhancements.

This entire process requires the bank/credit union to have appropriate policy and procedures in place to provide guidance to all employees on how to handle and control customer (member) information.

Not having formal policy, but having documented procedures isn’t great, but it is a start.  The Board of Directors are expected to develop, or have developed for the bank/credit union, policies that they, the BOD are required to review, and approve and have implemented.  If they don’t, they cannot protect the information properly and I would write it up  a high or medium priority in a risk assessment I’m doing.

Protection of all media (optical, magnetic, or paper) at rest (sitting in a cabinet or database) or in transit (sent from main office to backupsite, etc.) has to be protected as well.  It must be secured such that only persons who need access to it, do.  This is commonly referred to as the rule of least privilege.   I did one audit for example where regulatory required documentation was stored in one central room and a number of individuals had access.  They stored non-perishable foods, holiday decorations, etc. in the same room.  That was an issue.  The paper materials should be in a secured location – either in a secured desk, locked room, cabinet, etc.

So today we have some excellent coverage via the always-interesting Mocana DeviceLine blog (have I blog-rolled them enough do you think?) covering a technical deep-dive on Google Wallet from ViaForensics.  An interesting read.

According to their inquiry of how Google Wallet works, they’ve determined that there’s some scary data stored cleartext on the phone, including:

• Card type and last 4
• Card holder name
• Current balance
• Available to spend
• Statement balance
• Payment due date
• Citi contact number

Well, that’s interesting. Folks might object to this kind of data being stored in cleartext within Google Wallet (I sure do), but I’d like to point out that the problem isn’t so much Google Wallet (although, guys… really?  Statement Balance?  Really?)  but instead the fact that mobile devices are blurring the lines between what’s a payment application vs. what’s not.

You see, right now, shy of actually storing the whole credit card number, there’s not really much guidance on what is or is not acceptable here from a protection standpoint.  Technically, Google Wallet falls into what the standards council has defined as a “Category 3 Payment Acceptance Application.”  What is a Category 3 mobile payment acceptance application, you ask? Per the council:

Payment application operates on any consumer electronic handheld device (e.g., smart phone, tablet, or PDA) that is not solely dedicated to payment acceptance for transaction processing.

Sounds like Google Wallet, amirite?  So how do you validate such an application?  For example say Google wants to do the right thing and have someone review their app to avoid these kinds of shenanigans… to ensure that the security of the application is consistent with the defined requirements of PCI?  Short answer: you can’t.  Longer answer —  from the council:

The PCI SSC recommends that mobile payment acceptance applications that fit into Category 3—and are thus not eligible for PA-DSS validation at this time but are intended for use in the cardholder data environment—are developed using PA-DSS as a baseline for protection of payment card data and in support of PCI DSS compliance.

OK, so you can’t validate it.  They recommend that you maybe skim through the PA-DSS to check out how to protect cardholder data from an application standpoint, but it’s discretionary… So you can’t validate to PA-DSS.  Unfortunate.  So what is the oversight for these apps? Who’s responsible?  From the same document:

Applications used for payment-initiation—for example, those downloaded by consumers onto their mobile phones and used for consumers’ personal shopping—are seen as similar to the payment card in a consumer’s wallet. The Council’s purview does not currently extend to, nor is PA-DSS applicable to, consumer-facing mobile payment initiation applications.

And there you have it.  My reading of this is that — at least currently — the expectation that we should have for security of “consumer-facing mobile payment initiation applications” is the goose-egg.  In other words, Google didn’t cross a regulatory boundary.  One might argue that there should be a regulatory boundary here… but if there is, I can’t find it.

Anybody disagree?  Would love to hear from a PA-QSA on this.

Image source: gyakutenphoenix.deviantart.com

So today the CUNA (Credit Union National Association) issued a letter from their president to Congress (as part of the record for a hearing on data protection for small businesses) calling for merchants to have the same “same high standards for data protection” as financial institutions.

From the letter:

As we describe below, credit unions are subject to very high data security standards under the Gramm-Leach Bliley Act of 1999 (GLBA)… However, merchants are not required to follow these standards, and until they are held to the same standard, consumers will remain vulnerable to a system that does not protect their information.

So the beef here is that Merchants — specifically in reference to debit transactions – don’t have data security requirements with teeth.  OK, I get that.

But compare GLBA (as outlined via the safeguards rule and the  FFIEC IT Examination Handbook) with the PCI DSS.   Yes, it’s true that most financial institutions have better procedural controls compared to merchants — because merchants don’t generally have the same challenges as financial institutions do.  But merchants do have a requirement for technical controls.   In many cases, a more prescriptive, defined, with less “we don’t want to do it” wiggle room as what FI’s have to adhere to.  By virtue of the PCI DSS,  merchants who process credit cards — tend to have better technical controls  than many financial institutions.

So here’s what I’d say: sure, let’s get merchants to adhere to same  data security requirements as financial institutions when it comes to debit transactions.  But I’d recommend that we make that conditional on the inverse requirement.  Namely, that the current  requirement merchants need to adhere to for credit cards be required of FI’s.  Specifically, that financial institutions be required to implement the technical controls of a highly-prescriptive technical standard (like the PCI DSS) in the entirety of their processing environment.

Seems fair, don’t you think?

TechTarget just published my analysis on the PCI Tokenization Guidelines:

For years, security experts have touted the value of credit card tokenization for limiting PCI scope. The National Retail Federation (NRF) listed tokenization in its January 2009 “Key PCI Best Practices” document, and Gartner Inc. analysts John Pescatore and Avivah Litan explained how tokenization can be used to reduce PCI scope in their August 2009 research note, “Using Tokenization to Reduce PCI Compliance Requirements.”

Now, following the long-awaited release of its PCI Tokenization Guidelines in August 2011, the PCI Security Standards Council (SSC) has made it official: tokenization can reduce scope for PCI audits. Organizations that were waiting for the council’s opinion can now forge ahead with implementations, knowing that credit card tokenization is approved for use in a PCI DSS-compliant cardholder data environment (CDE). That in itself will be welcome news to many merchants.

To read the rest of my analysis, please click here.

So, for folks who pay attention to this stuff, the long-awaited PCI Tokenization guidance is finally out.

We’ll be discussing it in some depth over the next few months — in this forum and others.  However, as a quick hit, the biggest win by far is that we finally know for a fact (because they council finally said it officially) that scope-limiting via tokenization is permissible.  So that ought to be refreshing to folks.  But really, it was pretty much the only way that it could have gone down (I do confess though to finding a “project mayhem“-esque humor in the idea of them saying it wasn’t).  So anyway, now it’s official.

But now that it’s there, I”m a bit confused by the C&A (certification/accreditation) strategy here.  Check out, for example, the plan for encryption C&A in the P2PE initial roadmap:

Independent validation of P2PE solutions is required and will be based on additional guidance and/or testing criteria for the encryption and decryption environments to be provided by PCI SSC. [page 5]

So the plan is to certify encryption technologies used to limit scope but not tokenization.  So… what if I use encryption to implement tokenization?  Here’s what they say about that:

 Note that where token generation is based on a reversible encryption method (where the token is mathematically derived from the original PAN through the use of an encryption algorithm and cryptographic key), the resultant token is an encrypted PAN, and may be subject to PCI DSS considerations in addition to those included in this document. The PCI SSC is further evaluating how these considerations may impact PCI DSS scope for reversible, encryption-based tokens.

So if I encrypt a PAN using a reversible, encryption-based method and sell it as “encryption”,  I definitely have to certify.  But if I sell it as “tokenization”, I maybe don’t have to.  Whereas if I make a “tokenization” product (maybe or maybe not based on encryption) and I want to certify it, I may or may not be able to depending since it’s not officially governed by any C&A program currently in place.

Um.  Is it just me?  Or is that confusing?

I mean, putting aside the technology for a second, what’s the difference from a business process standpoint — from a scoping and goals standpoint — between tokenization and P2PE?  Isn’t the goal for both to limit scope?   It’s not about requirements either — from a security requirements standpoint, I’d argue that  a lookup-table or MAC key used to create a token have almost exactly equivalent security requirements to a symmetric key.  So it’s not about the usage where the C&A line gets drawn, it’s about the implementation.  In particular, it’s about a specific nuance of that implementation (i.e. the “reversibility” of the algorithm).  Why draw this line?

In point of fact, rather than discourage certification, I think certification would be very helpful in the tokenization space.  And I think the market is already telling us this.   Liaison (formerly NuBridges) for example, announced recently that they’ve undergone voluntary PA-DSS audit — even though they’re not able to fully certify as a payment application under the PA-DSS.  It’s an interesting case (and I admire their gumption).  They basically decided that they were going to go through the compliance validation process as a payment application in absence of any requirement to do so.  As a competitive differentiator.

Now putting aside discussion about whether the solution does or does not facilitate authorization and/or settlement (I think there’s room for discussion on that point).  Given the ambiguity above, arguably they could have called their solution an encryption solution and gone through that C&A process if it were finalized.  But since the encryption certification process is still in development, they’ve instead evaluated the product as a payment application.  Even though they’re not, strictly speaking, eligible.

An interesting decision — and one that I’m curious to see play out in the market.  As a former assessor, I would have found a PA-DSS (non)certification helpful during the audit process.  Even if it didn’t result in an official PA-DSS registration.  Why?  Because I could know that an application auditor would have looked over the product already.  It could help in evaluating the underlying technology to know that someone stamped as “approved” by the council actually looked at the solution.  You can’t rely on it of course, but it can add a level of confidence in an evaluation that you wouldn’t have otherwise.  Heck, I might have even referred to it explicitly in the observations area in writing up section 6.

So, as promised on Friday, here’s an interesting discussion that Diana brought my attention to the other day.  It’s basically a discussion about how to (ostensibly) eliminate PCI scope – by manipulation of who hosts payment-related HTML forms.  How could that possibly matter, you ask?  More on that in a minute.

The article itself would only be semi-interesting  in and of itself, but what makes it worth reading are the comments.  Comments like the following:

This is stupifying to say the least, that 1) Visa’s own gateway does not understand the idea of PCI Scope, and 2) that the industry also does not know how to connect the dots that it gives this sort of solution a pass and adorn it with words like “Eliminating” instead of reducing PCI Scope.

So… right?  Anyway, there’s some really good back and forth in the comments and some really good arguments get raised about the nature of PCI scope.  It’s worth a read.  As a quick synopsis, the issue is the following:

Background:  Various payment gateways are making the claim that merchants can eliminate PCI scope by removing themselves from the payment flow. On the one end of the spectrum, you have a situation like PayPal where the 3rd party hosts the whole payment flow; on the other end, you have redirect a shopper to a different site prior to payment – or host the form handler on a different domain.

It sounds complicated, but it’s really not.  Here’s a graphic of a solution built on this premise in action: kind of like the way Verified by Visa works, but bouncing the shopper to the processor for payment rather than bouncing them to the issuer for authentication.

Position #1 – Merchant out of scope:  so, some folks seeing this hold the position that the scope of compliance at the merchant is the null set due to the fact that they neither “store, process, or transmit” cardholder data.

Position #2 – Merchant in scope: the contrary position is that the merchant is in scope because of the fact that the form on the merchant site is so directly tied to the payment process.

It’s a pretty snarly topic, right?  In my humble opinion, the problem is introduced because the baseline of scope: “store, process, and transmit” is vague.  How can it be vague, you ask?  Well, at what level do you mean it?  Are the verbs “process” and “transmit” only applicable at the network and transport layers?  Or are they applicable at an application component level as well?  If you say it only matters what happens at the network level, you are likely to conclude that the environment is not in scope:

True enough, the blank web form with no customer data does come from the merchant. But the payment card information is never provided to the merchant, never handled by the merchant, never handled by a system the merchant manages, and never handled my a system networked to the merchant. Rather, the payment gateway takes responsibility for the actual credit card.

If, on the other hand, you conclude that the application components constitute a unit – a whole that is difficult to separate from a processing standpoint, you are likely to conclude the opposite:

…It is the merchant’s HTML document. It is the merchant’s PCI-DSS responsibility to secure this page and ensure that card data entered into it is protected… The merchant that is getting paid must protect the card data UNTIL is in the hands of another PCI Compliant entity.To say that once a web page is delivered to a consumers browser that is in Vegas and what happens in Vegas stays in Vegas is an incorrect way to view this.

It is, as I say, an interesting question.  One that is very much worth looking into.  And one that I think points to an issue in PCI as it relates to scope; namely, if the DSS delineates scope based on OSI layers 5 and below, this introduces a situation where scope could extend beyond what you might expect when you’re talking about the application layer.

Anyway, very much worth a read – particularly the smart comments from the folks who live and breath this at the end of the article proper.

After much anticipation, the PCI Security Standards Council released the Virtualization SIG guidance on June 14th. TechTarget asked for my take on the findings:

For years, retailers, merchants and payment service providers have asked the question: Can virtualization be used in a PCI-compliant cardholder data environment (CDE)?

Several qualified security assessors (QSAs) and auditors argued that the PCI DSS “one function per server” requirement (Requirement 2.2.1) rules out virtualization as an acceptable technology in a CDE. Other QSAs, auditors and architects posited the “one function per server” requirement could instead be met by installing one function per virtual machine (VM) server running on top of a hypervisor. But there was no official ruling from the PCI Security Standards Council, leaving the question up in the air.

For the rest of my PCI Virtualization SIG Analysis, please click here.

Overwhelmed by all of the documentation and resources associated with PCI? I have two articles over at TechTarget that untangle levels, special guidance, and other PCI related docs:

PCI Levels, Assessments and Reports

PCI DSS Documentation, Resources for Solution Providers

This morning, I came across this on Security Park entitled, “Retailers must begin to explore how to become PCI-DSS compliant to avoid being next on the hacker’s hit list”.   Anybody else find this concerning?

The indication seems to be that there is an implied connection between being PCI compliant and being “next on the hacker’s hit list”:

Retailers aren’t giving enough attention to compliance so the execution is poor. SMEs in particular are vulnerable. Larger companies are richer targets, but most have accompanying budgets and IT departments dedicated to protecting their vital customer information. As PCI DSS regulations take hold, fraudsters are targeting less well-defended small businesses.

Are folks still thinking these are connected in any way? Because they’re not. Being compliant with PCI introduces a bare minimum set of controls. Does the bare minimum prevent hackers? No. Does it reduce the likelihood of hackers? Possibly, but we don’t really have a way to measure that in the industry.

Security is not compliance.  Hackers don’t care if you’re compliant with some arbitrary standard or not.  Seriously.

After our PCI virtual seminar last week we had so many questions we were not able to address them all during the live Q&A. TechTarget asked us to answer them and post the responses in the Compliance Counselor section of their site – which we did.

So, please to enjoy our 30 answers to your PCI DSS v2.0 questions!