Too Much of a Good Thing
We are being asked to provide options to encrypt the entire database for our investor relations application.I'm with you so far, and there are a few options. But encrypting the entire database? I don't think it's necessary. Just what is it you're trying to protect?
# # #
Right, with you so far: $OurOLDBigApp.
running on MS SQL Server 7...
I see it coming.
running on NT app servers.
Oh jeebus! So that's why they want to encrypt even the damned ZIP codes: you're running on a deprecated OS which the maker admitted couldn't be made secure and couldn't even be further patched. They know they're going to be broken into (again and again and again).
But wait! There's more!
We would like to encrypt the entire database with strong encryption but not degrade the applications performance.
And just how the fuck are you going to do that, Sparky? A Porsche slows down if you turn on the air conditioner; imagine hooking a 40-foot trailer to its bumper.
Strong encryption necessarily requires more processor time. That's the whole point of it. Of course it should require a lot less power to decrypt data than what's needed to crack it, but the stronger you go, the more cycles you have to sacrifice. The heavy cost of processor cycles is the reason that we encrypt at the column level. Encrypting every field of a relational database -- the contents of which are then transmitted in proprietary protocol which itself can be encrypted at a trivial processing cost -- would require at least four times as much processor capacity as the application itself uses.
I don't think $ParentCompany is really going to consider racks of additional blade servers running NT4 just so they can encrypt $FunClub member Timmy's film character preferences when a couple new 4U servers and updating the OS and DB would suffice.
I explain the high cost of strong security. I provide references in our documentation and that of third-party encryption technology vendors. It's possible, I explain to him, but at a severe performance cost.
Your answer is unacceptable. We must have complete database encryption with $SuperStrongEncryption and we want [a very old version of] $YourBigApp to retain its performance level. I held a meeting to discuss this internally and this is what we decided.
Oh, a meeting? Why didn't you say so? Well then, how can I even consider declining your request to put our engineering staff back to work on code they haven't looked at for five years in order to figure out how to do the impossible which your meeting decided was the only viable solution?
Say it with me: "Root. Cause. Seventeen."
x-posted from HuSi, sans cool poll.