Software PIN, the Rosetta Stone of Future Payments

For those who don’t know what the Rosetta Stone is, it’s a tablet found in 1799 that greatly assisted the translation of ancient Egyptian Hieroglyphs to every modern language (subsequently).

So why do I use this as an analogy for non-cash payments?

Hieroglyphs​ had puzzled scholars for centuries until the Rosetta Stone unlocked them enough for the translation to move forward to completion. Having a software PIN will effect the exact same unlocking of the transition of non-cash payments from plastic to mobile. We have had credit cards for 60+ years, with nothing in that time anywhere near ubiquitous enough to disrupt them​, now ​we do. And while mobile devices are in no way perfect, and in many ways even less secure than a credit card, ​they ​​are​ already far more prevalent​. ​Despite all ​of mobiles’​ flaws, they ​are being used ​today as a payment medium​, a trend that will continue until plastic is replaced completely (at least in its current form).​

Th​ere are too many reasons​ for the continuity​ to go into​ here​ (sheer functionality being the top one), but it has been slow because until now every mobile payment innovation was just a little too much for people to accept, just a smidge too radical to gain the necessary momentum.

This is probably because none of those innovations kept the most widely used of the authentication mechanisms in the world; the PIN. The enormously complex and expensive chip & PIN (EMV) used for credit cards is accepted globally (if they can afford it), but up till now there has been no way to effect an acceptable level of security on a device that is never going to be as secure a system built for purpose.

But ‘as secure’ is not the point, ‘secure enough’ is. You’re not fighting for perfection and zero loss through theft, you’re fighting for making it too difficult for thieves to bother. This can only be effected by layers of security, the so-called defence-in-depth. EMV put all of its security controls into a single factor (they had no choice), but mobile devices have access to numerous – and ever expanding – options:

  1. Geolocation/Geofencing: Whatever you want to call it, and whatever buzz phrases vendors will come up with next, they all mean the same thing; are you where you should be? Should you be paying for something in Glasgow if you live in London? Maybe, but when you set the areas from which payments can be made, you are removing the majority of the bad guys’ ability to process a fraudulent transaction.
    Yes, there can be privacy issues, but most vendors have dealt with that now.
    o
  2. Device Authentication: Every mobile phone has a serial number, IMEI number, and other built in identifiers. If your device is registered it’s very difficult to use another device to get in the middle. Not impossible, just difficult.
    o
  3. Application Signing and Authentication: Minimal security in and of itself, but is another security layer which ensures as much as possible that only known good apps are used. Apple and Google have their own ways of doing this for downloads, neither of which is adequate. Ongoing application verification can be relatively useful though.
    o
  4. App Blacklisting / Malware Detection: Very early days yet for mobile devices, but in the same way that operating systems anti-virus vendors have made untold fortunes regurgitating known bad things into signatures, mobile devices will have the ability to blacklist apps that should never be running on devices secure enough to authenticate payments.  OS hardening guides (SELinux for example) and version control (Android must be at v4.2 and above for example) are fundamental baselines.
    o
  5. PIN Image ‘Watermarking’: Most internet banking sites now have a facility whereby you can upload a personal image to ensure that your open communication is actually with your bank and not redirected to a bad guy. Mobile  devices make this factor possible and can even be configured into the PIN pad image.
    o
  6. Encryption (Packet and Transport Layer): Obvious stuff, and relatively trivial to circumvent when you have access to the base operating system kernel (where all jailbreaks take place), but still a very valid concept, especially when you consider the very clever technology surrounding things like Secure Remote Password protocol (SRP).

​Even today there are more options than this, and even implementing all of them at once is seamless to the end user once they have registered their device​. Any one of these by itself is clearly inadequate, but can you really see a bad guy sitting in Starbucks cracking ALL of these in the few moment it takes you to pay for your coffee?

By their nature, mobile devices will always be insecure and limited (bloated OSs, battery life, delicacy, theft and so on) and cannot be seen as a long term solution in payments the way the credit cards were, but I don’t think anyone can deny that they will replace plastic. Mobile devices will take payments to places credit cards can never reach, and the functionality and distribution of payment innovation through mobile devices will grow exponentially over the next 5 – 10 years, it just needs something to help everyone make that transition;

The software PIN.

PCI – Going Beyond the Standard: Part 4, The Major ‘Projects’

For first timers to PCI; Regardless of the security posture you THINK you have, the specific controls in the PCI have always – in my experience – resulted in several major efforts in a number of areas. These should be defined up-front and worked in parallel to minimise your efforts and bring your compliance date forward.

