Database Encryption

[original PM]

So with all the GDPR stuff going on everyone is starting to go on about database encryption.

Ok not a new subject but seems to be everyone thinks it is the solution to anybody stealing your data.

However the push back we are getting is the performance overhead which comes with database encryption means that the business could not operate.

Also there is concern that your 'head of database encryption' is now a targeted person and if someone really wants your data them and their family could be at risk.

Does any of you tech geniuses have any thoughts on this subject?

TIA

[Hobosapien]

The weak link will be where the encrypted data needs to be decrypted, i.e. an endpoint, so not necessarily a person that will be targeted.

Rather than look at one aspect of security the whole infrastructure needs appraising.

[original PM]

The weak link will be where the encrypted data needs to be decrypted, i.e. an endpoint, so not necessarily a person that will be targeted.

Rather than look at one aspect of security the whole infrastructure needs appraising.

Well this is the thing for the past x years we have been increasing security etc etc etc

Data is encrypted in transit - firstly it was just data coming into or leaving our data centres, then it was data within the data centres and now it is at rest data.

So in essence what we are saying is that it is impossible for someone to hack into our network (false really because nothing is 100% unhackable but..)

But if someone did hack the network all the data is password protected.

And any data which is moving around is encrypted so even if you could intercept the message the data would be meaningless.

And then we are going to start to encrypted at rest data - which really means encrypting either all of the database or just the PII portions of the databases.


Is this all worth it?

Will this sort of thing just become 'standard' over the next few years anyway?

[NotAllThere]

Also there is concern that your 'head of database encryption' is now a targeted person and if someone really wants your data them and their family could be at risk.

Do you know anything about encryption? Why would the head of db encryption know the keys to decrypt the data?

[original PM]

Do you know anything about encryption? Why would the head of db encryption know the keys to decrypt the data?

That was the point - so do we assume that no one can decrypt the data without the relevant keys/systems.

But can the keys/systems be hacked?

Or rather what happens to encrypted data when you lose the 'key' - is it possible to get it back?

I suppose the sum up the question does the reduction in the possible risk you get by encrypting your data outweigh the overheads of encryption.

And if we assume no system is 100% safe and all systems and data are hackable are you really making a huge difference by encrypting data?

Just asking really??

[oracleslave]

Does any of you tech geniuses have any thoughts on this subject?

TIA

I'm no tech genius but am having all sorts of issues with this GDPR stuff. I'm running a Global HCM implementation in the cloud and there are a raft of requirements we can't currently handle. Probably hampered by the fact it is SaaS and hence access to all areas of source code / database are restricted but examples include:

- Right to be forgotten, how do we anonymise data but also make it available should say pension queries arise 5 years later?
- How do we delete data when people leave or are terminated but keep sufficient information on them so that if they are re-hired they can be identified as having worked there previously
- How do we delete / anonymise all related documents / attachments associated with their emloyee records when they leave without screwing up downstream and down the line reporting requirements

etc etc

[original PM]

I'm no tech genius but am having all sorts of issues with this GDPR stuff. I'm running a Global HCM implementation in the cloud and there are a raft of requirements we can't currently handle. Probably hampered by the fact it is SaaS and hence access to all areas of source code / database are restricted but examples include:

- Right to be forgotten, how do we anonymise data but also make it available should say pension queries arise 5 years later?
- How do we delete data when people leave or are terminated but keep sufficient information on them so that if they are re-hired they can be identified as having worked there previously
- How do we delete / anonymise all related documents / attachments associated with their emloyee records when they leave without screwing up downstream and down the line reporting requirements

etc etc

And these are all the other questions about feasibility.

I am happy to delete/anonymise/archive whatever data we have to.

As long as whoever is making the rules understands that if someone wants that data for some reason it will not be available.

[SeanT]

Encrypt the data that needs encrypting (possibly very little of it) at the application level if you can, then use something like Hashicorp Vault to store the key material needed to decrypt it, which can be leased by the application and periodically renewed. Don't forget to consider the integrity and lifecycle of your backups (it may make sense to decrypt and re-encrypt with different key material with a longer validity and to include decryption in your automated restore testing).

[SeanT]

- Right to be forgotten, how do we anonymise data but also make it available should say pension queries arise 5 years later?

You have a valid and legally sound reason to keep the data and to refuse the request for it to be "forgotten". GDPR doesn't trump e.g. FCA regulation or AML laws.

[DaveB]

So with all the GDPR stuff going on everyone is starting to go on about database encryption.

Ok not a new subject but seems to be everyone thinks it is the solution to anybody stealing your data.

However the push back we are getting is the performance overhead which comes with database encryption means that the business could not operate.

Also there is concern that your 'head of database encryption' is now a targeted person and if someone really wants your data them and their family could be at risk.

Does any of you tech geniuses have any thoughts on this subject?

TIA

Database encryption is not the be all and end all. GDPR is about much more than just have a technology solution in place.

Performance overheads are a historical issue that has been addressed and any remaining overheads can be minimised though proper configuration. In general if you use things like Oracle TDE and encrypt the entire data base rather than trying to do it at row or column level your overheads wont be noticeable in the real world. The only time you may see a significant impact is if your hardware is already under specced.

Correctly set up the only person who would have access to the encryption keys would be the sysadmin responsible for managing the database environment, not the DBA. Other than being read back by the database system to decrypt data when it is legitimately accessed they should only be accessible from the physical console of the server they are stored on.

However none of this addresses the major vulnerability which is the database user accounts. If you don't have good account security for the database users anyone gaining access to an account will be able to extract and remove the data in clear text anyway because thats what they are allowed to do. It's far easier to mount a phishing / social engineering attack to obtain account credentials than trying to threaten an individual who probably doesn't have the access you need anyway.