• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Database Encryption

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

  • quackhandle
    replied
    Originally posted by DaveB View Post
    Easy fix for the latter. Create a new group on the system with rights required for the application to to run and add the SQL user to that. Never, ever, ever allow anything to run as root/admin.

    Make sure to he ask the devs what rights the SQL ussr needs and then ask them why they don't know when they can't tell you. It's their App, they should know. Make sure management / the security team are cc'd in the conversation.
    Yes, you'd think that.

    qh

    Leave a comment:


  • DaveB
    replied
    Originally posted by Lance View Post
    Encryption of data at rest is really only protection against someone stealing the data when it’s at rest. That sounds obvious but it’s key.
    To steal DB data at rest the thief needs access to the DB files or hardware. In reality that means it’s an attack at the OS/physical.
    You are assuming encryption at rest can only happen at the disk level. Encryption in the DB at application level prevents that. Even physical / OS access will not allow access. Take a look at Oracle TDE as an example.

    Originally posted by Lance View Post

    To be useful the data needs to be decrypted, by he DB before being given anywhere, and probably encrypted again for transport. This is the weak point. Oddly enough if you don’t encrypt data at rest the weak point is the same point.
    So if you encrypt data at rest you are strengthening an already strong point in the chain.
    No, if the DB is transmitting data to another system/application over TLS etc. then it encrypts the packets within the application, before it leaves the DB. There is no point outside the application where it appears in plain text.

    If you don't encrypt at rest then anyone with physical or logical access to the file store holding the data can read it. Thats the weak point. Full disk encryption works for anyone stealing the hardware or not having appropriate OS rights on the system, but doesn't protect against rogue sys admins etc. Encryption at the DB application level, such as Oracle TDE, makes sure that only those DB users and admins with appropriate access can read the data.

    Yes, those users could in theory copy the data in plain text form to another location via copy/paste, exporting etc. but your DB users should be trusted and trained not to do that and the application / system config should also prevent them from doing it. They should also only have access to those tables etc in the DB that they actually need access to for the role. This is why account security is so important and why phishing / social engineering attacks can be so effective.

    Originally posted by Lance View Post

    IMO it’s a waste of time and effort. And user credential protection for the DB admins is still the best way to improve data protection.
    No, again, if you don't encrypt at rest, preferably at the DB level then you leave your data open to any who gains access to the files. Legitimately or otherwise.

    Originally posted by Lance View Post

    The only time that rest encryption makes real sense is when you perceive the threat to be the OS admins. And bluntly if they’re the problem then you’re ****ed.
    That's why you encrypt at the application level and not the OS level. You need encryption at rest in the DB rather than the OS to meet your Data Protection commitments to only allow access to the data by those who actually require that access. SysAdmins / Support staff have no reason to be looking at personal data and should not be able to. Encrypt the DB at the application level and not the OS level and you can achieve that. DBA's should be someone on the same team as the DB users and vetted for access in the same way.

    Combine encryption in the application and good account security with properly configured transaction logging and you are mitigating the vast majority of the risks.

    Leave a comment:


  • Lance
    replied
    Encryption of data at rest is really only protection against someone stealing the data when it’s at rest. That sounds obvious but it’s key.
    To steal DB data at rest the thief needs access to the DB files or hardware. In reality that means it’s an attack at the OS/physical.

    To be useful the data needs to be decrypted, by he DB before being given anywhere, and probably encrypted again for transport. This is the weak point. Oddly enough if you don’t encrypt data at rest the weak point is the same point.
    So if you encrypt data at rest you are strengthening an already strong point in the chain.

    IMO it’s a waste of time and effort. And user credential protection for the DB admins is still the best way to improve data protection.

    The only time that rest encryption makes real sense is when you perceive the threat to be the OS admins. And bluntly if they’re the problem then you’re ****ed.

    Leave a comment:


  • stek
    replied
    Originally posted by DaveB View Post
    Easy fix for the latter. Create a new group on the system with rights required for the application to to run and add the SQL user to that. Never, ever, ever allow anything to run as root/admin.

    Make sure to he ask the devs what rights the SQL ussr needs and then ask them why they don't know when they can't tell you. It's their App, they should know. Make sure management / the security team are cc'd in the conversation.
    Use Centrify. Great product.

    Leave a comment:


  • DaveB
    replied
    Originally posted by quackhandle View Post
    In most places this is usually the DBA, as it's the only person who understands encryption. (right or wrong).



    The bain of my life, developers demanding sysadmin on production to run their awful code (okay I am generalising) however far worse is the bad applications that won't run unless the SQL login has sysadmin rights. /rantover

    qh
    Easy fix for the latter. Create a new group on the system with rights required for the application to to run and add the SQL user to that. Never, ever, ever allow anything to run as root/admin.

    Make sure to he ask the devs what rights the SQL ussr needs and then ask them why they don't know when they can't tell you. It's their App, they should know. Make sure management / the security team are cc'd in the conversation.

    Leave a comment:


  • darrylmg
    replied
    Originally posted by original PM View Post
    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
    Also maybe consider:
    - the Intel chipset bugs that allow anyone to snoop on the CPU cache. This is highly unlikely but you never know...

    - is your DB vendor software decrypting the data when it loads it into memory.

    - as others have said, the strength of your policies around segregation of duties.

    - the worldly location of support staff (are they in countries/locations that lack basic physical security measures)

    - the frequency of turnover of staff (general disgruntalledness).

    Leave a comment:


  • quackhandle
    replied
    Originally posted by DaveB View Post
    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.
    In most places this is usually the DBA, as it's the only person who understands encryption. (right or wrong).

    Originally posted by DaveB View Post
    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.
    The bain of my life, developers demanding sysadmin on production to run their awful code (okay I am generalising) however far worse is the bad applications that won't run unless the SQL login has sysadmin rights. /rantover

    qh

    Leave a comment:


  • DaveB
    replied
    Originally posted by original PM View Post
    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.

    Leave a comment:


  • SeanT
    replied
    Originally posted by oracleslave View Post
    - 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.

    Leave a comment:


  • SeanT
    replied
    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).

    Leave a comment:

Working...
X