PCI L1 Service Provider

From FinTech Concept to PCI Compliant in 6 Months?

Anyone wanting to start a new business in FinTech/payments – digital wallets for example – has to address PCI. Like it not, payment cards are still the dominant form of non-cash payment on the planet. By far.

So what if you have a great idea in this amazing world of opportunity, but your skill-set is in payments and innovation, and not IT or cybersecurity. How do you get your service to market, AND play by the rules? Can you do this in time to be ahead of game given the incredibly short timeframe of today’s competitive advantage?

Well, you could just self assess, but you are restricting yourself to a maximum of 300,000 transaction annually.  But more importantly, would you trust your money to a service provider who self assesses? No, neither would I.

However, I’m talking about full Level 1 Service Provider compliance through a reputable QSA (yes, there are some out there). How can you set up the infrastructure, get all the documentation in place, AND get all the way through a PCI DSS Level 1 assessment in 6 months? And if you do, have you really done it properly?

The answer is yes, you can, but there are MANY caveats, and if you deviate from these steps you will not get there. I am only interested in helping organisations get compliant properly, I have no interest in adding more crap service providers to the ecosystem.

First, you have to completely ignore the PCI DSS. Any plans you make to design both your physical infrastructure and your security program from scratch must be with real security in mind. Never compliance alone. For that, many organisations turn to the ISO 27001 standard. There are others, but try finding affordable consultants who can help you implement them. As long as you realise they are all just frameworks, not step-by-step instructions, then you’re ready to start asking questions.

So What Are the Steps to Compliance?

o

  1. Get Help – This should be no surprise. I don’t perform emergency appendectomies, I’m not remotely qualified, why would you try to achieve compliance when that’s not your experience or skill-set. Yes, is can be expensive, but nowhere near as expensive as any of the alternatives. There are some very good consultants out there, do your homework and find the best one for you.
    o
  2. Outsource the Infrastructure – Unless you’re an expert in everything from hardened operating systems, to logging and monitoring, to firewall management, you will want to outsource as much of the platform as you possibly can. Unfortunately, finding a single provider who can take on anything more than physical hosting and some networking stuff is still ridiculously difficult. Amazon Web Services (AWS) for example is about as bad as you can get. Unless of course you want a dozen or so independent service providers to manage along with Amazon.
    You MUST ask the right questions, and this is where your  consultant comes into play. S/he will write your RFP, interview providers, and eventually produce a responsibility mapping of services against the PCI DSS. This will match their Attestation of Compliance, as YOU should only do business with L1 PCI compliant service providers.
    o
    You are welcome to use my mapping if you don’t have one: PCI DSS v3.2 SP Responsibility Mapping
    o
  3. Policies, Standards & Procedures – You have to start somewhere, so you will likely want to buy a Policy Set. Once again, you have to be very careful as there are dozens of options but few will be fit for purpose. In this case, ‘fit for purpose’ means the service must 1) get you through compliance, 2) provide a platform for your unique culture, and 3) be self-sustainable for the long-term.
    If you buy a Policy Set with ‘PCI’ in the title, you have already failed. Buy one that your consultant can customise on your behalf, and then teach you to manage yourself. Get one that; 1) Is already mapped to both the PCI DSS and your chosen framework (usually ISO 27001), 2) has document management built in (numbering, content standards, assigned coordination etc.), and 3) is easily distributed to the subject matter experts best placed to maintain them.
    o
    I have written a quasi-white paper on how to choose the right the right service, you use the questions as an RFP: ‘Selecting the Right Policy Set
    o
  4. Hire a Completely Independent QSA – While it may be very tempting to have your consultant take care of all the ‘PCI stuff’, bite the bullet and keep these separate. No, you don’t have to be an expert in this stuff, but if you are relying completely on your consultant you are building in a single source of failure. By all means have your consultant run with the assessment, but be involved. If you don’t, you’ll have no idea what you paid for in the first place. In fact, you may even want to build in some SLAs regarding how much remediation is required from by QSA. There will always be some, but if it involves significant scope creep or capital cost, your consultant has failed you. Remember, you have outsourced almost the entire function of PCI to your platform provider, validation of compliance should be a formality.

