does pcidss compliance require UNIX auditing?

Hey;

I'm looking through the pcidss ver 2 requirements and the phrasing of the requirements, particularly in req 10, suggest that full blown auditing is required. I haven't had to use auditing since I left the USAF and left my TS/SCI clearance behind, thank god. My experience with it, while dated, is that it is hard to configure, hard to administer, and generates an unholy amount of data most of which is worthless.

Has anyone implemented an acceptable *not auditing* solution to support reqs 10.2.1 (individual access to all cardholder data) and 10.2.3 (access to all audit trails)?

If auditing is required, has it gotten any easier in the past 10 years?

Any info, greatly appreciated.

Doug O'Leary

dkoleary <dkoleary@olearycomputers.com> writes:
>I'm looking through the pcidss ver 2 requirements and the phrasing of the r=
>equirements, particularly in req 10, suggest that full blown auditing is re=
>quired. I haven't had to use auditing since I left the USAF and left my TS=
>/SCI clearance behind, thank god. My experience with it, while dated, is t=
>hat it is hard to configure, hard to administer, and generates an unholy am=
>ount of data most of which is worthless. =20

>Has anyone implemented an acceptable *not auditing* solution to support req=
>s 10.2.1 (individual access to all cardholder data) and 10.2.3 (access to a=
>ll audit trails)?

>If auditing is required, has it gotten any easier in the past 10 years?


Note, I'm not an authority on PCI/DSS, I'm only giving my readings and
how it applies to me in my enviornment.

This depends quite a lot on your setup of course, and just where
credit card data may be stored. If you are dealing with some ecommerce
site on a unix system that just collects the data, approves it through
some gateway like Authorize.net and forgets the data, then there is
very little to require audits of credit-card data access because you
don't have stored copy of the credit card data.

If OOTH, you do store and retain credit-card data (the most security
intensive variant of PCI/DSS requirements), rethink if you need to. :)
If you do need to store and retain credit-card data, then my take on
the audit requirements are retaining a log of who/what accessed the
credit card data and for what purpose. Most likely, this will be of
the form of Jim in A/R ran the batch queue to post charges against
this set of credit-cards. Your audit requirements are that you log
that Jim's account accessed this card # at this timestamp.

This requirement is so that you can authoritatively say who had accessed
what at any given time.

And 10.2.3 requires that you protect your logs and user access to the
access logs is logged. I think in most environments this would be
sufficient to be logged to a remote secure bastion log host that has
extremely limited access, and you can verify that access events are
logged and secure there.


I don't think either of these events require full-blown unix audit
trails of every user action on every system.

You mention a certification of yourself as well. Neither of these
sections deal with personnel, although there are other sections inside
PCI/DSS about requiring background checks and other reasonable actions
on the employees that have access to credit-card data. Restricting
back access to only those that absolutely need to obtain credit-card
data is a given.

Hey;

Thanks for the reply.

>>Most likely, this will be of the form of Jim in A/R ran the batch queue to post charges against this set of credit-cards. Your audit requirements are that you log that Jim's account accessed this card # at this timestamp.

That's the part that I'm unclear on. Outside of full blown auditing, from the OS level, does anyone know how that can be done?

It also doesn't help that I'm not all that clear on the application that myclient's using. If the only people that require a login access to the unix system are the admins, then this suddenly gets a lot easier - it's the application that has to ensure that it logs Jim accessed this card # at this time...

Thanks again for the response.

Doug O'Leary

dkoleary <dkoleary@olearycomputers.com> writes:
>>>Most likely, this will be of the form of Jim in A/R ran the batch queue t=
>o post charges against this set of credit-cards. Your audit requirements ar=
>e that you log that Jim's account accessed this card # at this timestamp.=
>=20

>That's the part that I'm unclear on. Outside of full blown auditing, from =
>the OS level, does anyone know how that can be done? =20


Well, credit card data doesn't really live in the OS, it typically
lives in a database, and you have applications that access that database.
That is where you need to be logging access, in the application level.

For instance, in the system I need to maintain (albiet not on unix),
each user has their login into the billing application. The
application logs every major action they do. Ie. Jim expired these services.
Jim ran this credit card batch. The batch comprised of these customers.
At any given time, and admin can login to the application and pull an
audit log on Jim's actions for the day, or a audit log of what credit
card data was accessed.

While I do have a Unix application interface to this secure system, it
can't even access credit-card data due to security levels on the DB
server, but it does require unique user logins. If it could access
secure data, it would have to be recoded in such a way to have audit
logs of the actions of each of those users, and what actions they did
as well. Those logs would have to be secure and unalterable in a
reasonable fashion.

Also, PCI/DSS requires credit-card data to be stored encrypted, even
within a database, so you'll need some sort of column encryption.


>It also doesn't help that I'm not all that clear on the application that my=
> client's using. If the only people that require a login access to the uni=
>x system are the admins, then this suddenly gets a lot easier - it's the ap=
>plication that has to ensure that it logs Jim accessed this card # at this =
>time...=20

Yes, application logging should be the main thrust.

As another wrench, PCI/DSS also requires machine functions to be
dedicated to the main task. Ie. a DB server should be only a DB
server. A web front end should only be a web front end, not a file
server, mail server, etc. etc.

So, theoritically, only the admins should have access to any DB server
that holds credit-card data, and there should be no user logins there
at all.


And in the end, we see time and time again that all of these items are
not followed even in the biggest sites.