Re: Key encryption and relational integrity - Mailing list pgsql-general

On 2019-03-29 17:01:07 +0100, Moreno Andreo wrote:
> Il 28/03/2019 23:29, Peter J. Holzer ha scritto:
> > On 2019-03-28 18:36:40 +0100, Moreno Andreo wrote:
> > > it's just "separation" (that was OK with the last privacy act, but not
> > > with GDPR
> > I doubt that this is correct. The GDPR doesn't prescribe specific
> > technical means (there may be laws or standards in your country which
> > prescribe such means for medical data, but that's not the GDPR).
>
> That was told me by a privacy consultant, there was an Italian law
> (196/2003) that introduced "minimal security measures", that has been
> revoked with the GDPR appliance.
>
>
> > > The problem is not on the application side... there you can do almost
> > > anything you want to do. The prolem is that if someone breaks in the
> > > server (data breach) it is easy to join patients and their
> > > medications.
> > I sure hope that the doctors are able to join patients and their
> > medications. So at some level that has to be possible.
> It would be possible at application level, that resides on another server
> (so it would be compliant the separation between the pseudonimysation and
> the reverse method)

But why would you assume that an attacker cannot get access to that
"other server"?

> > If you assume a break-in into the server, there will always be a
> > level of penetration at which the attacker will be able to access
> > any data an authorized user can access.
>
> That's not what I got reading the GDPR article... but I may have
> misunderstood (juridic text is non my cup of tea). My understanding was that
> even in a data breach event there should be a mechanism that prevents (or
> "mitigate the risk that") the attacker to gain access to the data in the

Quoting from article 32 of the GDPR:

| Taking into account the state of the art, the costs of implementation
| and the nature, scope, context and purposes of processing as well as the
| risk of varying likelihood and severity for the rights and freedoms of
| natural persons, the controller and the processor shall implement
| appropriate technical and organisational measures to ensure a level of
| security appropriate to the risk, including inter alia as appropriate:

This is basically the gist of technical part of the GDPR. The controller
and processor are responsible to "ensure a level of security appropriate
to the risk", and it is their job to determine how to do that. The GDPR
doesn't say how to do that at all (the legislators were wise enough that
any attempt to do that would result in a mess). So you can't say "the
GDPR says we have to do it this way" (and if your consultant says that
it is probably time to get a different one). You have to consider all
the risks (and yes, an attacker getting access to some or all of the
data is a risk, but a doctor not being able to access a patient's
records is also a risk) and implement the best you can do considering
"the state of the art, the costs of implementation", etc.

> "joined" form, so he cannot acquire that patient John Doe has got Alzheimer,
> for instance, but only that in that database there is a patient which name
> is John Doe and someone that has got Alzheimer.

I'm not talking about the GDPR here, but about the technical
impossibility. If an authorized user (say a doctor or a nurse) can get
the information that John Doe has Alzheimer's (and as a patient one
would hope that they can), then there will *always* be a way for an
attacker to aquire the privileges of that authorized user and get the
same information. There is no way around that. You can make it harder,
but you can't prevent it.

A much better way (IMHO) is to reduce the attack surface: Store only
data you need, allow access only for personnel which are actually
involved in treating that patient, use good authentication, physically
separate systems which can access the data from the internet, don't
throw printouts into the waste paper (don't laugh - that happened). If
there are people who need access to pseudonymized or aggregate data,
copy that data to a separate system ...

        hp

--
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp@hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>