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.

One thought on “PCI – Going Beyond the Standard: Part 2, The Pre-Requisites

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.