Author: David Froud

As I stated in my previous article Target Breach: What Does This Say About Their QSA?, the more naive questions that inevitably follow a major breach like this revolve around a couple of things:

  1. What good is the PCI Data Security Standard if this kind of thing still happens, and;
    o
  2. What did the QSA do wrong?

Both of these questions are the WRONG questions to ask, and display an ignorance of good security practices, the PCI compliance assessment process, and the intent of the PCI standard itself.

First, the intent of the standard was never to prevent beaches from happening entirely, that’s impossible, so the intent was always to REDUCE the instances of breaches to a point that can be considered ‘best efforts’. Every other standard or security framework out there use phrases like ‘reasonable’ or ‘appropriate’, and make absolutely no effort whatsoever to help you figure out what these things mean in your environment.

PCI went the other way, and explicitly implied (by the very nature of the DSS) that if you implement all of the controls, that the resulting risk reduction was good enough. Not once did they ever say PCI compliance was actual security, and not once did they ever say that you should stop your security program AT compliance. The PCI DSS has always been, and will always BE a minimum set of controls around a single form of data, and should NEVER have been seen as enough security for your business.

So, ANY individual who is surprised when a company that has achieved compliance is breached, should do their homework before pointing fingers. Target was an enormously valuable prize for thieves, and warranted an effort far above anything PCI compliance, or maybe even good security, could have hoped to prevent.

As for the QSA, you just have to look at the assessment process itself to see that the PCI DSS should never be confused with either a comprehensive security framework, or even a reasonable assessment of compliance. Any standard that allows both sampling, AND point-in-time validation, can only ever be seen as scratching the surface, especially with an organisation the size, distribution, and complexity of Target. There is simply far too much that the QSA will not see in a given year to point fingers in that direction.

Sampling is a privilege, not a right, and has to be earned. You start at 100%, and work down from there, and to even allow sampling in the first place, a few things must be in place:

  1. Standardised Builds: Just because every Windows system is built from the same base image (for example), does not mean that all Windows systems can be sampled randomly. Every system function, location, admin team, etc. must be taken into account, and a justifiable cross section of systems included.
    o
  2. Centralised Maintenance/Management: For sampling to be valid, it must be shown that ALL systems in the environment are maintained identically. From patching, to updates, to anything else that affects the ‘like’ systems, uniformity must be demonstrated.
    o
  3. Centralised Monitoring: Unless all systems in the estate where sampling is proposed are monitored centrally, each distinct monitoring unit must be handled separately.

In other words, unless you can show how the systems are configured identically, managed identically, and monitored identically, sampling is not an option. Even with this in place, the potential gaps are significant.

As for the point-in-time aspect, even the cards brands themselves don’t understand that at the time of compliance, the assessment process allows validation evidence that’s 364 days old. There is nothing in the DSS, or any other document produced by the SSC, that states that validation evidence cannot be more than x days/months old.

Instead, it seems to be assumed that the RE-certification process, including evidence gathering, happens in the last few weeks of the compliance cycle. It simply does not work that way. Unless you provide a list of evidence / remediation requirements MONTHS in advance of your client’s compliance deadline, any surprises can either prevent re-compliance, and/or create significant internal re-tasking. So, generally, this will involve collecting evidence 6 months old at a minimum.

A lot can happen in 6 months.

As I stated at the end of my previous blog on the Target breach, the fault – IF there is any – lies with Target stopping their security program at just PCI compliance. If they didn’t stop there, and had gone above and beyond, then it’s just one of those things, hopefully a lesson learned, and we should all focus on something a little more constructive.

Like getting away from the use of credit cards for example…

I am constantly surprised and disappointed that the Policy Set (policies, standards, procedures, and guidelines) aren’t taken more seriously. They are the blueprint of your corporate culture, the single most important aspect of your security program, and by far the easiest and cheapest things to put together (in terms of capital costs anyway).

Even a ‘controls only’ standard like the PCI DSS is roughly 40% ‘paperwork’, but, with the possible exception of the risk assessment, remains the most common tick-in-the-box exercise of them all. Which is a shame really, as it should be enough that thieves want to steal your data, to make things worse by not preventing your own employees from virtually giving it away is just plain dumb?