For re-certifiers; If you didn’t put management controls around the PCI validation requirements in previous years, you will be doing much of this all over again, at least in terms of providing validation evidence.

PCI compliance is impossible without remediating the relevant action items to do so, and these will not be done until such times as a named person is assigned the task. Not a role, not a department, a person, with a due date and transparent accountability up his/her management chain.

The first step is to define what those major project are in your organisation, then assign a Project Manager to each and every one. I’m not saying you need to hire additional staff, but unless there is a named person in charge of a SPECIFIC goal, things will simply not get done. The trick, however, is to ensure that these people are fully aware of their responsibilities and action items at the very beginning, or the nasty surprises – for which PCI is infamous – will cause roadblock after roadblock.

That’s really all PCI is, a series of action items assigned to an individual, and a QSA in the wings to provide all necessary guidance to keep things moving forward. The better QSA companies understand this, and will have a well defined and proven methodology to take ANY organisation where they need to go. If that’s PCI compliance only, so be it, but a real QSA will give you the option to take the exact same programme all the way to real business-enabling security.

Generally, these are the major projects required for PCI, along with the generic role names usually best placed to own them;

  • DSS Requirements 1.x: Review of firewall / router configuration standards and rule sets / ACLs.
    Role(s): Network Administrators
  • DSS Requirements 2.x: Configuration / Hardening standards for all system types, plus business justification for all functionality (i.e. Running services and listening ports)
    Role(s): System Administrators, Network Administrators, Application Developers, DBAs
  • DSS Requirements 3.x: Encryption of data at rest (hopefully not applicable)
    Role(s): Application Developers, DBAs
  • DSS Requirements 4.x: Encryption of data at in motion – SSL / HTTPS / email etc.
    Role(s): Application Developers, Web Developers
  • DSS Requirements 5.x: Anti virus
    Role(s): System Administrators
  • DSS Requirements 6.1.x – 6.2.x: Vulnerability management (including patching)
    Role(s): [All roles, managed centrally as overarching project]
  • DSS Requirements 6.3.x – 6.5.x: Secure coding / SDLC
    Role(s): Application Developers, Web Developers
  • DSS Requirements 6.4.x: Change control
    Role(s): [All roles, managed centrally as overarching project]
  • DSS Requirements 7.x: Access control
    Role(s): [All roles, managed centrally as overarching project]
  • DSS Requirements 8.x: User ID management / Password complexity
    Role(s): [All roles, managed centrally as overarching project]
  • DSS Requirements 9.1.x – 9.4.x: Physical security at data centres
    Role(s): Facilities / Data Centre Manager 
  • DSS Requirements 9.5.x – 9.10.x: Media management
    Role(s): System Administrators
  • DSS Requirements 10.1 – 10.3.x: Logging attributes
    Role(s): [All roles, managed centrally as overarching project]
  • DSS Requirements 10.4.x: Time synch processes
    Role(s): System Administrators, Network Administrators
  • DSS Requirements 10.5.x – 10.7.x: Log collection, protection, monitoring and retention
    Role(s): [All roles, managed centrally as overarching project]
  • DSS Requirements 11.1.x – 11.3.x: Wireless access point detection, internal/external vulnerability scanning and penetration testing
    Role(s): [Network Administrators, managed centrally as overarching project]
  • DSS Requirements 11.4.x: Intrusion Detection/Protection Systems
    Role(s): [Network Administrators, managed centrally as overarching project]
  • DSS Requirements 11.5.x: File Integrity Monitoring
    Role(s): [System Administrators, managed centrally as overarching project]
  • DSS Requirements 12.1 – 12.5.x: Policy attributes
    Role(s): [Management Designate, managed centrally as overarching project]
  • DSS Requirements 12.6.x: Security Awareness Training
    Role(s): [Management Designate, managed centrally as overarching project]
  • DSS Requirements 12.7.x: Background Investigations
    Role(s): [Management Designate, managed centrally as overarching project]
  • DSS Requirements 12.8.x: Vendor management and due diligence
    Role(s): [Management Designate, Procurement, managed centrally as overarching project]
  • DSS Requirements 12.9.x: Incident response
    Role(s): [All roles, managed centrally as overarching project]

As you can see, a lot of these projects will either be multi-PM’d (you’ll have a separate configuration standard for each system for example), or SHOULD be handled centrally (no point in doing logging in any way but centrally, and as a corollary, Incident Response). Unless some of these things are centralised and maintained centrally, sampling becomes very difficult.

