Much attention and excitement within the security world has recently been focused on the lucrative surge in crypto-mining malware and hacks involving or targeting cryptocurrency implementations themselves. Yet the volume of ‘real world’ transactions for tangible goods and services currently paid for with cryptocurrency is still relatively niche in comparison to those that are being paid for every minute of the day with the pieces of plastic we know as payment cards. According to the British Retail Consortium, in the UK, card payments overtook cash for the first time ever last year. An upward trend assisted no doubt by the increasingly ubiquitous convenience of contactless micropayments. No coincidence either perhaps that contactless related card fraud in the UK also overtook cheque-based fraud in the first half of 2017. For the foreseeable future, card payment channels are likely to present a continued risk to both businesses and individuals for the exact same reason that bank robber Willie Hutton gave us in the last century for his chosen means of income. In today’s digital economy, however, agile cyber criminals will not only ‘go’ as Mr. Hutton suggested “where the money is” but will swiftly adapt and evolve their tactics to ‘go where the insecurity is.’ Hence, whilst according to a range of sources EMV chip cards have cut counterfeit fraud at ‘point of sale’ (POS) in the UK by approximately a third since the technology was introduced and similar improvements are now being cited for its more recent adoption in the US, a marked and plausibly corresponding uptake in online ‘card not present’ (CNP) fraud continues to rise. The Payment Card Industry Data Security Standard (PCI-DSS) has formally existed since 2004 to help reduce the risk of card fraud through the adoption and continued application of a recognized set of base level security measures. Whilst many people have heard of and will often reference PCI-DSS, the standard isn’t always as well understood, interpreted, or even applied as best it could be. A situation not entirely helped by the amount of myths, half-truths, and outright FUD surrounding it. The PCI Security Standards Council website holds a wealth of definitive and authoritative documentation. I would advise anyone seeking either basic or detailed information regarding PCI-DSS to start by looking to that as their first port of call. In this blog, however, I would simply like to call out and discuss a few common misconceptions.
Myth 1: “PCI just doesn’t apply to our business/ organization/vertical/sector.”
It doesn’t matter if you don’t consider yourself a fully-fledged business, if it’s not your primary activity, or if card payments are an insignificant part of your overall revenue. PCI-DSS applies in some form to all entities that process, store, or transmit cardholder data without exception. Nothing more to say about this one.
Myth 2: “PCI applies to our whole environment, everywhere, and we simply can’t apply such an obdurate standard to it all.”
Like many good myths, this one at least has some origin in truth. Certainly, if you use your own IT network and computing or even telephony resources to store, process or transmit cardholder data without any adequate means of network separation, then yes, it is fact. It could also rightly be stated that most of the PCI-DSS measures are simply good practice which organizations should be adhering to anyway. The level of rigor to which certain controls need to be applied may not always be practical or appropriate for areas of the environment who have nothing to do with card payments, however. A sensible approach is to, therefore, reduce the scope of the cardholder data environment (CDE) by segmenting elements of network where payment related activity occurs. Do remember though, that wherever network segmentation is being used to reduce scope it must be verified at least annually as being truly effective and robust by your PCI assessor. Whilst scoping of the CDE is the first essential step for all merchants on their road to compliance, for large and diverse environments with a range of payment channels, such an exercise in itself is rarely a straightforward task. It’s advisable for that reason to initially consult with a qualified PCI assessor as well as your acquirer who will ultimately have to agree on the scope. They may also advise on other ways of reducing risk and therefore compliance scope such as through the use of certified point-to-point encryption solutions or the transfer of payment activities away from your network altogether. Which takes us directly on to discussing another area of confusion.
Myth 3: “Outsourcing transfers our PCI risk.”
Again, there is a grain of truth here but one that is all too frequently misconstrued. Outsourcing your payment activity to an already compliant payments service provider (PSP) may well relieve you of the costs and associated ‘heavy lifting’ of applying and maintaining all of the necessary technical controls yourself. Particularly where such activity is far-removed from your core business and staff skill sets. As per Requirement 12.8 in the standard, however, due diligence needs to be conducted before any such engagement, and it still remains the merchant’s responsibility to appropriately manage their providers. At the very least via written agreements, policies and procedures. The service provider’s own compliance scope must, therefore, be fully understood and its status continually monitored. It is important to consider that this doesn’t just apply to external entities directly processing payments on your behalf but also to any service provider who can control or impact the security of cardholder data. It's therefore likely to include any outsourced IT service providers you may have. This will require a decent understanding of the suppliers Report or Attestation of Compliance (ROC or AOC), and where this is not sufficient to meet your own activity, they may even need to be included within your own PCI scope. Depending on the supplier or, service this may, of course, be a complex arrangement to manage.
Myth 4: “Compensatory means we can have some complacency.”
PCI is indeed pragmatic enough to permit the use of compensatory controls. But only where there is either a legitimate technical constraint or documented business constraint that genuinely precludes implementing a control in its original stated form. This is certainly not to be misjudged as a ‘soft option,’ however, nor a way of ‘getting around’ controls which are just difficult or unpopular to implement. In fact, the criteria for an assessor accepting a compensatory control (or whole range of controls to compensate a single one in some cases) means that that the alternative proposition must fully meet the intent and rigor of the original requirement. Compensatory controls are also expected to go ‘above and beyond’ any other PCI controls in place and must demonstrate that they will provide a similar level of defense. They will also need to be thoroughly revaluated after any related change in addition to the overall annual assessment. In many cases and especially over the longer term, this may result in maintaining something that is a harder and costlier overhead to efficiently manage than the original control itself. Wherever possible, compensatory controls should only be considered as temporary measure whilst addressing the technical or business constraint itself.
Myth 5: “We bought a PCI solution so we must be compliant, right?”
The Payment Application Data Security Standard (PA-DSS) is another PCI Security Standards Council controlled standard that exists to help software vendors and others develop secure payment applications. It categorically does not, however, follow that purchasing a PA-DSS solution will in itself ensure that a merchant has satisfactorily met the PCI-DSS. Whilst the correct implementation or integration of a PA-DSS verified application will surely assist a merchant in achieving compliance, once again it is only a part of the overall status and set of responsibilities. IT security vendors of all varieties may also claim to have solutions or modules that although they may have nothing directly to do with payments themselves have been specifically developed with PCI-DSS compliance in mind. They are often sold as PCI-related solutions. If deployed, used and configured correctly, many of these solutions will no doubt support the merchant with their compliance activity whilst tangibly reducing cardholder data risk and hopefully providing wider security benefits. No one technology or solution in itself will make you PCI compliant, however, and anyone telling you (or your board) that it does either does not understand the standard or is peddling ‘snake oil.’ Or both.
Myth 6: “We’re PCI-DSS compliant so that means we must be ‘secure,’ right?”
PCI-DSS should certainly align and play a key part within a wider security program. It should and cannot be an organizations only security focus, however. Nor should being compliant with any standard be confused with some unfeasible nirvana of being completely ‘secure’ whatever that may mean at any given point in time. There have, after all, been plenty examples of PCI-compliant organizations who have still been harshly and significantly breached. Some reports of high profile incidents have voiced scathing comments about the potentially ostensible nature of the breached organization’s PCI compliance status, even questioning validity of the standard itself. Such derision misses some key points. In the same way that passing a driving test does not guarantee you will never be involved in an accident, reasonably speaking, it will certainly decrease those chances. Far more so than if nobody was ever required to take such a test. PCI or any other security compliance exercise should be viewed with a similar sense of realism and perspective. Applying PCI-DSS controls correctly, with integrity and unlike a driving test re-assessing them annually, must surely help to reduce the risk of card payment fraud and breaches. More so than if you weren’t. Something that is to everyone’s benefit. It cannot possibly, however, protect against all attacks or take into account every risk scenario. That is for your own wider security risk assessment and security program to deal with. Maybe yes, it’s all far from perfect, but in the sage fictional words of Marvel’s Nick Fury, “SHIELD takes the world as it is, not as we’d like it to be. It’s getting damn near past time for you to get with that program.”
About the Author:
Angus Macrae is a CISSP (Certified Information Systems Security Professional) in good standing, a CCP (NCSC Certified Professional for the IT Security Officer role at Senior Practitioner level) and PCIP (PCI SSC Payment Card Industry Professional.) He is currently the IT security lead for King’s Service Centre supporting the services of King's College London, one of the worlds' top 20 universities
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire
