Category: PCI

In this, my first installment of the PCI DSS ‘Going Beyond the Standard Series‘, I will begin where not only every PCI assessment should start, but where the development of every security program should start; the Risk Assessment.

Just because you take branded cards, or in any way transmit process or store cardholder data, does NOT mean you should drop what you are doing and dedicate an enormous chunk of your IT capital or manpower resources into achieving compliance. Unless a) there is a distinct business benefit for doing so, and/or b) you are actually increasing the security posture of your entire business.

PCI is not about compliance, it’s about not losing cardholder data.

Compliance with the PCI DSS does not equal security, and security out of context has no business benefit. Either start your PCI program with an eye to staying in business responsibly or don’t bother.

Also, there is a very good chance that taking card payments is not core to your business. If you’re a retailer, your core business function is to sell things, taking payment is just a means to that end. Payment acceptance channels in your business should therefore be simple, inexpensive, and secure. If you can do this well yourself, great, if not, why take the risk? And can you truly innovate away from credit cards if you have to do all the work yourselves?

Should you decide that your existing payment channels are fit for purpose, the second question to ask that is how much should you be spending to fix / mitigate / transfer / remove any problems. i.e. a Business Impact Analysis. You would not spend £100,000 to protect £1,000 worth of data, but you likely would the other way around. Do you know what that balance is for your organisation? From my experience, the answer is generally no, and countless hours and capital are/is lost chasing a goal that was never properly defined.

That said, in terms of PCI, if you were doing security properly, you would already BE PCI compliant (mostly anyway), so it makes sense to just focus on security first and achieve compliance in your own time. As long as you have a reasonable project plan to show your acquirer, report your progress on time, and actually work towards your plan, you will pretty much get as much time as you need to get there. It’s the organisations that couldn’t care less, or are egregiously lax in protecting cardholder data that get the negative attention, and possibly the fines.

Sadly, along with Policies, Standards & Procedures, the Risk Assessment is often one of the last requirements to close during a PCI assessment, when, if they were in place at the beginning, the cost AND level of effort to sustain compliance would have been cut in half.

However, the issue is that most organisations do not have internal resources qualified to perform, or dedicated to, this task. It’s far too specialised, and has never been seen as a true value-add to the business. And unfortunately, the resources available to you in the QSA consulting arena are on the whole inadequate to the task of doing anything other than a PCI ‘audit’. So unless you know security, you would probably not even know the right questions to ask.

I probably should have made choosing the right QSA / consultant for your business the first of this series, but I have basically covered that in previous articles / white papers;

  1. How to Sell Security: While designed primarily to help salespeople in the information security arena, it doubles as a paper for anyone looking to BUY security services;
  2. Selecting The Right QSA For Your Business: This could just as easily be called ‘Questions For Your QSA Request For Proposal (RFP)’ as getting the help of a real security consultant and not ‘just a QSA‘ is critical;
  3. It Takes a Consultant to Hire a Consultant: One of the most difficult aspects of choosing the right help for your organisation, which begins with asking the right questions.

Bottom line; If you haven’t performed a Risk Assessment, go back and do it, and if you cannot do this yourself, find someone who can.

If you don’t know the right questions to ask, ask someone who does.

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

In a previous blog How to Achieve Compliance on the Road to Real Security I stated my intention to write a series of articles on; “…the intent of the 12 main sections of the PCI DSS, as well as provide guidance and options on how to go above and beyond PCI…”  Well, here it is …finally.

For this series, I will provide 3 distinct elements for each aspect of the PCI assessment process, the LAST 12 of which will be the PCI DSS v3.0 requirements sections themselves. I do this because you should not even be LOOKING at these until you have completed several pre-requisites.

The first is performing a Risk Assessment, the second is choosing the right QSA / consultant to help you.

Element 1 – Intent: One of the most confusing things about the DSS – to both layman and crappy QSAs alike – is how can a controls standard that is the most prescriptive of any regulation to date, be open to so much interpretation? How can QSAs have different opinions, or worse, how can QSAs working for same QSA company have different opinions?

Well, you just have to look at how many times the word ‘periodic‘ appears in the DSS to begin to figure this one out; 11 times against 5 distinct requirement sections (3, 5, 8, 9 & 10). Or how about ‘appropriate‘?; 15 times, also in 5 distinct requirement sections (2, 4, 6, 9 & 12). Or ‘applicable‘?; 15 times in 6 distinct requirement sections (2, 3, 5, 6, 8, 11 & 12).

But the prize for ambiguity goes to 2.2.1.a.; “Select a sample of system components and inspect the system configurations to verify that only one primary function is implemented per server.”  The SCC does – in v3.0 anyway – provide guidance that this means you should not have functions at different ‘security levels’ on the same server, but ‘security levels’ as defined by whom?

