Am I PCI compliant storing CreditCard info in SQL using EncryptByPassphrase()...?
I created a scalar function to encrypt the plaintext CreditCardNumber using this SQL function with a strong phrase and varbinary "salt" of tableid and recordid. The server is also encrypted and physically secure...the passphrase is stored in a text file that requires admin user account to access and must be read each time the function is executed.
The decrypt function that makes it to front end UI is masked with only the last 4 showing.
Is this enough to be compliant?
The decrypt function that makes it to front end UI is masked with only the last 4 showing.
Is this enough to be compliant?
ASKER
We validate and pre auth customers through a third party who actually has the merchant account...with an https web call. I'm asking mostly about federal law I guess...with regard for the requirements of storing the card.
Don't store the credit card information. Let the payment provider take care of this. Getting it 100% right is very difficult and once breached guess who gets the bad publicity and the lawsuits. Think Merriott
ASKER
If it were up to me I would not store the card info. I've been tasked with storing it properly.
ASKER
The reason I'm asking the question is because the old trusty google machine is not giving me a straight answer. I realize the question itself almost requires a room full of geeks and lawyers....in the end it's still just a room full of opinions, but I'm committed to giving it my best effort to secure our data by some kind of industry standard.
My thinking is that...in the event of a data breach we are not found to be negligent.
My thinking is that...in the event of a data breach we are not found to be negligent.
Reread my comments above.
You can only find the exact answer to your question by reading the merchant agreement provided by your specific merchant provider.
Each merchant agreement is unique.
Now let's get to David Johnson's comment of "Let the payment provider take care of this."
If your design is flawed in any way + your system hacked, all company owners (including shareholders holding 1 share of stock) can be held liable (jail time and/or fines) for allowing a breach.
So you have two primary choices.
1) Follow David Johnson's advice + all will be well.
2) If your management is okay with jail/fines for all shareholders, then store credit card data on site.
If #2 is acceptable, then refer to your merchant agreement for what's required to avoid jail/fines.
You can only find the exact answer to your question by reading the merchant agreement provided by your specific merchant provider.
Each merchant agreement is unique.
Now let's get to David Johnson's comment of "Let the payment provider take care of this."
If your design is flawed in any way + your system hacked, all company owners (including shareholders holding 1 share of stock) can be held liable (jail time and/or fines) for allowing a breach.
So you have two primary choices.
1) Follow David Johnson's advice + all will be well.
2) If your management is okay with jail/fines for all shareholders, then store credit card data on site.
If #2 is acceptable, then refer to your merchant agreement for what's required to avoid jail/fines.
To add to Davids last comment:
>>in the event of a data breach we are not found to be negligent.
How do you figure you won't be negligent if you are breached? That is sort of the definition of being breached, isn't it? Your system had a flaw that was exploited. It isn't anyone else's fault.
As far as your description of your setup: If you store the keys/salts/??? in a file on the system, access to it depends on the level of the hack. If the entire server is compromised, they have access, right?
Even if you store the last 4 and other personal info, that is still enough info to phish the customers into potentially revealing the rest when contacted.
Just remember that 100% of security is risk management. Find the level of risk acceptable to the company and call it done. If the company mandates ZERO risk, don't store credit cards or any personal information.
>>in the event of a data breach we are not found to be negligent.
How do you figure you won't be negligent if you are breached? That is sort of the definition of being breached, isn't it? Your system had a flaw that was exploited. It isn't anyone else's fault.
As far as your description of your setup: If you store the keys/salts/??? in a file on the system, access to it depends on the level of the hack. If the entire server is compromised, they have access, right?
Even if you store the last 4 and other personal info, that is still enough info to phish the customers into potentially revealing the rest when contacted.
Just remember that 100% of security is risk management. Find the level of risk acceptable to the company and call it done. If the company mandates ZERO risk, don't store credit cards or any personal information.
ASKER
Many big companies have been breached ...(yahoo, Marriott, Lowe's, etc.), and nonetheless were not fined or punished because they were not found to be negligent. They did everything they thought was by the book and yet somehow someone got in, physically or otherwise. Nothing is 100% secure. My question concerns REQUIREMENTS under the LAW to store billing info.
I store the key on the file system, so that in the entire server would have to be compromised in order for that key to be revealed. The "salt" is stored in compiled code.. so even if the key was revealed, they have no ability to know what I'm using for a salt in code. If there is a more acceptable way I'm all ears.
The server drive is encrypted as well, so they wouldn't be able to get the data, even if they physically broke in and stole the server. The server is also monitored by camera 24/7, and an alarm code on the server room. Only I and the office manager have a key.
I store the key on the file system, so that in the entire server would have to be compromised in order for that key to be revealed. The "salt" is stored in compiled code.. so even if the key was revealed, they have no ability to know what I'm using for a salt in code. If there is a more acceptable way I'm all ears.
The server drive is encrypted as well, so they wouldn't be able to get the data, even if they physically broke in and stole the server. The server is also monitored by camera 24/7, and an alarm code on the server room. Only I and the office manager have a key.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
In general where most people fail physical audits, which you've also left out of your list, is key rotation + key management, which can be tricky.
Refer to your merchant account requirements for details... and... just know some of these requirements are written by people who've never truly worked with securing data (my opinion), because some of the requirements... if followed completely will result in a non-functional system.
Just read your merchant account agreement + do your best.
The likelihood of a physical audit is slim.