A few PABP questions (security, logging, training)

[billy.gilbert]

I have a few questions regarding things that need password protection. Quick background, we are a POS Software system for hair salons. Our software interfaces with a third party processing software.

According to PABP/PCI compliance, is it necessary to have terminals password protected? The only thing that can be done from these terminals is charge/credit by swipe or manual entry.

My next question is logging. Obviously all things related to credit cards will need to be logged. To have PABP compliance with logging should we make sure our software logs everything? Even the sections that have nothing to do with the payment portion of our software, example, the product setup section? Also, our system requires re-authentication each time, it doesn't have any type of cookie system to maintain who was the most recent person logged in.

Another point in the PABP compliance has to do developing training programs and update them annually and with each new version. We rapidly develop our software, but the portion of it pertaining to credit processing is not changed that frequently. Updating training procedures annually can be done, but is it necessary for version changes that have nothing to do with credit processing?

Thanks!!!

[lyalc]

Whole bunch of good questions, so I'll take a stab here. You'll get more direct value by speaking directly to a PABP assessor (i.e. QPASP) as you journey towards PABP.
In my view, getting a QPASP involved early builds mutual undertanding of the product(s) and requirements in your situation.

The PCI DSS intent is to protect against misuse of card account data.
The main 'tools' PCI DSS uses are confidentiality, and accountability.

Maintaining accountability via user logons, and audit logs of key user actions etc is critical to deliver. Certainly, user access to card data (from data entry/capture onwards) needs to logged. "Log everything" is a simplistic but may be a high volume approach, so tailoring log outputs to those actions which will enable a detail log examination to determine 'who did what, when' is a good principle to start with. Anything administrative should be logged - new/deleted users, changed profiles or settings et.

In terms of training, the intent is to ensure that implementers and operators of the product know how to maintain the product in a PCI compliant state.
If the training will maintain that outcome regardless of any change, then don't necessarily update the training - but do record that you have reviewed the changes against the training in order to make that determination.

When in doubt, get advice relevant to your situation from a QPASP.

lyalc

[jbhall56]

According to PABP/PCI compliance, is it necessary to have terminals password protected? The only thing that can be done from these terminals is charge/credit by swipe or manual entry.

POS workstations should identify the clerk conducting the checkout, but do not have to use unique user identifiers/passwords. A lot of POS systems automatically log into a domain with a common user identifier and password. As long as these clerks do not have access to bulk cardholder data, this is acceptable.

My next question is logging. Obviously all things related to credit cards will need to be logged. To have PABP compliance with logging should we make sure our software logs everything? Even the sections that have nothing to do with the payment portion of our software, example, the product setup section? Also, our system requires re-authentication each time, it doesn't have any type of cookie system to maintain who was the most recent person logged in.

From a logging perspective, you need to log enough information to facilitate a forensic investigation in the event of a breach. So, I would agree with your assertion that not everything needs to be logged. Just items that are relevant to the PCI process of processing, storing or transmitting cardholder data.

Another point in the PABP compliance has to do developing training programs and update them annually and with each new version. We rapidly develop our software, but the portion of it pertaining to credit processing is not changed that frequently. Updating training procedures annually can be done, but is it necessary for version changes that have nothing to do with credit processing?

I would agree with you that you should only update things when they change for the PCI part of your software. However, you should consider adding what versions the manual covers so that readers know if it is relevant to the version they are implementing or working with.

[billy.gilbert]

Thanks to the both of you!!