Of course this is oversimplified, but I’m already way over my self-imposed word limit. However, while I haven’t included any of the inevitable challenges, the process is a simple as security itself, it’s up to you to find someone who can make it simple.

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

Self Assessment Questionnaire

SAQ Validation Requirements, Quite Simple Really

There’s an old phrase that’s depressingly appropriate when it comes to the completion of Self Assessment Questionnaires (SAQ); “Not worth the paper it’s printed on.” At least that’s how it is for the majority of the ones I’ve seen, SAQ validation is universally performed badly.

The reasons for this are many. From acquirers leaving the choice of SAQ up to the merchant, to merchant indifference, to flat out incompetence, many SAQs are works of fiction. While the PCI DSS itself has undergone significant modification to ensure more appropriate validation, the SAQs have not followed suit.

For example, for a relatively simple requirement like ‘1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations.’, the DSS requires all of this;

screen-shot-2016-10-15-at-10-51-49

The corresponding SAQs (A-EP, and D-M and D-SP) require just this;

screen-shot-2016-10-15-at-10-54-41

While the DSS requires full descriptions of HOW the requirements we validated, the SAQ requires just one of 5 tick-boxes; “Yes”, “Yes, with CCW”, “No”, “N/A” and”Not Tested”.

I fully understand that the SAQ requirements are completely tied to risk, however, EVERYONE is liable for full compliance against the entire DSS. The SAQ is just a reporting mechanism, nothing more. In other words, if you don’t validate properly, you’ll still be held fully accountable in a worst case scenario.

It follows therefore, that when validating your applicable SAQ requirements, you follow the Testing Procedures of the DSS. That way, should the worst happen, you can actually demonstrate appropriate due diligence. If you can “Describe how…” you sampled, examined, and tested firewall and router configuration changes, you cannot claim to have properly “Examine[d] network configurations”.

So, to help resolve this, and to once again demonstrate how sad I am, I have performed yet another mapping. This time I have mapped the applicable requirements as defined in all 9 SAQs to the validation requirements of the full PCI DSS v3.2. I did though go one stage further, and added a “Questions” sheet to help determine requirement applicability up front.

For example, if you do not retain full cardholder data post-auth, the majority of the encryption requirements become ‘Not Applicable’. Same for absence of wireless, no in-house application development, and so on.

Start with the ‘Questions’ tab of the spreadsheet (available here in Downloads) and answer “Yes” or “No” to each question. Now when you go to the ‘v3.2’ tab you will see which requirements are applicable to which SAQ (marked with a ✓). Now just choose your column and feel free to filter.

If I’m completely honest with myself – which I usually am – I know that there is little benefit to this document, but it may be of interest in these scenarios:

  1. Any merchant changing SAQs, going up a level, or adding a service – For example, if you’re a Level 2 Merchant and you’re going to kick up to Level 1, you’ll see just how much work you have to do. Or if you are adopting P2PE, you see just how much your SAQ validation is reduced.
    o
  2. Anyone who wants to see just how irrelevant the SAQs are in relation to real security – If all you do is complete an SAQ, you’ll be able to compare a minimum set of security controls (the full PCI DSS) to what you’re doing. Well, what you should be doing at an absolute minimum if you cared at all about your customers data.
    o
  3. Any entity wanting to validate their SAQ properly.

In 10+ years of providing PCI guidance, I have never seen an acquirer ask for validation evidence outside of an ASV scan. I doubt I ever will, so if you want to do security properly, great, but don’t use the SAQ as your guide. In fact, don’t even use the DSS for anything more than a rough guide, you’re better off with a real consultant.

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

PCI, You Have Chosen Poorly

PCI DSS, You Brought It On Yourselves

I have never hidden my disdain for the PCI DSS, and have written numerous blogs as to why. Not just whinging mind you, I have always included a stab at providing solutions or alternatives. But every now and again, I have to remind myself why the DSS even exists in the first place. And who needs to accept a sizeable chunk of the responsibility for it.

It’s you Mr. Retail, and you Mr. E-Commerce, and especially you Mr. Service Provider. You are every bit as culpable as the Card Brands.

Yes, the payment card technology is 50+ years old, and hopelessly outdated. Yes it’s a ridiculous way of paying now that there are so many better ways. And yes, it’s very difficult to protect cardholder data, but it’s really not complicated. All it took was effort.

