Ouch.

The Windows machine is going to be a big sore point. Even using it to store the data for a short bit.

This means the CC# has to be encrypted during transit, err the actual CC# has to be stored encrypted everywhere. At no point can it be "in a file or db" un-encrypted, even if the file is transmitted encrypted over the internet or any public part of your network... Windows Desktop are in Black Zone. Application Server and DB servers are in White Zone. Webservers having to be accessed from the Internet and Workstations are in Grey or those kinds of things.

Well, since you *ARE* storing the CC# in the internal system here is what we had to do:

1) Establish a strict policy that NO Payment Card Data is copied, stored, moved, cut-n-pasted, e-mailed, "captured" in anyway shape or form on any computer or computing device, other than stored in the DB and displayed only by authorized persons (more on that). This is a single instance firing policy. Break it once... by by.

2) The CHD DB has to store the Payment Card (Debit, Credit, EFT, etc...) number completely encrypted. There is a Key handling policy framework that has to happen, with two sides (phases) to the deal... a Key manager, someone outside of IT, typically a department head. Then the IT/App side of things which "signs" the key. This is to keep things "honest". These keys will need to be changed/renewed yearly. We start with an initial Key generation request, which goes to the Key Manager, they enter the password/passphrase and it needs to be recorded and put in a safe spot and then once that is done, the IT side can then do it thing and put the "signed" key into place and the old one expired.

3) Levels of access need to established. Those who can and can't see the actual card info. Those who can and can't see the CHD, besides the card info, those that can enter information into the system and edit non-CHD info. This is where access levels can be tricky, since we already had some controls in place for this kind of access and restrictions, it was straight forward. This forced us to goto a single authentication mechanism. LDAP for us as we are 100% Linux. You will probably have to join the Linux machines to the Windows AD Domain setup. Though Root and Administrator for the Linux machines are not LDAP sync'd for other purposes. Also our LDAP servers are outside the LDAP domain for logins, hence my work this week.

4) Keeping track of all this stuff in a documented way for password, access infractions and Human Resources tracking... PCI is not just about the computer systems, they also will want Physical Access to the servers restricted (usually with swipe card and PIN) and logged and monitored with Video for 90 days. We ended up having to put a Camera system with cameras enough, one at each door of our colo cabinets front and back. All because our Colo only goes back 60 days on Video.

5) Now as far as PCI compliance, there is also other parts of this. You hiring processes are part of it. Keeping track of Firing and reasons and so on. Security Incidents and resolutions (infractions of CHD exposure inappropriately, system cracks/compromises and resolutions) all this stuff and you gotta friggin air your dirty laundry to. If you don't have any they "Audit" harder and find stuff to be picky about.

Final review is a long process also, it can take weeks to get all of the Data and documentation in order. They want SCREEN Capture proof of things being what they want, not just an editable list. (like rpm -qa, or iptables-save on a scrolling terminal and getting progressive screens or on Windows shots of all the options screens and configuration set etc)

Good luck and don't be a hardass with the Auditors, do be a hardass with your Boss, they are there to tell VISA that you are doing the right things... and are placing their certification on the line for you and your company. They are just as liable for PCI data leaks as you are, unless they can prove you were hiding stuff from them (which some companies do and get caught with their pants down, remember Heartland?)

Remember *I HATE* PCI Compliance Certification. To me much of the rules and regulations are simply people making policy decisions that do not know better. PCI has a LOT of good things in it... but a LOT of annoying stuff as well.

Compensating Controls when used have to agreed upon by the Auditors. Be fair, listen to them and help them understand, why the a Comp Cont is appropriate in "this" instance.

Sorry for the rambling and ranting... but its hard to not do it... mainly because this week I'm doing the

Do White/Grey/Black Zone Nessus (with Professional Feed) Scans and remediation
Do External Paid for "Rapid7" Scans and remediation
Do Root/Administrator password changes on all machines.

Hope this makes more sense to you, than it does to me... I wandered a bit, but gave you much of what you need to consider and do.

If you need more answers... I'm thinking e-mail would be better.

Our CC processing company told us to use a particular vendor for scans. They have a deal with them, and feed their customers. The security vendor will scan for free, and support you through the process of the SAQ, but they have an ulterior motive.

They want to sell consulting services. And they get to judge if my company is PCI compliant. So any mistep means they can declare us not compliant, and then come in to sell their services. This is a major conflict of interest.

On the other hand, we are tiny, single computer room, 3 servers internally and an external hosted website. They know they can't make any real money from us, so they are usually very helpful by default. They just want us off their plate.

Our new web site passed the scan yesterday and we can put their logo on it. Yay!

