Hi
čt 6. 6. 2019 v 1:23 odesílatel Jan Bilek <jan.bilek@xxxxxxxxxxxxx> napsal:
Hi team,
anyone? Please let me know if this is not a correct group to ask, I'll move it somewhere else.
this question, proposal is much more related to pgsql-hackers forum.
Currently Postgres doesn't support any feature like this. I think so can be hard to implement it to be absolutely safe. Modification of VACUUM statement probably is not problem. Harder work can be index cleaning.
Unfortunately this feature cannot be implemented as extension. It should be implemented in core.
Postgres has not road map - has only ToDo list - but it is mostly unimportant. If you need some feature in core, you should to contribute code.
More informations https://wiki.postgresql.org/wiki/Developer_FAQ
Regards
Pavel
Thank you in advance & Kind Regards,JanOn 2019-06-04 08:56:47+10:00 Jan Bilek 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
