Author: David Froud

Been composing this blog for several months now, and it started when I was thinking about how superstitions begin; It’s bad luck to walk under ladders, or it’s 7 years of bad luck if you break a mirror for example.  And then it occurred to me that these superstitions were probably the only way to scare children into, or out of, certain behaviour.

Walking under ladders, well duh, things fall OFF ladders, so don’t walk under them, and mirrors used to be really, REALLY, expensive, so telling children that breaking them would have horrific consequences makes a lot of sense (in a very negative way of course). I’m surprised that playing with matches didn’t become a superstition, but then again, household-use matches were not readily available until the 1800’s.

Unfortunately, these things have a way of sticking around long after the original cause is either meaningless, or worse, is twisted and perverted by those with a vested interest in the status quo. ‘Heretics’ were burned at the stake for suggesting that the Earth revolved around the Sun, and not the other way around*, and ‘witches’ were similarly killed in horrific ways when they suggested that herbal remedies were better than leaches and other forms of bleeding. Priests and Doctors respectively were very protective of their power.

Human nature has changed very little since then, only societal laws and the more progressive ‘norms’ keep the peace.

I have for years likened information security to insurance, in that no-one wants to spend money on it, but they know it’s a cost of doing business. And more recently I have likened security to the law, because it’s becoming so complex in terms of regulation / legislation / standards etc, that’s it’s often out of reach for the organisations and individuals who need it most.

Now I find myself likening security to superstition, because from the way we’re going, it won’t be long before being in security will have the same stigma as being a tax auditor, a parking enforcer, or a lawyer. QSAs are almost there already because the entire concept of PCI is so limited, but there is no reason true security professionals should not be seen in the same light as those responsible for driving revenue growth or competitive innovation.

Security departments are something people go out of their way to avoid, or to circumvent. They are seen as the department-who-says-no, who will stifle innovation and good ideas, and generally do the one thing that would label them heretics; get in the way of revenue.

Nothing could be further from the truth, as no other department has the knowledge and DESIRE to do the things that make staying is business possible:

  1. Innovation: It’s the 2000s, the vast majority of innovation now is in technology. Who else is best placed to pick the RIGHT technologies to ensure that innovation is implemented in a way that enhances the organisation and not just adds risk?
    o
  2. Business Transformation: Competitive advantage in the information age is now measure in weeks and months, not years, organisations without the ability to adjust critical business processes quickly and appropriately will be left behind. What other department has the knowledge of exiting processes to enable the adjustments?
    o
  3. Revenue Protection: Can you think of anything worse than seeing all your revenue disappear into the hands of regulators because your focus on selling failed to take into account that your processes for doing so were completely inappropriate. I understand completely the pressures, but revenue generation is not about doing what it takes, it’s about doing what’s right.
    o
  4. Reputation Protection: I could have put this under revenue protection, but wanted to break this out as corporate reputation goes way beyond just revenue, and my OCD will not allow for an even number of bullet points. Damage of reputation through loss of data C.I.A. can have long-term negative effects on a business, just ask CardSystems who went from $25M / annum to out of business in less than 1 year after their breach.
    o
  5. Infrastructure Investment Optimisation: OK, long title, but consider that the amount of money spent on PCI is already in the multi-billions, when a huge chunk of that could have been save by adjustments in PROCESS. Technology purchase is the last resort of a true security professional.

I really don’t have an answer to HOW we can ensure our reputations remain unsullied, and there are a lot of so called security experts out there giving the rest of us a bad name, but I think the worst thing to do is fall back one of the phrases I hate most in this world; “It is, what it is.”

Actions speak louder than words, and I will never stop trying to show my clients that security is something to be embraced, not avoided.

Forward this to all your friends or you’ll have 3 years of bad luck.

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 [subsequently] to every modern language.

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 payment 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 payment card, ​they ​​are​ already far more prevalent​. ​Despite all ​of mobiles’s 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 as 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.

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

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.

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.

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 claiming policies AND procedures out of the box, 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 vs. Modular – It is generally best to have each of your separate policies 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, maybe twice, 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.

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