On Wed, Oct 15, 2014 at 8:59 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 15 October 2014 21:03, Claudio Freire <klaussfre...@gmail.com> wrote: > >>> So you're familiar then with this process? So you know that an auditor >>> would trigger an investigation, resulting in deeper surveillance and >>> gathering of evidence that ends with various remedial actions, such as >>> court. How would that process start then, if not this way? >> >> I've seen lots of such investigations fail because the evidence wasn't >> strong enough to link to a particular person, but rather a computer >> terminal or something like that. > > So your solution to the evidence problem is to do nothing? Or you have > a better suggestion? > > Nothing is certain, apart from doing nothing.
Is solving the evidence problem in scope of the postgresql project? The solution is to not require evidence in order to be protected from data theft. Having evidence is nice, you can punish effective attacks, which is a deterrent to any attacker as you pointed out, and may even include financial compensation. It requires physical security as well as software security, and I'm not qualified to solve that problem without help from a lawyer (but I do know you need help from a lawyer to make sure the evidence you gather is usable). Not having usable evidence, however, could fail to deter knowledgeable attackers (remember, in this setting, it would be an inside job, so it would be a very knowledgeable attacker). But in any case, if the deterrence isn't enough, and you get attacked, anything involving redaction as fleshed out in the OP is good for nothing. The damage has been done already. The feature doesn't meaningfully slow down extraction of data, so anything you do can only punish the attacker, not prevent further data theft or damaged reputation/business. Something that requires superuser privilege (or specially granted privilege) in order to gain access to the unredacted value, on the other hand, would considerably slow down the attacker. From my proposal, only the second form (unnormalized redacted tuples) would provide any meaningful data security in this sense, but even in the other, less limiting form, it would still prevent unauthorized users from extracting the value: you can no longer do binary search with unredacted data, only a full brute-force search would work. That's because the full value id (that I called prefix id, sorry, leftover from an earlier draft) doesn't relate to the unredacted value, so sorting comparisons (< <= > >=) don't provide usable information about value space. So, if there is a chance to implement redaction in a way that truly protects redacted data... even if it costs a bit of performance sometimes. Is avoiding the performance hit worth the risk? I guess the potential users of such a feature are the only ones qualified to answer, and the answer has great weight on how the feature could be implemented. Well, and of course, the quality of the implementation. If my proposal has weaknesses I did not realize yet, it may be worthless. But that's true of all proposals that aim for any meaningful level of security: it's worth a lengthy look. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