For a number of years the SSC has been trying desperately to bring the standard into line with a more risk based approach. For example, in the requirements section, the word ‘risk’ appears 20 times in v3.0, compared to v1.2 in which it appeared only 5 times; Patching requirements have gone from ‘you will do it in 30 days’, to ‘do it in 30 days IF it’s appropriate’; and so on…

It all boils down to the INTENT of each section, and too often, the standard is seen as a black and white / all-or-nothing checklist with no room to actually fit the security goals into the business as a whole. This is not the case, so an understanding of the intent is critical before making ANY move to become compliant.

Element 2 – Above & Beyond: The second thing I will attempt to do is explain that every requirement is a bare minimum, so going just a little bit above and beyond is not only the RIGHT thing to do, it builds a portfolio of compensating controls that, if applied in total, should enable you and your QSA to have conversations related to risk and not semantics.

Element 3 – Continuous Compliance Validation: The third thing I will do is try to provide some guidance on how to KEEP the controls in place through either automation or process change. Unless your goal is to develop your management systems into those that can provide Continuous Compliance Validation, you’re working much harder than you have to, and your incident response capability will never be optimal.

In the end, this series will NOT be about PCI compliance, it will be about doing security properly and appropriately for your business, compliance will be nothing more than a by-product.

And finally, this is not about credit card data, this is about protecting ALL your information assets. Credit cards are approaching their end-of-life, and with the card brand’s acceptance of Host Card Emulation (HCE) and the enormous pressure to migrate payments to mobile devices, this will happen at an ever increasing pace. Don’t waste your time and effort on ‘just PCI’.

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

There’s a cheesy quote by Norman Vincent Peale which goes; “Shoot for the moon. Even if you miss, you’ll land among the stars.”

This does not apply if PCI compliance is your end goal.

Set PCI compliance as your goal and miss, and you haven’t even made it out of the barrel. However, if you shoot for REAL security, there is a very good chance you’ll achieve compliance with almost any standard or regulation along the way.

PCI has always been, and will always be a minimum set of security controls and nothing more. The SSC has said as much themselves, as have the card brands, as has anyone else who actually knows what they are doing. This is not meant as a criticism of the standard, they don’t have a lot of choice, and any organisation treating PCI as an annual project, and/or is bitching about how difficult it is, deserves what they get.

As I’ve said more times than I care to admit; “Take the phrase ‘cardholder data’ out of the DSS and replace it with the phrase ‘personal information about your family’. Now name ONE requirement you don’t want in place? Seriously, name one. So if you agree that these are nothing more than the most basic security controls, why have you not put them in place already?

In every section of the DSS there is a LOT of room for better practices, for example:

DSS Section 1 – Do you to have device-to-device-only rules configured, or just a business justification for the ones you have?

DSS Section 2 – Do the testing procedures for a system require a configuration standard for every device type, or every individual device?

DSS Section 3 – Can you really perform manual key management well?

DSS Section 6 – Should you include ONLY the OWASP Top 10 in your app security testing?

DS Section 10 – Do you have to log centrally, and can you really perform manual reviews of your log files on a daily basis?

…and so on and so on. And let’s not forget this is still just about credit card data, validated just once a year, and [potentially] only on a small sub-set of your environment.

If you were to perform a business wide risk assessment, then a security controls gap analysis, you would come up with many deficiencies in your security programme. Then, IF you were to actually take this seriously and not just seeing security as an expense, you would come up with a remediation plan that I can [almost] guarantee would achieve PCI compliance on the way to your goals.

Chances are better than even that you have not even performed the risk assessment, so you have no idea what you goals ARE, and look at PCI compliance as something to get out of the way as soon as possible. You will achieve PCI compliance as a tick-in-the-box exercise, throw good money after bad, and start all over again next year.

This is unfortunate, as your appropriate security goals would most likely have kept you compliant throughout the year, saving you a significant amount of time, effort and cost on re-certification. Oh, you would also be a lot more secure.

I bet Target, Neiman Marcus and Michaels wish they had done security properly.

Every time you go above an beyond what PCI requires, you are building a database of compensating controls. The more compensating controls you have, they less constrictive PCI becomes, and the closer you get to applying the expense of PCI to your actual business goals. Eventually there will be no waste.

This marks the beginning of a 12 part series where I will explain the intent of the 12 main sections of the PCI DSS, as well as provide guidance and options on how to go above and beyond PCI so that you can you can focus on the meaning of PCI and not just the words. More importantly, you can focus on your business.

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

In the most ridiculous decision possible, Target have agree to ACCELERATE their ‘smart card rollout’ to the tune of about $100M;

Target to accelerate $100 million chip-enabled smart card program: CFO, Reuters, Feb 03, 2014