A Policy Set generally consist of 4 main components:

  1. Policies – the dos-and-don’ts of your entire organisation and use language like will / must / shall. e.g. Your authentication policy states that you; ‘MUST use strong authentication for access to systems containing data above a certain classification.’;
    o
  2. Standards – A very detailed document that explains exactly HOW something is to be configured. From operating system hardening guides to firewall rulesets. e.g. the details the actual password elements that constitute ‘strong’ (7 characters, alpha-numeric, change every 90 days etc.).;
    o
  3. Procedures – describe HOW you implement the policies in YOUR organisation. They are detailed, ‘living’ documents that prevent the constant re-inventing of the wheel when faced with performing standard functions. e.g. this is how you long into X system using 2-factor authentication.; and
    o
  4. Guidelines – The only non-mandatory element of the Policy Set, they provide good-practice guidance on how to implement a policy or standard requirement. e.g. For passwords, don’t use birthdays, don’t use names of children, consider a pass-phrase instead etc.

However, you can have the most polished documentation ever, and still completely miss the mark. It’s not about the paperwork itself, it’s about the enforcement of what’s IN the paperwork. A policy is only ever as good as the understanding of it, and the adherence to it.

Unfortunately, this is where most organisation fall down, and one or most of the following challenges apply:

  1. Policies not in-line with corporate culture or day-to-day business process – Policies should be owned, and even written BY the CEO / BoD. Who else is responsible for the culture, direction, and future of an organisation more than them? Too often this is delegated to departments or individuals without the necessary authority or experience to perform the function properly. A document coordinator MUST be a subject matter expert;
    o
  2. Undocumented procedures result in numerous (usually unintentional) breaches in policy outside of formal exception/variance processes – Just because a policy is in place, does not mean everyone knows how to implement it. Every department in an organisation is responsible to describe how each and every task is accomplished. Without procedures and standards, policies can become unenforceable, and every new employee has to reinvent the wheel every time they want to accomplish what should be a standard task;
    o
  3. Policies are undistributed, unenforced, or mis-understood – Just because you HAVE policies, or even procedures, if no-one knows where they are, what they mean, or how to measure against them, they are just pieces of paper. Security Awareness Training programs should start with a comprehensive look at ‘role-relevant’ corporate policies;
    o
  4. Poor document management or lack of integration with formalised training mechanisms – Without a robust document management system, it’s very difficult to both maintain the integrity of the Policy Set, and very difficult to distribute and enforce it; and/or
    o
  5. No feedback or measurement processes – Per the old misquoted cliché; ‘you can’t manage what you can’t measure‘, unless policies are seen as living documents with company wide feedback mechanisms in place, they can rapidly become obsolete.

I do not use the word ‘recommend’ lightly, but I HIGHLY recommend that before you implement ANY aspect of your security or compliance program, you get your Policy Set in place. At the VERY least do this in parallel with a risk assessment and business process mapping exercise.

While most high profile breaches focus on what went wrong technically, I can almost guarantee the original failure was one of education in the most basic of all security foundations; policies, standards, and procedures.

[If you liked this article, please share! Want more like it, subscribe!]

According to the pre-forensics news, the breach was a result of malicious software installed on Point of Sale (POS) devices in a significant number (potentially all) of their locations across the US.

The thieves were apparently able steal not only the card numbers, but the track data and the PIN numbers as well, suggesting that the breach involved ‘sniffing’ the information off the wire. This data was obviously unencrypted from the point of swipe, suggesting also that the PEDs / terminals are either not configured to do so, or are older models not capable of doing so.

Of course, this is all speculation, and it may be as simple as a concerted attack with skimming devices, but 40 MILLION cards lost at so many locations certainly suggests something more centralised, and far more fundamental.

Once the fuss dies down, there will be the inevitable ‘blame storming’ questions. For example:

  1. How did this happen if they were PCI compliant?
    o
  2. Who was their QSA, and how did they miss something so major?
    o
  3. Why are we still using credit cards when they are so insecure?

…and so on.

The first one is easy, and anyone who STILL thinks PCI compliance means that they were secure knows nothing about PCI, and even less about security. More detail in my blog Stop Confusing PCI Compliance With Actual Security. As a corollary, there are many QSAs who think that PCI compliance is enough, and either don’t even try to help their clients toward a proper security posture, or assume PCI is about compliance in the first place. They should, and it’s not, respectively.

PCI compliance was only introduced to try to prevent things like the Target breach from happening, do you really think the cards brands care about actual compliance itself if it means credit card data is still vulnerable?

As for the second, the name of the QSA will no doubt come out in time, but blaming THEM for not doing their job properly is like blaming a single doctor for not curing all the world’s illnesses, it simply does not work that way. To any QSA company who tries to use this breach to bad mouth either the incumbent QSA company, or the QSA assessors, I say they had better have their own house 100% in order, because what goes around, comes around.

No QSA can EVER have the depth or breadth of knowledge of an organisation the size and complexity of Target and be able to determine 100% compliance, not when sampling and point-in-time validation are part and parcel of the assessment process.

As for the third one, that’s a question for the ages, and beyond the scope of this blog. I don’t like credit cards, as the majority of my blogs will attest, but they are going to be around for a while, so we had better come up with a better way of protecting them than compliance to the PCI DSS can ever provide.

For a start, does Target need to accept credit card payment themselves? Are home grown payment applications and systems core to their business? The answer to both is no, they are in business to sell things, that’s all, payments are just the MEANS to that end. Simplify, and/or outsource that function to an organisation that specialises in it, or at least consider the possibility.

Eventually credit cards will go away, but the need to properly authenticate a payment, and protect personal data will not. PCI does not get ANY organisation where it needs to be, and if you want to blame anyone for this breach, look no further than Target, they are the ones with all the cards in their hands, not the QSA.

====================

Update 20-Dec-13: In case my words above are unclear, I am VERY much against blaming QSAs for breaches when there is so much wrong with both the assessment process, and the standard itself. Yes, there are some crappy QSAs, but I seriously doubt this was something Target’s QSA missed. This was most likely a very sophisticated attack that even a security posture far above PCI compliance would have been able to stop.

Also, to whomever tried to post the name of the QSA as an employee OF that QSA, there is nothing I have seen in my career that is more unprofessional or more lacking in integrity. You are a coward.

Last week I had the pleasure of conducting a 1 day Advanced PCI course that included details of the changes between v2.0 and v3.0. It was clear that there is not only continued confusion regarding the ‘new’ content, but that the less scrupulous vendors of QSA and penetration testing services are using this confusion to charge more for the same service.

I have warned of this previously, but let’s be very clear. If you are being asked for more money based on the v3.0 changes, your service provider is:

  1. Confused about what the changes mean themselves;
    o
  2. Covering up for not performing their work properly in previous years;
    o
  3. Lying to you.

I fully understand the pressures QSA companies are under with regard price compression, competition and so forth, but using this DSS update to raise prices is unconscionable.

Here is an example;

Requirement 1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.

In v2.0 of the DSS the ‘Testing Procedures’ states; “1.3.3 Verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.”

In theory, the QSA could just say; “[QSA company] verified that direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.” However, in the ‘ROC Reporting Instructions for PCI DSS v2.0, September 2011‘ your QSA is responsible to do far more;

 Identify the network documents/diagrams specifying that direct connections are not allowed for traffic between the Internet and the cardholder data environment:

i. Inbound ii. Outbound

 Describe how observed firewall/router configurations prevent direct connections between the Internet and the cardholder data environment:

i. Inbound ii. Outbound

 Describe how observed traffic between the Internet and the cardholder data environment confirms that direct connections are not permitted:

i. Inbound ii. Outbound

Now look at v3.0; “1.3.3 Examine firewall and router configurations to verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.”

Other than changing ‘verify’ to ‘examine’, the reporting instructions are STILL not fully built into the new standard, but are getting closer. So the vast majority of the DSS v3.0 is just clarification of validation requirements based on a document that is already more than 2 years old.

To put this another way; your QSA and YOU were responsible for performing 95% of what’s in the v3.0 for the last 2 years. The other 5% are things you SHOULD have been doing anyway if your QSA was doing their job, and you were doing security properly:

2.4 – Maintain an inventory of system components that are in scope for PCI DSS

Seriously? How could you have EVER achieved compliance without having an asset inventory of some sort?

6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).

Verify that coding techniques actually address the ‘high vulnerabilities’? What ELSE would it be doing?

8.5.1 Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer. 

The sad part is that they actually had to add this, as a lot of breaches were caused by NOT having this in place. Vendor due diligence is almost universally poor across PCI relevant service providers, and this is entirely the fault of each organisation, not the SSC.

9.9 Examine documented policies and procedures to verify they include:

 Maintaining a list of devices

 Periodically inspecting devices to look for tampering or substitution

 Training personnel to be aware of suspicious behavior and to report tampering or substitution of POS devices

If you weren’t doing this already you deserve what you get.

10.x [Logging Stuff]

Significant clarification of what’s expected in logging and monitoring, and will only negatively impact those organisations doing the bare minimum to get through PCI.

11.3.x [Penetration Testing Stuff]

Nothing in here is different from the intent of penetration testing all the way back to v1.0, and if your QSA says things have changed, they have been doing it wrong all along.

12.8.x [Service Provider Stuff]