In PCI sampling starts out at 100%, you must earn a reduction in that. The only way to do that is to show how you have: 1) installed all systems identically, maintained them identically, managed them centrally, monitor them centrally and show this from a centralised console of some sort. More on this in later ‘Beyond the Standard’ blogs.

There may be more or less projects in your environment, but unless you engage a QSA at the beginning of these exercises there is no guarantee your hard work will get you where you need to be. PCI is simple when you know what to do, so if you DON’T know, ask.

Security RFPs: You Must Ask the Right Questions

Whom would you want interviewing prospective specialist Doctors if a family member was sick; your plumber, or your GP?

Why then, would any organisation without in-house expertise try to write their own Request for Proposal (RFP) for security services? Or worse, hand it off to the procurement department who know even less, and only have two remits: 1) meet company policies, and 2) get the best price.

As simple as security is, getting the right services (whether consulting, managed, or product) by finding the right help to MAKE it simple, and hopefully, as easy as possible, is probably the most complicated, and the most necessary, thing you can do. It takes an expert to make things simple. Get THAT right and you’re well on the way to a cost-efficient and above all sustainable security programme appropriate for your business.

Taking PCI as an example, here are the steps that organisations take more often than not:

  1. CEO gets the letter from their acquirer stating that they must achieve PCI compliance.
  2. CEO MAY get as far as DSS Requirement 1: Firewalls etc. and glazes over. They hand this off to the IT Director.
  3. IT Director looks at it in a little more detail, but only enough to realise that they’ll need help. He gets budget for a QSA.
  4. Procurement receive the requirements from the IT Director who wrote them based on many assumptions.
  5. Procurement packages up a sub-set of the requirements along without their own standard requirements out to the QSA  ecosystem.
  6. Answers come back to the questions asked and no more, along with a quote based on an inaccurate scope.
  7. Procurement throw out the top and bottom, choose a few in the middle for the next stage and make no effort to refine the selection criteria.
  8. The QSA company who has the best answers to all the wrong questions and is near the bottom in price gets the gig

And what do they end up with? They get what they asked for, and invariably not what they need.

OK, so this is a completely worst case scenario, but you would be as horrified as I am if you actually knew just how close to reality this is. In almost 10  years I’ve been asked for details of my pre-QSA security experience twice, and only once have I been asked to provide personal references. I can get my dog through the SSCs QSA training, and I can sell her to you for a lot less than any of my competition can sell their people, but guess what kind of service you are going to get? About the same actually.

You don’t buy a Smart car then expect it to drive like an Aston Martin, yet you’re shocked and pissed off when your QSA is as much use as hubcaps on a tractor? No offence, but you literally got what you asked for.

Your job as the IT Director (or equivalent) is to do your homework to find the person(s) best placed to then find the services best suited to your business, because they have done it dozens of times for organisation much like yours. And they can do so without any conflict of interest. There are consultants out there who have been in security LONG before they were QSAs, then performed QSA services for many years helping literally hundreds of clients in every industry sector and potentially globally.

These consultants will define the RIGHT questions for your RFP, and then analyse the results before inviting the few decent QSA companies to offer up both their assessment methodology and personnel for appropriate review and interview respectively.

Every service provider out there is trying to maximise their profits – with which I have no problem – but if they are doing so at your expense by giving you inadequately experienced QSAs, tick-in-the-box managed services, or utterly pointless technology then quite frankly you have no-one but yourselves to blame.

The right skills are out there, go find them, or find someone who can.

PCI – Going Beyond the Standard: Part 3, Policies & Procedures

Of the roughly 400 separate requirements in the PCI DSS, 46% of them require the review or examination of some form of documentation. From policy, to procedure, to configuration standard to diagram, a very significant chunk of achieving PCI compliance starts with paperwork.

How is it then that in the 10 years I’ve been performing PCI and PCI-esque assessments the ‘paperwork’ is almost invariably the last thing to close? I’ve seen large organisations get centralised logging in place before they managed to get their policies and procedures in order.

In Want REAL Information Security? Start With Your Policies I have already gone into why organisations should take polices and procedures more seriously, so I’m not going to repeat myself. But I will just say now that if you didn’t start your project to formalise your policies and procedures at the beginning of your assessment, stop, go back, and start there. A good QSA will fail you for crap policies just as quickly as they would for lack of encryption on stored card holder data.