But organisations didn’t make any effort. For decades on end. From stand-alone terminals, to integrated points of sale, to e-commerce, and now to mobile, the threat landscape has changed beyond measure. The corresponding risk management programs have done next to nothing.

Let’s take a quick look at the causes of 3 of the worst card data breaches to date:

  1. T.J. Maxx (2007 – 45.7M Primary Account Numbers (PANs) compromised) – I know this one’s going back a bit, but it’s one of those rare examples of where the PCI DSS was [mostly] up to speed with the prevailing threat landscape. The breach was caused by weak encryption on their wireless access points. Although Wired Equivalent Privacy (WEP) was:
    o
    i)   known to be vulnerable way back in 2001;
    ii)  replaced by WPA in 2003;
    iii) deprecated by the IEEE in 2004, and;
    iv) addressed specifically in the DSS from as early as v1.0 – “4.1.1 For wireless networks transmitting cardholder data, encrypt the transmissions by using Wi-Fi Protected Access (WPA) technology if WPA capable, or VPN or SSL at 128-bit. Never rely exclusively on WEP to protect confidentiality and access to a wireless LAN.
    o
    …T.J.Maxx still had WEP as its standard. This vulnerability (plus horrifically poor network segmentation) lead to the compromise. It also took T.J.Maxx 18 MONTHS to find out.
    o
  2. Target (2013 – 40M PANs compromised) – Network access credentials stolen from a 3rd party and used to remotely log in to systems in-scope for PCI. An HVAC provider at that! Where to even begin on where Target went wrong?! But we can assume:
    o
    i)   vendor due diligence and management was sub-standard (addressed in Requirements 12.8.x);
    ii)  vendor access standards and monitoring were not in place (addressed in Requirements 8.1.5.a, 8.1.5.b, and 8.3.2.a);
    iii) change detection mechanisms were either not in place, or ineffective (addressed in Requirements 6.4.x);
    iv)  logging and monitoring mechanisms were either not in place, or ineffective (addressed in Requirements 10.x), and;
    v)   network segmentation was inadequate.
    o
  3. Home Depot (2014 – 56M PANs compromised) – Similar to Target, which makes this one even more embarrassing and unforgivable.

If we were to look at the thousands of other breaches that have occurred we would find little difference. It’s not so much concerted attacks from dedicated and skilled hackers that’s the problem, it’s the complete disregard for basic security practices by the vast majority of organisations. Organisations who KNOW better, but have chosen instead to just roll the dice.

I’m not saying that these three examples were not perpetrated by skilled hackers, but the level of skill required was significantly less than it should have been. In fact, if these organisations only had DSS levels of security controls in place, the attacks would have significantly more difficult. REAL security would have made these targets of last resort.

What Are You Going to Do About It?

As the South Africans say; If you want security, build your fence higher than your neighbour’s.” The reason the PCI DSS exists is because no one was building any fences!

The right things to do for security have, quite literally, been written down for generations. Ignore these basics and the upcoming regulations related to privacy will make PCI look like a walk in the park by comparison.

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

The Evolution of the PCI DSS, From v1.1 to v3.2

In honour of the SSC’s 10th year in power [oops!] business, I thought it would be interesting to run a little retrospective.

On December 15th, 2004, a day that will live in infamy, Visa released the Payment Card Industry Data Security Standard (PCI DSS) v1.0.

~2 years later, the PCI Security Standards Council (SSC) was formed, closely followed by the release of DSS v1.1.

Six iterations later, here we are at v3.2.

To emphasise yet again just how sad I am, I chose to map v1.1 against not just the v3.2 standard itself, but its corresponding Report on Compliance (RoC) Reporting Template . While this seems like an extreme comparison (download it here), I wanted to get the full flavour of just how PCI compliance assessments have evolved in the 10 years since v1.1’s debut.

At first blush, they would appear to be radically different. For a start, v1.1 was just 17 pages long, v3.2 is 139 pages, and the RoC Reporting Template is a whopping 198 pages! But what becomes clear very quickly is that most of the changes are related to assessment guidance, validation guidance, and wave after wave of clarifications.

