Do we need to encrypt all customer information like first name, last name,address or only those data which are related with card payment.
Encrypting any Personally Identifiable Information (PII) is actually a pretty good practice if you can do it.
Pages 7 & 8 of the PCI DSS security standard tell you what needs to be encrypted. The fields in the category of cardholder data all need to be encrypted if stored/transmitted with the PAN. This includes card holder name (among other data), but does not include the card holder address.
Related
I'm currently new developping large scale webservices and I'd like to retrieve IP addresses from visitors to make some stats about the country/state of origin.
Is it allowed to take IP addresses from clients for internal use?
As this is a kind of personal information, I wonder if it is legal or not retrieving it.
It's not possible for you not to know the client IP (because your site couldn't work without it), but you don't have to keep it. From a GDPR perspective, data is only "personal data" if it can be linked to an individual (even indirectly), so for example you could take the client IP, do some kind of GeoIP lookup on it (preferably local), and then increment a country counter. Then you can simply discard the IP, and the aggregate data you retain has no way of being connected back to an individual, so it's not personal data.
A very simple approach would be a table like this:
Country
Count
France
2
Germany
4
USA
10
So you would just bump the count for the country each time. This gives you the data you're after, but without any privacy impact for your users, and no GDPR exposure.
I want to store Personel data to BlockChain for a company. We want to prove that the data is unchangeable. A Customer in the blockchain will not access or see any other customer data.
But Company will access all customer data and can make any operation and also can follow any operation, any access Log.
Company will store new form type(Personal data) and flag it as a personal data card.
Is it possible with Blockchain?
The best method would be to encrypt the data, but it really depends upon what you are doing with it. If you need to do operations on it, then you will have to use zk-SNARKs, but these are a new field and you would have to do a lot of research to get it working. If you aren't using the data for anything; it's just metadata, then why would you need it to be on a public ledger and validated?
Plus, there is one big problem about storing sensitive data on the blockchain: the blockchain is immutable and once something is on the blockchain, it is stored forever. So what if there comes a time when quantum computers become so powerful that they can break all encryption we have today? Then all your users' personal data will be public on the blockchain.
What is the best practice in terms of data locality in PCI DSS compliance world?
Can I store data PCI/PII data (nope, we are not storing any of the CC#, CVV, or any magnetic stripe data) from one country in another country?
Say for example, the merchant is doing his business in Europe (say France or Germany) and the merchant server and DB is in US, will that be considered against PCI compliance?
PCI doesn't mandate to keep the data locally. They just want you to ensure that the data, wherever stored, is according to PCI DSS regulations. Moving or storing the data outside of the country is generally regulated by the Govt. of that particular country. Like in the case of India, entities were storing the data outside of India but after the RBI(Reserve Bank of India, India's central banking institution, which controls the monetary policy of the Indian currency) regulation was passed to migrate the data (transaction data and its metadata) back to India, all the companies had to do so and provide a declaration.
Best practice is to use a hsm locally. This tokenize all sensitive datafields into hashes. Then the data can be distributed. All reverse lookups have to be authenticated and logged locally with the hsm.
We need to store last 4 digits of credit card, (in order to let customers know which card they have used?) and expiry date (to notify customers that their card is about to expire) for our subscription/recurring payment based SaaS application.
are those two data storage allowed in PCI DSS? Please answer with reference/link to official website or document.
Please note: We are not storing Name On Card and CVV numbers
You should be ok w regard to PCI regulations.
This table lays out what data can be stored:
https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf
"If required for business purposes, the cardholder’s name, PAN, expiration date, and service code may be stored as long as they are protected in accordance with PCI DSS requirements."
-edit-
According to the bottom table in that doc, it says you should be able to store those elements. Since you are not storing full PAN, Regulation 3.4 shouldn't apply to the other elements.
If it helps, we got Level 1 certified and we store last 4 and expiration date in clear text. You don't need audited unless you are Level 1 (assuming Merchant here, not Service Provider).
From what I am reading within the PCI Data Storage Do's and Don'ts PDF (https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf)
You are able to store the expiration date, service code, and cardholder name so long as you do NOT store the PAN.
Direct quote from the PDF:
These data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS requirements for general protection of the cardholder data environment. Additionally, other legislation (e.g., related to consumer personal data protection, privacy, identity theft, or data security) may require speci c protection of this data, or proper disclosure of a company’s practices if consumer- related personal data is being collected during the course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.
I'm investigating the use Authorize.net for a client that has N physical locations, each with their own distinct set of goods to sell and each with their own merchant account. I'm thinking about using the CIM feature, which allows me to store sensitive customer data with Authorize rather than holding onto it myself. That's a big win; I'd prefer not to have to deal with the complexities of managing sensitive data.
However, it appears that the CIM feature is storing this information on a per-merchant-account basis. That is, if I store some customer data Z with merchant account A, I can't use that same data with merchant account B, even though A and B both correspond to the same entity and the data represented by Z is identical in each case. That seems silly: the customer will have to re-enter their data once for each store, even though all the stores are part of one chain.
Is there a way I can do this with Authorize.net? If not, is there an alternative which allows me to reuse customer representations across merchant accounts, without storing the sensitive data myself? Are there other more general solutions that would get me what I want, or do I have to resort to holding onto this data myself?
Unfortunately Authorize.Net's CIM service, as well as all of their services, are on a one-to-one relationship with a merchant account. So if you wish to put a profile in multiple CIM accounts you would have to do it for each CIM individually.
Based on your requirements it looks like you may find it easier to store the information yourself.
You can try to centralize connectiivity to Authorize.net and this centralized service will store the mapping within where user entered his sensitive information, and pass it to centralized authorize.net adapter as part of customer identtity,like so "customers/shop12/user12345" over an encrypted connection. THat centralized service will need a Authorize.nwt credentials table, of course (shopid, apiLogin, transactionKey).
This is a possible solution if your client accepts storing api credentials outside of "shops"