All too often the client response to a request for documentation is to provide a handful of polices taken from the internet with the company name changed, but no effort whatsoever to customise the content in line with reality. Procedures are virtually non-existent, everything is in unprotected Word docs, several years old, and in no way standardised. The look on the faces of those being asked to provide just the location of the official copies is usually one of confusion, or worse, blank incomprehension.

The worst thing you can do is hand your QSA a bunch of crappy docs and say “You tell me what’s missing.” It does not work that way, and all you’ve done is thoroughly irritate someone who should be on your side. It is YOUR job as the client to tell the QSA which documents and specific language YOU think meets the intent of the DSS requirement testing procedures. The best way to do this (if you don’t have access to a GRC tool with DMS built-in, see below) is just to start with the DSS on a spreadsheet and map your existing documents to it. Your QSA will tell you the gaps, which gives you the necessary action items to begin your remediation.

Here’s the one I give my clients, help yourself; PCI DSS v3.0 – Document Mapping Matrix

Other stuff:

  • Policy Content – In terms of policies, procedures and standards, these are the major headings I generally expect to see; PCI DSS v3.0 – Policy & Procedure Checklist.
    o
  • Document Management System (DMS) – This does not have to be a major expense, a folder on an intranet share will suffice, but the point is to have a centralised location to place all of your latest approved documents. They should however have access control mechanisms in place to ensure only those with a real need to see them, can. Some of the more elaborate DMSs will take care of version control, ownership, review cycles and so on, as well as automated mappings to regulatory compliance regimes like PCI. Choose what’s right for your business, and look at the Governance Risk & Compliance tools that may have this built-in.
    o
  • Pre-Packaged Templates – There are many organisations that can offer pre-packaged policy templates, but none that can provide pre-packaged procedures. Best practice policies are numerous and can be customised to suit your business, but procedures are written by your organisation and are necessarily specific to it. Don’t buy anything saying policies AND procedures, and don’t buy anything specific to PCI. Cover your business, and if you have to spend money to get your ‘paperwork’ together, focus more on expert guidance. Avoid policies that match the next two points.
    o
  • Monolithic Policies vs. Object Oriented – It is generally best to have each of your separate polices as stand alone documents with their own version history and ownership, a single policy document is very hard to maintain.
    o
  • PCI Relevance – The phrase ‘card holder data’ should appear only once in all of your policies, in the Data Classification Policy, every other policy refers to the classification in which card holder data was contained (e.g. Highly Confidential).

Like everything in security, getting policies right is not easy, but it is simple. There are many people out there who can help you if you don’t know where to start, and this is not something you should do half-arsed.

Target: Here Come the Vultures

It was inevitable I suppose, that once the dust had settled somewhat the lawsuits would commence. It’s America after all. It’s not bad enough that Target have already spent millions on this event, and will spend millions more patching the problems and covering the losses, now the banks want a piece. The BANKS!

These same banks have MADE millions off credit card transactions over the years, and now that the downside of their venture has reared its ugly head they go crying to the courts to whine about how unfair this all is. I dare say that eventually some of these plaintiffs will be the very Issuers that have managed to block EMV for so long.

Not that EMV would have prevented the breach mind you, it would have made no difference, but the monetisation of the breach would have been far more difficult. My thoughts on why EMV was never rolled out in the US – and never SHOULD in my opinion – is here; Why the US Will Not Adopt EMV (Chip & PIN).

Then there will be the QSA and MSS companies, and the integrity-less leaches who will jump all over this to try to steal the Trustwave client base. They will point to the breach and say that the Trustwave QSAs didn’t do their job, missed something, or worse, that they lied. The fact is that not one QSA or MSS in the WORLD following the PCI DSS as written could possibly find every hole in ANY client’s infrastructure, let alone one the size of Target.

I’m not saying that they did their jobs perfectly, I don’t know if they did or not, but I CAN say that they were not watching EVERY system and EVERY individual, EVERY minute, of EVERY day, which is what it would have taken to prevent the breach. The QSA looked at a justified SAMPLE of systems ONCE in the course of a year, that’s what a PCI assessment is, and the MSS would only be monitoring a fraction of the network traffic.

And then of course there are the journalists covering this story. It’s news, no doubt about that, but HOW it’s told will have repercussions. There are actually very few people in the world who can have a truly valid opinion on this matter, and fewer still who are the people actually writing the stories, which means that most of what you will see is based on either the facts only (yeah, right), or what sells. Decisions get made on sensational stories every day, sadly this will also be the case here.