I mean, seriously, excluding the Bill of Rights the US Constitution has only been amended 17 times in 227 years!

Take Requirement 1.1.1 for example, this is what v3.2 looks like in the v3.2 RoC Reporting Template:

Screen Shot 2016-08-10 at 10.46.04

This is from v1.1:

Screen Shot 2016-08-10 at 10.39.46

Radically different, right?

Not really, everything in 1.1.1.a – 1.1.1.c is validation guidance, nothing more. In other words, if the original v1.1 assessors were doing a good job, this is how they would have assessed their clients back in 2006.

But they weren’t doing a good job. Not even close. Even into v1.2 QSAs were still filling out ‘Yes’ for in-place and ‘No’ for not-in place.

What we have seen from v1.2 onwards is the gradual increase in detail related to the validation that has to be performed. From v2.0, a separate document was provided to QSAs, the ‘ROC Reporting Instructions for PCI DSS v2.0‘ that broke down what was expected during compliance validation.

This was also implemented poorly by a lot of QSA companies, while others were clearly unaware of its very existence.

Roll on DSS v3.0, the version that caused by far the biggest stir in the PCI community since the DSS’s initial release. There were shouts from the merchants that the SSC had just raised the bar to unacceptable heights. There were even complaints from QSAs that the ‘new’ instructions would increase the workload to the point assessments would be unprofitable. And worst of all, the more unscrupulous QSA companies actually raised their prices! Here are my thoughts on those companies; PCI DSS v3.0 – Do NOT Pay More For Your QSA Services!

The fact is that v3.0 was a consolidation of the DSS Requirements and the Reporting Instructions, and little more (detailed mapping here). If the QSAs and the organisations they were assessing had been performing assessments properly, the effects would have been minimal.

How Similar is v1.1 to v3.2?

About 82% according to my calculation. Obviously this is at the overarching control level, not the validation detail. v1.1 had exactly zero guidance in that regard.

Other than some wording and requirement numbering changes the controls have remained remarkably consistent.

…and the ‘major’ changes aren’t really that major. Certainly nothing outside of basic common sense:

  1. Req. 1.1.3  – Cardholder Data Flow Diagrams – [How would you determine scope in the first place?]
  2. Req. 2.4    – Asset Inventory – [Seriously, how could you possibly achieve PCI compliance without one?]
  3. Req. 5.x    – Make sure anti-virus are actively running etc. – [Really!?]
  4. Req. 7.x     – Additional requirements around job classification etc. – [RBAC is RBAC, this should never have needed changing.]
  5. Req. 8.6    – ‘Other’ Authentication Mechanisms – [About time non-password stuff was introduced.]
  6. Req. 9.3    – Physical access based on job function – [As opposed to?]
  7. Req. 9.9     – Protection of Terminals (only affects retail) – [Sigh…]
  8. …etc…

So What Are You Saying?

There are two ways to look at these results:

  1. The main controls of the DSS were correct from the very beginning and there has been no change in either the threat landscape, or security technology; and
    o
  2.  The card schemes do not WANT to make significant changes, because they already consider the controls to be risk reduction enough. Not to mention the poo-storm that would descend on them if they did.

I think we all know that the first option isn’t true, so that leaves the second. And can you really blame them? Besides, what does it really matter, the DSS will never have the opportunity to improve much beyond minor clarifications. Payment cards just don’t have enough life-span to warrant anything else.

Nothing more to add really, now I need to go get a life.

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

PCI SSC: Effective Daily Log Monitoring

PCI SSC: ‘Effective Daily Log Monitoring Supplement’ – They Missed Again

The SSC released their Information Supplement ‘Effective Daily Log Monitoring‘ in MAY, and I’m only just hearing about it now! Either I’m completely out of the loop (not being a QSA) or the SSC did a very poor job PR-ing it.

I think I understand which it is now that I’ve read it.

Anyway, despite the blatant oxymoron in the document’s title, and my own predisposition toward negative bias where the SSC is concerned, I was still hoping to be pleasantly surprised.

I wasn’t, but nor was I as horrified as I have been while reading output from other SIGs.

