This is the final part in my GDPR Step-by-Step series, and one that, in my cynicism, I see very few organisations even trying to attempt. I have lost count of the number of companies with whom I have tried to implement a continuous compliance program, only to have them stop once they received their initial ‘certification’. In this respect, GDPR will be no different from something like PCI.Continue reading
…or better still, keep doing what you’ve learned, all day every day.
This is the final post in my ‘Going Beyond the Standard’ series – HURRAH!! – and hopefully despite all of the spelling mistakes, grammatical errors, left-field rants, and miscellaneous off-topic diatribes that you have derived some benefit from it.
Timing is pretty good as well, seeing as the SSC came out with their Information Supplement: Best Practices for Maintaining PCI DSS Compliance, and I will say that I have to agree with the majority of its content. However, reading a book on emergency appendectomies does not make me a doctor, so when it comes to the implementation of the ‘staying compliant’ concepts, have an expert help you.
It takes someone very skilled to make things simple, do not half-arse your security.
There is nothing in PCI that you should not already be doing around all of your sensitive data, and there are no validation requirements that should fall outside of standard practices. In fact, you should be validating EVERY day, not once a year, and the only way to do that is to baseline everything and report against exceptions.
I previously used this ridiculous analogy; If every PCI requirement was a tennis ball, you could very easily carry them all from a weight perspective, but it’s impossible to hold them all together without some kind of container (Tennis ball = DSS Requirements, Container = Security Program). In other words, the requirements themselves are basic, but completely out of context from an ongoing management, business, or even good security practice perspective.
The reason PCI becomes so difficult to maintain is because security in general is too often seen as an IT project and not what it is; a business process. The only time it gets the attention it deserves is when there’s a problem, which is already too late.
When I started my own business, and when I began this blog, it was with the following premise; “Security Is Not Easy, But It Can Be Simple.” Yet every business for whom I have ever provided guidance were basically making a pig’s ear of it, and it always revolves around a lack in at least one, but usually all of the The 4 Foundations of Security.
The way I have always phrased it is; “If my boss does not care about something, guess how much I care about it?”, which is why I have made this statement several times now;
“Let’s be very clear; The CEO sets the tone for the entire company: its vision, its values, its direction, and its priorities. If the organisation fails to achieve [enter any goal here], it’s the CEOs fault, and no-one else’s.”
So if you get nothing out of this series of 25 blogs, take that away and do what you can to help them change the culture to one of accountability and responsibility across the entire organisation. It will pay dividends.
Hope you enjoyed the series, and I would welcome any guest blogs that either expand on the concepts on the subjects on which I am weakest (encryption, coding, charm, spelling etc.) or are better than mine if it’s a subject in which you are an expert.
There is no room for ego in security, everyone has to win.
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.
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;
- 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;
- 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;
- 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.
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!]