Post #346,416 by folkert 8/19/11 12:46:43 PM Reply	Ouch. The Windows machine is going to be a big sore point. Even using it to store the data for a short bit. This means the CC# has to be encrypted during transit, err the actual CC# has to be stored encrypted everywhere. At no point can it be "in a file or db" un-encrypted, even if the file is transmitted encrypted over the internet or any public part of your network... Windows Desktop are in Black Zone. Application Server and DB servers are in White Zone. Webservers having to be accessed from the Internet and Workstations are in Grey or those kinds of things. Well, since you ARE storing the CC# in the internal system here is what we had to do: 1) Establish a strict policy that NO Payment Card Data is copied, stored, moved, cut-n-pasted, e-mailed, "captured" in anyway shape or form on any computer or computing device, other than stored in the DB and displayed only by authorized persons (more on that). This is a single instance firing policy. Break it once... by by. 2) The CHD DB has to store the Payment Card (Debit, Credit, EFT, etc...) number completely encrypted. There is a Key handling policy framework that has to happen, with two sides (phases) to the deal... a Key manager, someone outside of IT, typically a department head. Then the IT/App side of things which "signs" the key. This is to keep things "honest". These keys will need to be changed/renewed yearly. We start with an initial Key generation request, which goes to the Key Manager, they enter the password/passphrase and it needs to be recorded and put in a safe spot and then once that is done, the IT side can then do it thing and put the "signed" key into place and the old one expired. 3) Levels of access need to established. Those who can and can't see the actual card info. Those who can and can't see the CHD, besides the card info, those that can enter information into the system and edit non-CHD info. This is where access levels can be tricky, since we already had some controls in place for this kind of access and restrictions, it was straight forward. This forced us to goto a single authentication mechanism. LDAP for us as we are 100% Linux. You will probably have to join the Linux machines to the Windows AD Domain setup. Though Root and Administrator for the Linux machines are not LDAP sync'd for other purposes. Also our LDAP servers are outside the LDAP domain for logins, hence my work this week. 4) Keeping track of all this stuff in a documented way for password, access infractions and Human Resources tracking... PCI is not just about the computer systems, they also will want Physical Access to the servers restricted (usually with swipe card and PIN) and logged and monitored with Video for 90 days. We ended up having to put a Camera system with cameras enough, one at each door of our colo cabinets front and back. All because our Colo only goes back 60 days on Video. 5) Now as far as PCI compliance, there is also other parts of this. You hiring processes are part of it. Keeping track of Firing and reasons and so on. Security Incidents and resolutions (infractions of CHD exposure inappropriately, system cracks/compromises and resolutions) all this stuff and you gotta friggin air your dirty laundry to. If you don't have any they "Audit" harder and find stuff to be picky about. Final review is a long process also, it can take weeks to get all of the Data and documentation in order. They want SCREEN Capture proof of things being what they want, not just an editable list. (like rpm -qa, or iptables-save on a scrolling terminal and getting progressive screens or on Windows shots of all the options screens and configuration set etc) Good luck and don't be a hardass with the Auditors, do be a hardass with your Boss, they are there to tell VISA that you are doing the right things... and are placing their certification on the line for you and your company. They are just as liable for PCI data leaks as you are, unless they can prove you were hiding stuff from them (which some companies do and get caught with their pants down, remember Heartland?) Remember I HATE PCI Compliance Certification. To me much of the rules and regulations are simply people making policy decisions that do not know better. PCI has a LOT of good things in it... but a LOT of annoying stuff as well. Compensating Controls when used have to agreed upon by the Auditors. Be fair, listen to them and help them understand, why the a Comp Cont is appropriate in "this" instance. Sorry for the rambling and ranting... but its hard to not do it... mainly because this week I'm doing the Do White/Grey/Black Zone Nessus (with Professional Feed) Scans and remediation Do External Paid for "Rapid7" Scans and remediation Do Root/Administrator password changes on all machines. Hope this makes more sense to you, than it does to me... I wandered a bit, but gave you much of what you need to consider and do. If you need more answers... I'm thinking e-mail would be better.
Post #346,426 by crazy 8/19/11 2:02:15 PM Reply	All good stuff Thanks And yes, read it all. Feel free to pour more pain out in an email to me.
Post #346,491 by Steve Lowe 8/20/11 1:52:35 PM Reply	What Greg said. If you need an auditing firm, we had a pretty good relationship with Coalfire Systems. (still true, Greg?) Even with self assessment, you need to prove external scans by an ASV. Check the website https://www.pcisecuritystandards.org/ for the latest list of vendors. Good luck - I'm glad to not currently be a part of that world.
Post #346,514 by crazy 8/20/11 4:44:00 PM Reply	We got the scan vendor Our CC processing company told us to use a particular vendor for scans. They have a deal with them, and feed their customers. The security vendor will scan for free, and support you through the process of the SAQ, but they have an ulterior motive. They want to sell consulting services. And they get to judge if my company is PCI compliant. So any mistep means they can declare us not compliant, and then come in to sell their services. This is a major conflict of interest. On the other hand, we are tiny, single computer room, 3 servers internally and an external hosted website. They know they can't make any real money from us, so they are usually very helpful by default. They just want us off their plate. Our new web site passed the scan yesterday and we can put their logo on it. Yay!
Post #346,580 by Steve Lowe 8/22/11 6:30:59 PM Reply	woot Passing a scan is praiseworthy indeed.

Welcome to IWETHEY!