On Tue, Apr 17, 2012 at 10:05:51AM -0500, Mark McCullough spake thusly:
> 
> On 2012 Apr 17, at 08:50 , Aaron Sachs wrote:
> 
> > Hello all!
> > 
> > I'm new to the sysadmin profession and my dept is heavily steeped in being 
> > PCI compliant. Are there any useful resources out there that you are aware 
> > of for learning PCI compliance?
> 
> Your best bet is to start by reading the PCI-DSS itself.  Then, find your PCI 
> compliance contact.  PCI compliance is based on your QSA's specific 
> interpretation of the PCI-DSS (assuming of course you are large enough to 
> need a QSA to come in and review your site).  

I have been implementing PCI compliance for years now. Yes, reading the PCI-DSS
itself is critical. 

Aaron, 

While it sounds like your department proably already has lots of PCI skills,
here is how I generally go about implementing PCI compliance at an organization
which has not had it before which may help you understand the process and what
they are trying to do.

My recommended plan of attack:

1. Go peruse the actual PCI-DSS requirements (not just the 12 main
   requirements, each of those 12 have approximately another 12 or more!) to
   get a feel for what kinds of things you are potentially in for.

2. Figure out exactly where your card data is and what you do with it. This is
   critical. This includes card data that just "passes through". Anywhere card
   data passes through any system or wire in your network must be mapped out.

3. Figure out which SAQ applies to you. If you store the card number, it is 
SAQ-D. If
   it just passes through, it is SAQ-C. If you redirect and the card data never
   touches your network, you still have a PCI obligation, it is just less. Read
   the appropriate SAQ.

4. Determine your merchant level. This mostly determines how well they will
   verify your compliance.

5. Read the whole SAQ (A-D) which applies.

6. Since there is a good chance you are storing card data, try to convince your
   management that storing card data is a bad idea.

7. Spend a few days putting together an action and expense plan to become
   compliant with SAQ-D (the most onerous, required for storing card data). It
   will likely cost hundreds of thousands or more depending on the size of your
   org.  They won't like that and will probably decide it isn't worth it to
   store card data.

8. Work to completely expunge 100% of stored card data.

9. Generally speaking, PCI only applies to machines which handle card data or
   machines not separated by a firewall from machines containing card data. So
   to reduce risk and expense it is absolutely critical to reduce the scope of
   the PCI requirements by isolating the network paths and machines which
   handle card data. So plan to subnet and set up more firewalls (not just
   inbound, egress filtering is mandatory).

10. Begin doing all of your remediation and implementation of the required
    security controls per PCI-DSS and use "The Prioritized Approach to Pursue
    PCI DSS Compliance" to plan, prioritize, and triage. 

11. You must always remain PCI compliant. This means the work is never-ending.
    It is definitely not "fire and forget" or "we're done with PCI".  There are
    always patches to apply, logs to review, inspections for wireless access
    points to be done, lots of recurring scheduled items, infrastructure
    changes that require remediation or re-application of PCI controls, etc..

Also read "Navigating PCI DSS: Understanding the Intent of the Requirements".
Management often thinks they can lawyer or weasel their way through a loophole
in the letter of the PCI standard. They can't. And if/when a breach happens
(remember, this is all to avoid a breach first and foremost, compliance with
the contractual obligation to your card processor to be PCI compliant is
second) it is your card processor and the payment brands who will decide
whether or not to sue you and what sort of penalties to impose based on whether
or not they think you were compliant among other things.

-- 
Tracy Reed

Attachment: pgpekrbfOj8OW.pgp
Description: PGP signature

_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to