We store encrypted credit card data in our database. With our latest PA-DSS certification, I'm being asked to perform "secure delete" of credit card data when dropping card numbers and CVCs from the database. Dropping for us is either updating the field to an empty string, or deleting the record altogether.
My QSA suggested a method that I have found referenced for file system deletes, but not for databases; the old overwrite-with-random-junk 3 times kind of thing. But I have a hard time understanding how that would be effective in the database.
Has anyone had to answer to this before? I did read where SQLite and MySQL have settings that directly address the issue, but I don't see anything similar in SQL Anywhere.
Thanks for any info.
Update: the url below is one of the few I've found that reference database and secure delete...but the 5 step example they give doesn't make any sense to me (from a database perspective...or any other for that matter)
Much secure is to use database encryption: 1) pcidss also demand using DB encryption 2) when DB encrypted it's impossible to get deleted values directly from DB file. Also temporary files and transaction logs also be encrypted. Or you can use only table encryption mode.
"When table encryption is enabled, table pages for the encrypted table, associated index pages, and temporary file pages are encrypted, as well as the transaction log pages that contain transactions on encrypted tables."
answered 16 Apr '14, 02:44
When the SQLite secure delete pragma is turned on "SQLite overwrites deleted content with zeros"... I couldn't find a discussion of what MySQL does.
SQL Anywhere doesn't have an automatic "secure delete" mode of operation, but if you share the "secure delete" requirements you are expected to meet, someone here might be able to offer suggestions.
Here's a guess...
You might be able to do it yourself by using UPDATE to replace the column to be erased with a value of exactly the same length (random, zeroes, multiple passes, your choice). To be especially thorough, take care not to change the size of the row before doing a COMMIT and a CHECKPOINT. Not changing the size of the row eliminates the possibility of a row split where data is copied to another page, and a COMMIT plus CHECKPOINT ensures the erased data is written to the disk. You could do multiple UPDATE erasure operations in a batch, but don't do anything else to the rows before the COMMIT and CHECKPOINT. Then, after all that is said and done, you can DELETE the rows if you so choose.
Potential problems include old copies of the column in the transaction log file (permanent until erased), backup files (permanent until erased) and in the checkpoint and rollback logs (temporary until CHECKPOINT)... at this point, encryption is starting to look better and better :)
Change of heart!... strong encryption of the data when it is first received is a prerequisite... SQL Anywhere is like any other DBMS, one of its primary goals is the protection of data from loss, so it make MANY redundant copies at MANY times in MANY locations... so if any of those copies are in clear text your job is infinitely harder.