Link to home
Start Free TrialLog in
Avatar of Pau Lo
Pau Lo

asked on

PCI compliance on data management/info handling

What are the PCI rules when it comes to data management and information handling of CC/personal data?

The one thing that worries me is you can lock down your database and environment, but sometimes there are genuine reasons for employees to take hard copy extracts of certain data out of a system – for work purposes. Plus many ERP systems have “export” features, or “report” features whereby you can essentially extract sensitive data and save it where-ever you like.

So what are the rules on PCI or any compliance standard which handles sensitive data (i.e. is it HIPPA that handles medical records?).

• About extracting data from information systems via export facilities or reports and saving extracts locally/to servers etc
• Printing data/reports directly from the system
• Taking hard-copy of data/reports from the system offsite

Have I missed any information handling type issue, and if so what are the rules there? I know they’ll need to be policy but what needs to go in that policy for these kind of issues, and what business rules need to be enforced to comply with PCI?
Avatar of TTauri
TTauri
Flag of United Kingdom of Great Britain and Northern Ireland image

Hi,

PCI DSS compliance is a very complex subject and I'd strongly recommend you either get a consultant to go over things with you or spend a lot of time reading through the standard on the official site https://www.pcisecuritystandards.org/security_standards/index.php (Look under document library - the main standard is "PCI DSS v2.0 " but there are also several other helpful documents there.  A lot of the answers to you questions depend heavily on your exact setup and business practice, not something you really want to post online.

That said I'll have a go at answering your questions as best I can.

You mention business need to extract informatin etc - The PCI DSS is only concerned with the credit card numbers, nothing else so as long as you do not export the full card number or any of the authentication details, PIN code, 3 digit security number you should be OK.  For the long card number you are allowed to show some parts of it - this is why you often see just the last 4 digits of a card number.  It is enough to be pretty sure you are dealing with the correct card, especially combined with the card holder name for example, but is not enough for fraud.

Related to this the PCI DSS is completly happy with you doing whatever you want with customers names, addresses, date of birth, etc - there are other data protection regulations to protect those details.

If you do need to extract card number details then you need a genuine business need (do they really need to see the whole card number?), need to secure it and destroy it when done (standard specifies incinerate, pulp or cross cut shred).

Oh and you also need audit trails etc for your systems so you can see who has looded at the card number and when.

One good starting point is to look at the self assessment questionaires - you will save yourself LOTS of work if you qualify for one of the shorter questionaires and if you can change anything you do to enable you to qualify I strongly recommend you try.

If anything is not clear then let me know, but unfortunatly a lot of the correct answers for you will depend heavily on your systems and how you do business.


Oh and good luck!
Avatar of Pau Lo
Pau Lo

ASKER

Thanks for the pointers, and can you send me a link to the self assessment questionarres?
They are on the same document library as the main PCI DSS download.  
https://www.pcisecuritystandards.org/security_standards/documents.php
Look about halfway down or search for "SAQ".  The 4 SAQ questionaires (A - D) are the different versions.  A is easiest to complete, D is hardest.  From what you are saying you will probably be using D or C.

There is a good flowchart to show which one you need to complete on the last page of the SAQ guide:
https://www.pcisecuritystandards.org/documents/pci_dss_saq_instr_guide_v2.0.pdf

One thing I had to do to impress on the people I work with how big this security standard is was print out the whole standard (its about an inch thick) ask them to open it randomly near the middle and start reading.  The biggest thing you can do to make it easier is to simplify your setup to exclude parts of the standard - eg if you can stop using wireless for processing and transmitting card details you save yourself a LOT of work on securing your wireless networks.  If you can put a firewall between the systems that process card details and your marketing department (random example) then your marketing department does not have to comply with the standard.
Avatar of Pau Lo

ASKER

Thanks - is there any PCI requirement about dedicated management hosts? Or logging on to admin servers that house CC databases from workstations via RDP with web enabled, USB enabled workstations?
I don't think that dedicated management hosts are required but any machine that connects to a server with cc details needs to have full endpoint security (AV, firewall, probably locked down USB port etc).  You might find that using a dedicated host for management makes things a lot easier, or at least lets you get compliant short term.

Connections to admin any server with cc data need to be encrypted (RDP can do this just check it is enforced and working).  Remote access is also allowed however for this you need to add dual factor authentication (something like the RSA key fobs that generate numbers) as part of the logon process.

Web access can be an issue, when I looked into this I read it as easiest to block all web access but you could use proxys etc to restrict the web sites that can be viewed and keep a log of who goes where.  
Avatar of Pau Lo

ASKER

Thanks.

>>but any machine that connects to a server with cc details needs to have full endpoint security (AV, firewall, probably locked down USB port etc).

Just going through the document now, do you know which point exactly mentions the above requirement so I can read it up quicker, I've downloaded a 75 pager.
Sorry my mistake - I was thinking more of my setup than the standard itself.  I think that is scattered through the standard, not a single point

AV is required on all machines vulnerable to viruses - AV is in section 5 (page 28)

There needs to be a firewall between the cardholder data and any network that is not compliant, and a personal firewall on any mobile machine or any employee owned machine that is used to connect in (eg laptops) section 1 covers firewalls, section 1.4 covers this point.

USB I do not think is mentioned directly - its just a step we took to ensure that cardholder data/encryption keys/ etc were not copied to a USB stick which could then be lost etc without us knowing.  You need a decent audit trail for where copies of the data are and we decided to limit the places the data could get to to simplify this.
Avatar of Pau Lo

ASKER

>>You need a decent audit trail for where copies of the data are and we decided to limit the places the data could get to to simplify this.

Thanks so much for the advice. With regards to the above, can you go into a little more detail on this and your approoach, and areas you prevented data from getting too?
ASKER CERTIFIED SOLUTION
Avatar of TTauri
TTauri
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial