Re: Effective database column level encryption?

Security is a big issue. There really are no short-cuts that can be taken with it at all. No magic bullet, no "if we focus on protecting x, then we're safe". The real idea is to balance the effort / reward ratio such that the business down the block is a more tempting target for miscreants.

In order to do this, you need to restrict the storage of user / client data to the absolute minimum amount essential to the running of your business. If this means customers have to enter credit card details more often, or have to setup direct debits for regular payments, so be it.

Once you've identified the bare minimum of information required, you need to ensure that you have done the basics to protect it. Things like multiple layers between your web gateway and your backend servers, using restricted accounts for everything (other than the very few individuals requiring root to maintain your systems and having company policies that very clearly state how and when those individuals should be using root access), firewalling the f**** out of your network (not just external interfaces, but internal (possibly departmental) segregation as well). Logging the heck out of anything and everything relating to security and access to sensitive infrastructure.

When you have everything locked down and logged, then you need to regularly review it. This might just mean internal reviews by appropriate staff, however if you are a large organisation, or hold particularly sensitive information, then you probably want to get external security specialists in to perform penetration testing and otherwise review your policies and procedures on a regular basis (we do this once a year, in addition to internal monitoring and reviews).

Beyond that, keep your eyes and ears open and try to learn from others mistakes.

EDIT: In response to your specific question about SQL, yes encrypting particularly sensitive data with an appropriate scheme is an absolute must (as it prevents attackers from simply copying out your DB and going their merry way - They have to take the time to figure out what you're doing, where keys are stored, etc). Designing security systems that take a long time to work out / hack into is a delaying tactic designed to give your monitoring team time to detect the intrusion.

Comment on Re: Effective database column level encryption?

Replies are listed 'Best First'.
Re^2: Effective database column level encryption? by maruhige (Novice) on Dec 02, 2015 at 12:12 UTC
During my trial implementation with DBIx::Class::EncodedColumn::Crypt::OpenPGP i've hit on a notion regarding key storage which I'm wary of being security theatre and/or reinventing a wheel and would appreciate some guidance. Context wise I'm working towards a VPS in a 3rd part data center installation where security is more important than uptime. It's based in Switzerland but that's no reason to be complacent. Since shared secrets can be stored in a .pm, is there any particular reason said .pm should not be stored on some seperate machine and downloaded, loaded and deleted at initial run time when the system resides in a persistent execution environment e.g. Catalyst? If the key host is switched on solely when the system is manually started I don't see how it would be possible to access the secrets barring physical access to the server and data recovery tools. Furthermore, if this is a good idea someone more experienced than I has surely done it already. Thoughts?	[reply]
Re^3: Effective database column level encryption? by Corion (Patriarch) on Dec 02, 2015 at 12:24 UTC
If this is run within a VPS, you must also trust the VPS provider and the supervisor OS not to have backdoors/faults like Xen and others had discovered recently. If your attacker can become `root` on your VPS, they can also "simply" extract the key by reading the memory of your process: `open my $process, '<', "/proc/$apache/mem"; binmode $process; binmode STDOUT; print $_ while <$process>;` [download] But unless you can store the key on a hardened USB encryption/decryption device and perform decryption on that device, having the key only in memory reduces the attack surface a lot. Your attacker has to attack the live machine(s) instead of for example attacking a backup tape.	[reply] [d/l] [select]
Re^3: Effective database column level encryption? by SimonPratt (Friar) on Dec 02, 2015 at 16:49 UTC
I agree with Corion's comments. I would lean more towards using a tokenisation system (especially if dealing with CC details). I also would not download, load and delete a pm file in the manner you suggest. What I would do is make a fast API interface available on that separate machine. This allows you to tightly restrict access and upgrade your secrets easily (or even implement a completely different system, maybe even to provide one-time secrets), along with giving you some additional logging abilities that loading a pm wouldn't necessarily allow. Imagine if you know that when someone does x on your website that it causes a, b and c to happen, which generates 2 requests to your secrets API. Now if your logging detects that someone doing x has actually generated 4 requests to your secrets API, you've just identified a possible intrusion and you can do something about it before too many customers are potentially compromised.	[reply]
Re^3: Effective database column level encryption? by dallen16 (Sexton) on Dec 03, 2015 at 16:46 UTC
I think what you're getting at is key exchange... secure methods to exchange secret keys. There are well defined solutions but they may fall into your "wary of being security theatre". In general, look at Internet Key Exchange Key exchange works using a key management server. To your need, an authorized consumer of the encrypted data would need to establish a security association with the key management server to gain access to the secret key needed to decrypt the data. You might want to look at Cyrpt::DH or Cyrpt::PK::DH. On CPAN, search for "diffie-hellman".	[reply]