This entire case is not some lessons-learned exercise, nor should it be used to crucify the named participants, this is an indictment against credit cards and the credit card companies themselves who have done too little for too long to innovate away from the current technology. Card numbers are a liability, EMV is a joke, and PCI is smoke and mirrors.

It’s time for them ALL to go away and allow the true nature of payments to shine. Identity Management will rule the day, not plastic.

I am probably someone with the most reason to jump on the bash-Trustwave bandwagon, but if I don’t – who for many reasons IS one of the people that can have a valid opinion – then maybe you shouldn’t either.

Of course, if Trustwave WERE found to be negligent, then I take most of this back, just not the part about credit cards going away.

PCI – Going Beyond the Standard: Part 2, The Pre-Requisites

Assuming you’ve performed the Risk Assessment correctly, you will already have the majority of the PCI assessment pre-requisites in place, or at least mostly in place. Now it’s time to get them optimised, and formalised.

The 5 pre-requisites are:

Management Buy-In – If you have not already got this, go back and get it, or if you ARE the management, start taking this more seriously. There is nothing more futile than trying to achieve compliance when it’s clear that management couldn’t care less. Even the appearance of caring is enough to galvanise all levels of an organisation to get the job done, thereby saving enormous amounts of resource and capital costs. The Risk Assessment should have all the ammunition you need to show senior leadership the benefits of an optimised security posture as it puts the loss of data asset Confidentiality, Integrity, and Availability (CIA) into terms they can understand; money.

See Top 10 Roadblocks to PCI Compliance and  How Information Security & Governance Enable Innovation for a little context on management buy-in and CIA respectively.

Asset Inventory / Register / Database – Does not matter what you call it, it’s a list of all of your assets with enough data points to make the list relevant. For some reason the DSS did not make this a requirement until v3.0, but I cannot even begin to fathom how anyone ever achieved compliance without one. EVERYTHING you do in security has asset management at its core, and there is no appropriate security without asset management done well. The register will include all physical devices and applications (CoTS, custom and DB) but should also include overarching business processes and even people’s special knowledge or necessary skill-sets.

At a minimum, the asset register should record the following; Unique ID #, Friendly Name, Hostname, IP Address, Function, Make, Model, Location, Owner. Of course, you should go MUCH further than this and add things like compliance relevance(s), system dependencies, running service baselines and so on.

Network Diagram - There are a thousand ways to do this, but really only one way to do it well. You start with your asset register, some network scans, and Visio (or equivalent). As long as all of your assets are represented (does not have to be individually), and every sub-net / VLAN reflected, the rest is just in the detail.  Complex is not sustainable, so if your diagrams are monstrous or very difficult to subdivide, then there is a good chance your infrastructure should be reviewed. However:

  • Layer 1 – IP, VLAN, ethernet port addresses and so on. Network admins use this for troubleshooting and it must be sustained at this level. QSA will use this for rule set reviews.
  • Layer 2 – All detail is taken away leaving only the ‘Friendly Names’ from the asset register.
  • Layer 3 – Business process flows (as many as it takes)

Data Flow Diagram + Detailed Narrative – You cannot have effective change control or business transformation processes unless you can determine change impact on all system dependencies. These flows are an asset in and of themselves and should be treated accordingly (i.e. with ownership, and regular reviews for accuracy).  Something as simple as numbered arrows from systems-to-system will suffice. For PCI, these data flow diagrams must be identical in format to the network diagram, hens the layering in Visio.

The data flow narratives are a ‘painfully detailed’ explanation of what happens to the data at every touchpoint. For PCI this will include storage (location / time), storage of what (data elements), truncation, encryption (type and strength) and so on. This is not a summary, this is everything.

Key Stakeholder Matrix - I have performed  2 month consulting gigs at large organisations where the first 6 weeks was spent finding the right people to talk to. Job knowledge and responsibilities are just as much an asset as the systems they maintain. Incident response and disaster recovery are not possible without application of the right knowledge, to the right place, at the right time, so knowing who knows what SHOULD be mandatory.

Eventually I will provide some samples, but for now, these descriptions should make sense. If not, ask your QSA / consultant, and if THEY don’t know, you should replace them.

These 5 things are not PCI requirements, these are SECURITY requirements. Done properly, everything you need for PCI falls out the back-end.

How Identity Management Will Transform the Future of Payments

For generations – quite literally – credit cards have ruled the non-cash payments world, but it’s now time to start saying goodbye to the ‘plastic’.

