• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 433
  • Last Modified:

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?
0
pma111
Asked:
pma111
  • 5
  • 4
1 Solution
 
TTauriCommented:
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!
0
 
pma111Author Commented:
Thanks for the pointers, and can you send me a link to the self assessment questionarres?
0
 
TTauriCommented:
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.
0
Will You Be GDPR Compliant by 5/28/2018?

GDPR? That's a regulation for the European Union. But, if you collect data from customers or employees within the EU, then you need to know about GDPR and make sure your organization is compliant by May 2018. Check out our preparation checklist to make sure you're on track today!

 
pma111Author Commented:
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?
0
 
TTauriCommented:
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.  
0
 
pma111Author Commented:
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.
0
 
TTauriCommented:
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.
0
 
pma111Author Commented:
>>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?
0
 
TTauriCommented:
Section 10.2.1 - this is where you are required to have an automated audit trail of all access to cardholder data.

For our setup we went more minimal than most people can - we have dedicated machines which are fully locked down on their own network for taking payments.  By fully locked down these are actually linux based, boot straight into a web browser that can only go to the host we allow, are not able to save files, don't keep any history etc.  This does mean that to take payments the users have to move desk which is not ideal.  So for these desktops there is no card data stored so no access to audit.  Also since they are linux based they do not need anti virus (section 5.1 - deploy av software on all systems commoly affected by malicious software) - Somewhere in the PCI DSS supporting documents it states taht Linux is not commonly affected.  Sorry not sure where right now but I'm sure a quick google search will find details.

Server side the card number is processed in memory with our payment gateway then only the first 4 and last 4 numbers are saved.  Since PCI does not define this number as a credit card number we no longer need to audit access to it (we still do not actually use or display it anywhere - the transaction reference code is used to identify the transaction if we ever need to process a refund).  Of course we still need to have lots of security, audit trails of who access the servers and what they do, all security updates applied etc to ensure that nothing is changed which undermines this setup.

So the only places that see the whole card number are the locked down desktops and the server and neither of those actually store it to disk.  Not sure how usefull this will be in your situation though - this is where a solution for one person might be no help at all to another person due to business processes and the specific software in use.

Hope this has at least given you a few pointers in the right direction.
0

Featured Post

KuppingerCole Reviews AlgoSec in Executive Report

Leading analyst firm, KuppingerCole reviews AlgoSec's Security Policy Management Solution, and the security challenges faced by companies today in their Executive View report.

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now