It’s actually a really good beginner’s guide to logging, but it’s completely unsupported by the DSS in its current form. And it’s not just me looking for faults, they have not put logging into a proper, or even accurate, context to the DSS requirements as written. With their knowledge of best practice, they basically made the rookie mistake of assuming requirements mean more than they do.

To be clear; If it’s not specifically spelled out in the standard, it is not mandatory. Period / full stop. Even if it’s the right thing to do.

For example: There is no requirement for any automated alerting. Not from firewalls, not from A/V, not from IDS, not from FIM, and not from ‘system components’ like servers and applications. So the statement; “The PCI DSS recognizes the importance of proactive monitoring of security logs in the detection of attacks on information assets and the protection of those assets from compromise.” is inaccurate. The SSC might recognise the importance of pro-active monitoring, the SIG’s participants clearly do, but the DSS only recognises the need for what amounts to forensic evidence. Nothing more.

The DSS uses the word ‘alert’ in only 6 relevant Requirements:

  • 6.6  For public-facing web applications, ensure that either one of the following methods is in place as follows:

• Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:

– Is configured to either block web-based attacks, or generate an alert that is immediately investigated.” – [Alerts are non-mandatory, and can be manually generated.]

  • 10.5.5  Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).” – [No time-period defined, so you have to assume weekly like 11.5, or at most daily like 10.6. Alerts can be manualy generated.]
    o
  • 10.6 Review logs and security events for all system components to identify anomalies or suspicious activity.

Note: Log harvesting, parsing, and alerting tools may be used to meet this Requirement.” – [Non-mandatory]

  • 11.1.d  If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), verify the configuration will generate alerts to notify personnel.” – [Non-mandatory, and/or no time-period defined.]
    o
  • 11.4  Use intrusion-detection systems and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.” – [Alert how? Automatically or during a daily review?]
    o
  • 11.5  Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.” – [Weekly notification, so clearly does not require automation.]

So if there’s no requirement for automatically generated alerts, and daily is the maximum defined review timeframe, how can they possibly insist on 24/7 availability related to Incident Response (DSS Req. 12.10.3)? Who is going to choose 2AM for their daily review?

Even the SIG makes the statement; “Without automated alerting mechanisms, it is almost impossible to identify and alert about such events in near real-time.“. In other words, in time to actually do something about it before it gets out of hand.

But I thought this was about effective DAILY log monitoring?

So All In All…

The thing that still confuses me most, is that the DSS is full of mandatory technologies, but a manual and daily review of logs is still OK?! Not one technology in the DSS is required to be utilised properly, and some have significantly less benefit than a Security Incident & Event Management (SIEM) or an equivalent managed service:

  • why require firewalls and routers then don’t mandate review of the traffic logs?
  • why require an asset database, but not an asset management system on which every other security processes can rely?
  • anti-malware is based on signatures so is all but useless
  • intrusion detection is pointless unless the entire infrastructure is baselined to a known-good
  • …and so on.

So of ALL requirements, how can centralised logging and automated alerts not be mandatory?

This post in already too long, and I’ve barely begun to scratch to surface of why logging and monitoring is so important.

There’s no escaping that the document name; ‘Effective Daily Log Monitoring‘ is misleading, it should be called the ‘We Cannot Tell You to Buy a SIEM, But Good Luck Getting Compliant Without One‘. Basically the SSC has all but admitted that the logging and monitoring requirements are completely inadequate, but can think of no way to change them in the DSS. Not without pissing off a lot of people anyway.

Finally, it IS  a good document, worth a read, and kudos to the authors. Unfortunately it’s guidance is meaningless to those without the means to perform anything other than manual daily reviews.

Bonus Material

If you’re interested, I have provided some additional thoughts in my own Logging Supplement document. There are 3 sections:

  1. Breakdown of Existing DSS Logging & Alerting (Non-Server) – There are 5 DSS requirements outside of the established logging and alerting requirements, and are ambiguous at best. They are also not covered appropriately in the SSC’s Supplement.
    o
  2. Missing from the DSS – The SSC’s Supplement did not cover daily review appropriately, nor did then then go far enough to cover appropriate automation. This section covers a few of the major benefits of logging and monitoring properly.
    o
  3. Automating the Daily Review – There are only three processes required to automate the daily review, but it cannot be done without centralised logging and scripting skills, a managed service, or a SIEM.

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