The only organisations this will negatively affect are service providers who were hiding the true extent of their service coverage, and clients trying to outsource responsibility of PCI compliance to others. If your organisation’s vendor due diligence and vendor management programs don’t already cover this, it’s your fault.

If you want a more complete listing of the changes, go here; PCI DSS v3.0 – Mapping to v2.0_v07NOV13.xlsx

Every QSA company has training courses, white papers, presentations and God knows what else trying to explain the difference between v2.0 and v3.0. If you want to save your time and money, learn how to do SECURITY properly and PCI will make perfect sense.

Take the phrase ‘cardholder data’ out of the DSS and replace it with ‘personal information about your family’. Name ONE requirement you don’t want in place?

[It’s clear that this topic has wayyyy too much material for just a blog, so at some point I’ll back this up with a white paper or some such. Please accept this as an amuse-bouche];

Today, the savvy buyer does their homework on all major retail expenses, ensures they have they the funds for it (debit or credit), and finds the best deal BEFORE buying.

The non-savvy, or impulse buyer, tends to get hosed, which may result in several things; the buyer either changes their minds and returns the item (and/or gets into financial difficulty), the merchant has a second-hand system to get rid of AND has the hassle of a charge-back, and the financial institution behind the payment runs the risk of non-repayment of the resulting bad debt.

While you’re never going to get away from consumers making bad decisions, you CAN make level the playing field, and make the experience for all parties less risky, more efficient, and potentially cheaper all round.

Two of the challenges we face today are:

  1. The vast majority of new businesses in the payments space are innovators, and have a very narrow focus. i.e. see a need, fill a need from a niche perspective. So if you’re looking around for those types of services, you have hundreds of small organisations from which to choose, and you either gamble, or wait until the market settles down and risk missing out entirely on a potential competitive edge.
    o
  2. Every player in the payments ecosystem is either a dependent, or in competition, leaving everyone worse off, especially the consumer. You just have to look at the number of e-wallets, coupons, or loyalty point systems to see that 99% of them are unsustainable. The corollary is that new innovations in the retail space are very slow to be adopted, if at all.

So how do you choose the right combination of payment services for YOUR business?

Choose the right one(s) and the benefits are clear and ongoing, choose the wrong one(s) and you’ve potentially damaged your brand reputation. How many times have you collected loyalty points (for example), and never had the opportunity to enjoy the benefits?

The biggest issue the payments ecosystem faces it that the true cost of an expense if rarely apparent up front, and your payment options are limited to the offers of either your existing financial institutions, or of the retailers themselves.  Instead, what if the banks made available enough information at the time of purchase for you to choose the RIGHT payment option?

Bob Mackman wrote a short white paper How to Pay: The Future for Mobile in m-Commerce, in which he posits that for a mobile application to;

“…weigh up the advantages of each [payment method] by looking at things such as: available credit, due date, interest rates and any loyalty schemes and give them the pros and cons of each for this particular purchase at this moment in time. Perhaps putting them into an order of preference.“

…that the background financial institutions would first need to provide;

“…direct access to the information from the bank and card accounts being used. If the providers made API’s available for even just some basic transactions then this would be possible.”

You can imagine how often his happens currently.

But, if the banks could see the amazing potential this provides, then this would not be the “pipe dream of a romantic“, as Bob puts it, but a reality in which anyone NOT providing these services is left behind.

Like most things, it’s not that easy. For this to truly work you have to consider all of the following and many more:

  1. Authentication – ALWAYS the primary consideration in payments
  2. Ratings & Reviews integration – against financial services, retailers, products etc.
  3. Big data analytics and customer profiling resulting in targeted displays / coupons based on instant access to metadata of preferences (e.g. material / colour / designer)
  4. Existing payment technologies – PEDs, EMV, NFC, e-wallets and so on…
  5. New[er] payment technologies – Bluetooth beaconing, geolocation, bio-metrics and so on…
  6. Payment choices / instant credit through existing financial institutions (which has dependencies on single purchase interest rates and unaffected credit ratings etc.)

So who’s going to be able to put this all together? No-one currently, but in much the same way that the enormous growth of telecoms options resulting in a spin-off industry of consultants providing consolidation / savings services, the soon to be exponential growth of payment technologies will spurn a new breed of consultant; the payments Service Provider Integrator (SPI).

From banks, to payment gateways, to ratings & reviews, to loyalty, to anti-fraud, the SPI will be able to seamlessly integrate all the niche providers into a whole-istic solution designed to meet an organisations goals.

Here I must stop, but this will continue in more detail in the pending white paper.

If you have any ideas around this stuff, please share, I’ll make sure to build it in.