Part Three - Defining your scope so you know what you're assessing
This is the third chapter in a series about preparing for and going through a PCI assessment;...
1. Part One - Intro to a PCI on-site assessment & the QSA selection process
2. Part Two - Preparation for an on-site assessment and what to do first!
3. Part Three - Defining your scope so you know what you’re assessing
4. Part Four - Authoring a PCI On-site Assessment RFP
5. Part Five – Selecting a QSA to conduct an on-site PCI assessment
6. Part Six – Preparing your Company and I.T. department for the assessment
7. Part Seven - Important documents to have to manage your assessment
Scope; The first thing you need to start with before anything else is to make sure you know what your scope is. I know this may be hard to do prior to having the assistance from a QSA (chicken before the egg), particularly if this is your very first on-site assessment. But this is the most crucial part because this is what your entire PCI compliance program centers around.
I don’t think I need to go into all the problems and potential liability and compliance gaps you leave yourself open to if you improperly define your Card Holder Environment (CDE). Not to mention how potential wrong your RFP will be, this in return can cause the assessment to explode (can you say scope creep) and expand way beyond what you had envisioned and probably originally budgeted for . . . ooooops! . . . . . let the dominoes fall.
Start off by conducting a payment application/credit card data mapping project to properly map out your payment application environment and CHD flow. You want to do this a couple of months prior to authoring your RFP. Make sure that the payment application/data and process owners have ownership in this project (they should want to know this stuff anyway) to ensure the documentation and flow charts are as accurate as possible, don’t let them dump this project on you.
NOTE; tell them that this documentation is going to be requested by the QSA anyway.
You should also enlist the assistance of the payment application vendors (i.e. Micros, Radiant) to help you and your engineers in properly mapping these elements. Here is a list of things I recommend you discover from this project;
Let’s start with how and where you take card payments;
- Where do you take card payments, stores, kiosks, online, etc;
- What online applications take payments, are they web facing?
- Do you take any physical card payments (i.e. knuckle busters, FAX, etc.
- (if so follow physical security, data retention and disposal requirements)
- Do you take card information over the phone and record this conversation?
- NOTE; This recording and the systems that contain it are now in scope.
Next lets look at the network objects (as PCI calls them);
- Document applications, their versions and patch levels,
- Document the systems (servers) that they reside on,
- Document where on the network these systems are on, and what other systems they communicate with regardless of service,
- What is the classification of that systems (CHD resident, processed, connected, all the above),
- What applications reside on those systems and what other application do they talk to,
Next let’s map out our data;
- What is the state of the data, encrypted, proprietary or plain text,
- If encrypted how, what level/algorithm, is it asymmetric, symmetric, or PKI
- What devices/application have access or hold the keys to decrypt the data
- What system handles the key management
- Where is the data, where does it start, the card swiper, “Swiper No Swiping” (that’s for you daddy’s out there)
- Map the CHD as it travels through the payment application systems and ask;
How does the data move through the network;
- If you have remote stores (such as a retailer or restaurant) how are your stores connected to the corporate network, MPLS, VPN or what.
- If applicable, you should also make sure your MPLS contract has specific language in it that addresses security issues (you network admins know what I am talking about) and privacy. For more about PCI and MPLS reference this white paper.
- Find out what the state of the data is as it travels through each segment of the network and through the cloud.
- Who has the keys to the castle and what is the level of their access;
- System administrators,
- Database administrators,
- Application administrators,
- Encryption Key Administrators,
- During this process, document job roles, users and/ or persons that have bulk access to card holder data.
Note; do not get too much into the weeds during this process, the purpose of this endeavor is for scoping the assessment, not conducting one (YET).
Now wasn't that fun!