At the time of their introduction (way back in the late 1950′s early 60′s) they were a fantastic innovation, and they have rightly had their decades in the sun. Until now, there has been nothing to replace them, nothing anywhere near as widespread, ubiquitous, incredibly versatile, and still growing as a market.

Now there is.

I am talking of course about the mobile phone, but as I will try to demonstrate here, I’m convinced that this is just a reactive and brief stepping stone, and it will not be 60 more years before that next transition comes about.  Actually, it’s already happening.

The table below represents my thoughts on the next steps, and are not based on anything resembling research, known statistics, and maybe even reality. This is just a visual representation of what I believe;

Screen Shot 2014-03-20 at 10.27.12

Credit Cards – Began way back when, and have enjoyed an enormous growth over the years. However, the up-front nature of the card itself has required a massively expensive infrastructure to accommodate it, leaving half the planet un-covered and un-banked. Beginning this decade we will see a rapid decline in their use as consumer choices expand, and issuer’s profits drop.

Mobile Phone - Enormous and unprecedented growth and owned by more people than any electronic product in history. Anyone who believes that the inherent insecurity and inconvenience of battery life will prevent the transition of payments onto this platform is going to be left behind. Nevertheless, these limitations WILL ensure that the transition to what’s next in payments comes much faster than the move from plastic. Rapid advances in battery technology and OS security will maintain the trend for a few years.

Non-Invasive Biometrics – As I’m calling it, but I basically mean wearables and anything else that comes up that starts doing away with the keyboard and begins the process of identity management through non-static authentication (passwords, secret information), and learning the wearer’s physical profile to effect the majority the functionality. Voice at first I assume.

Invasive Biometrics – Implants in other words. There will be those who say this is a ridiculous concept, that it will never take off, but I believe that the next generations will not see this as outrageous, and WILL see the mobile phone as antiquated and inconvenient. Anyone who has seen the 2012 version of Total Recall and the phone implanted into Colin Farrell’s hand either said “NO WAY!”, or like me said “I WANT ONE!”. Batteries will always be a limitation, but the human body IS a battery (of sorts), and it will be harnessed accordingly (hopefully not like in The Matrix).

Cumulative Identity Profiling – Again, this is what I’m calling it, but it’s basically the culmination of the trend toward a totally different idea of privacy, and one that I cannot see clearly because I’m not of this yet-to-be-born generation. Anyone who is the parent of a teenager knows that their kids have never NOT had a mobile  phone, and that almost their entire life is recorded online. The are never unplugged. We are horrified for them, but that’s our judgement, not theirs, and theirs will win. Identity Management and authentication will be a sum total of your life’s experiences, and therefore almost impossible to fake, or duplicate. The whole concept of privacy will be turned on its head.

There are those who say that this can only happen in industrialised nations, those with the money to afford such things, and yes, there will always be a portion of the population who will be out of the loop for a while. However, Mozilla (for example) are releasing a $25 smartphone, and it is estimated that within a few years Africa with have a 50% smartphone adoption. This trend will cover almost everyone, eventually.

The innovation involved with payments is really at the beginning of its evolution, and I’ll probably look back on this post in 5 years time and laugh at my naivety. Nevertheless, the card brands know its coming (hence NFC, HCE etc.), the terminal manufacturers know its coming (hence the rise of phone based mPOS), and the retailers know its coming (hence the push back on EMV), so the only thing left is for the consumer to start making demands and there will be no looking back.

The average consumer will forgo security for convenience, it will be up to the payments innovators to make sure enough security is built in to protect people from themselves. Which I think is unfortunate, but it’s that or educate 7 billion people.

PCI – Going Beyond the Standard: Part 1, The Risk Assessment

In this, my first instalment of the PCI DSS ‘Going Beyond the Standard Series‘, I will begin where not only every PCI assessment should begin, but where the development of every security programme should begin; 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 certification 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, so the payment acceptance channels in your business should 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 that balance for your organisation? From my experience, the answer is usually 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 & 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, the level of effort, AND the effort to sustain compliance would all 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 those 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.

PCI DSS v3.0 – ‘Going Beyond the Standard’ Series

In my previous bog 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…”  Of course, I also stated my intention of writing a book on PCI back in October, so don’t hold your breath.

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 work ‘risk’ appears 20 times in v3.0, compared to v1.2 in which it appeared only 5 times; Patching requirements have done 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 & BeyondThe 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 play-book 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 ValidationThe 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’.

How to Achieve Compliance on the Road to Real Security

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.