Let me say that again; ONE HUNDRED MILLION DOLLARS!

How exactly are these new smart cards (which is EMV / Chip & PIN obviously)  going to reduce “cyber theft” when they do absolutely nothing except prevent card present fraud? It’s not as though this amazing chip-enabled technology actually encrypts the cardholder data point-to-point (that’s a terminal function, if available), so it doesn’t stop Target saving the data post-auth. And because not ALL US retailers and merchants are going to accelerate THEIR programs, Target have done nothing to prevent the real menace; card NOT present fraud.

What are they going to do when their customers start demanding other forms of payment, like mobile? Or when they start losing market share because value-add services won’t integrate with their shiny new static-function payment terminals? Spend ANOTHER $100M?

I’ve said it a hundred times, payments is NOT about the payment functionality itself, it’s about the AUTHENTICATION of the individual trying to MAKE the payment. In that, Target are completely missing the point.

If this is pressure from the card brands shame on them, if it’s pressure from ‘Government regulators’, shame on THEM, but if this is just Target being short-sighted and throwing good money after bad, then I hope their share-holders wake up before it’s too late.

I for one would be really pissed if had a vested interest in this.

Just about everyone who writes on information security has had ample blodder from the Target / Neiman Marcus et al breaches, myself included. Some blame the PCI standards or the card brands themselves, some blame the retailers for not doing enough, and those that are a little more charitable, just blame the thieves.

In the end, it’s not about blame, it’s about learning the lesson, making the necessary adjustments, and moving on responsibly. Unfortunately, this will NOT include being able to move on from credit cards or from the PCI DSS v3.0 any time soon, so organisations wanting to avoid becoming the next Target (excuse the pun), had better pay more attention to their enterprise-wide security program, not just their annual compliance ‘projects’.

Just as importantly, they need to pay VERY close attention to innovation in the payment / authentication space, and advances in more real-time security measures / technologies.

Nothing in the PCI DSS is anything other than a bare minimum, and represents enough security for the card brands to say they are doing what they can. But any organisation who thinks this is enough will eventually lose data, and I for one have no sympathy.

You can look at every single requirement and come up with two choices: 1) Good enough for PCI, and 2) Appropriate for the business. 9 times out of 10, the second option is more difficult to implement, but in almost every instance, it is both easier to maintain, and more secure.

For example;

PCI DSS Requirements 1.X are all about networking, firewalls, segmentation and the like, and while it does stress that every service/protocol/port must have a business justification, it does not state specifically that every individual in-scope device must have least-privilege inbound and outbound rules applied.

  1. 1.1.6.a – Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification for each
  2. 1.2.1.a – Examine firewall and router configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment.
  3. 1.2.1.b – Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment.

Yes, we can imply it means each device (especially 1.2.1.b), and yes, it’s the right thing to do, but no QSA can enforce anything that is not specifically written within the standard. If they had just replaced “the cardholder data environment” with “each in-scope system” DSS Section 1 would be VERY different, and instil a significantly better security posture.

However, if they DID change it to least privilege for every device, is it actually possible to implement and maintain it? Same goes for more robust configuration standards (DSS Section 2), or real-time logging (DSS Section 10), what should be done is very different from what the DSS requires.

In answer to the question, yes, it is possible, and it all boils down to one thing; baselines

Security is not about crunching big data to determine patterns, that’s only truly relevant in forensics when it’s already too late. Real security is knowing exactly what something SHOULD look like performing normally, and reporting everything outside of that. Keep it simple, or it cannot be monitored, maintained, or measured, but the PCI DSS can never go this far.

Hypothetical: If you knew every running service, listening port, and permitted connections each in-scope device should maintain to perform its function, then anything NOT those things should be investigated. That’s a baseline. Security would dictate that you have alerts based on these anomalies for all systems, not a sample of them and certainly not once a year (point-in-time).

How difficult would it be to automate this process so that EVERY system (not just PCI ones) reports back on a daily/weekly/monthly – or ANY period of time less tun a year! – basis to a centralised management console to perform the baseline comparisons? Then what’s to stop you comparing the device’s listening ports to firewall rule sets to make sure they are properly defined? Or comparing them against enterprise policies and standards, or known business data flows?

Not one organisation or security vendor is doing this properly, at least not that I have seen, or not yet. Some vendors do bits of this, but the last thing you want to do is patch together a bunch of separate, non-integrated systems, as the effort to do so will usually outweigh the risk mitigation, or the cost-to-benefit ratio.

However, none of this can happen until you have centralised and accurate asset management, and seeing as the PCI DSS just added that as a requirement in v3.0, most organisations have a long way to go before they can ever achieve this ultimate in security; continuous compliance validation.