Category: PCI

It is the job of every QSA to help their clients reduce their scope as much as humanly possible prior to inflicting the remainder of the assessment processes upon them. Even the very far from ideal Prioritised Approach from the SSC alludes to this in Milestone 1: Remove sensitive authentication data and limit data retention.

While the remainder of the Prioritized Approach can effectively be ignored, removing ANY sensitive data that is not required will automatically reduce risk. And once the redundant instances of data have been removed, hopefully the number of systems that transmit, process or store card holder data have been equally reduced.

The second part of the scoping exercise is to ensure that ONLY the systems in-scope for PCI are in-scope, and other systems which could be deemed in-scope-by-association are minimised.

There are 3 things that can put a system into scope for PCI:

  1. It directly transmits, processes or stores card holder data – obvious, and will include things like points of sale (POS), back-office servers, network devices and the like.
    o
  2. It’s in the same subnet / VLAN as a device that matches 1. above – not quite so obvious, and provides the greatest opportunity for scope reduction. e.g. you have 2 web servers in your DMZ but only one is relevant to e-commerce. By putting these servers in 2 completely separate VLANs, you can most likely take the non e-comm server out of scope entirely.
    o
  3. It has significant impact on a system that matches 1. or 2. above – This can include things like active directory / scanning servers / log servers / jump servers / system admin laptops and so on, and while they may never directly touch CHD, can significantly affect the security of ones that do. Being in-scope in this category does not necessarily put the other devices in the same subnet in scope, but you need to be careful here.

Unfortunately this is where most organisations start to make the biggest mistake in PCI; focusing on just the in-scope systems. Just because it’s no longer in scope, does NOT mean it should now be excluded from the processes necessary to bring the in-scope systems into compliance with what amounts to the barest minimum of security controls.

Not being in scope for PCI just means it’s a lower priority, and even then you can only make that determination if you have properly performed a Risk Assessment in conjunction with the company-wide data classification and asset management mechanisms. A good QSA will always ask for a risk assessment before they ask for a network diagram.

Segmentation to reduce scope should never, EVER, be exclusive to card holder data and PCI compliance, it should be part of an enterprise-wide project to ensure that all systems have the necessary level of protection per their data classification and their overall criticality ranking to the business.

Any effort to segment based on PCI should be appropriate, sustainable, and above all SIMPLE. Over the course of time organisations can grow organically with new business processes being tagged on to existing ones, and networks becoming more and more complex and ungainly. Unless these changes are implemented with simplicity in mind they can become rapidly unsustainable, and security itself goes out the window.

A good QSA will be able to determine scope and potentially some scope reduction options, a good CONSULTANT will be able to help you define your optimal network and segmentation infrastructure, so choose your help wisely.

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.

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!]

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.

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.