Postgres has spent several decades creating a data store that does its best to make sure data is accessible and never accidentally lost. The cobc8of a secure forensic wipe is anathama to the product goals. To have any hope of implementing such a thing with confidence you'd need to drop most of those resilience features and write directly to block storage avoiding any file system that uses journals or copy on write semantics (like btrfs).
I've built some of the early leading forensic discovery and decommissioning software so I know what's involved. You should never store such information in a database product unless you plan of decommissioning ALL of the media that stores the information once you're supposed to lose custody.
If you're allowed to do this on a periodic basis (say monthly or quarterly) you could, as a policy, make a logical dump of the database and then restore it on a fresh server periodically and then fully decommission the data stores on the prior server. If you have a clustered system for resiliency then round robbin this in an N+1 configuration would work.
Outside of the above - if your custody latency allowences are too short then never store this information in a database product of any sort or even a modern file system. I'd write block storage in fixed sizes to a dedicated partition and then write over the data securely multiple times when you release custody.
Hope this helps,
- - Ben Scherrey
On Tue, Jun 4, 2019, 5:57 AM Jan Bilek <jan.bilek@xxxxxxxxxxxxx> wrote:
Hi,
We've build a Payments Authorisation system (Box solution) on Postgresql database and now we are hitting following issue with our PA:DSS audit - requirement PA-DSS 1.1.4:
<>
1.1.4 Securely delete any track data (from the magnetic stripe or equivalent data contained on a chip), card verification values or codes, and PINs or PIN block data stored by previous versions of the payment application, in accordance with industry-accepted standards for secure deletion, as defined, for example by the list of approved products maintained by the National Security Agency, or by other State or National standards or regulations.
</>
All of these elements of sensitive authentication data are not permitted to be stored post-authorization. If older versions of payment applications stored this information, the payment application vendor is required to provide instructions in the PA-DSS Implementation Guide as well as a secure wipe tool or procedure. If not securely deleted, this data could remain hidden on customer systems, and malicious individuals who obtain access to this information could use it to produce counterfeit payment cards, and/or to perform fraudulent transactions.Unfortunately, description is too ambiguous and our QSA claims that stored is stored regardless of form. Tokens he can live with, but encryption not. But we do encryption (regardless it is happening with a key stored on HSM).
Actual trouble comes with forensics:
<>
1.1.4.c Verify, through the use of forensic tools and/or methods, that the secure wipe tool or procedure provided by vendor securely removes the data, in accordance with industry-accepted standards for secure deletion of data.
</>
Similar with:
<>
2.6 Provide a mechanism to render irretrievable any cryptographic key material or cryptogram stored by the payment application, in accordance with industry-accepted standards.</>
These are cryptographic keys (Host stored HSM keys) used to encrypt or verify cardholder data.
At this stage our QSA was able to identify that data remain on a persistence device (DB files) even after deleting those from our application.
Checking SQLite database, it comes with pragma secure_delete - which is very much what we are looking for. https://www.sqlite.org/pragma.html#pragma_secure_delete
I would appreciate your input on this. Is there any solution already I haven't been able to find in documentation. If not, is there any way we can put this on a road map or even contribute to your code?
Thank you in advance & Kind Regards,
Jan
--EFTlab CTO
