Too Much of a Good Thing
From the You-Gotta-Be-Kidding Dept.:
# # #
It's $YourBigApp...
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?
Fuckwit.
Say it with me: "Root. Cause. Seventeen."
x-posted from HuSi, sans cool poll.
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?
# # #
It's $YourBigApp...
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?
Fuckwit.
Say it with me: "Root. Cause. Seventeen."
x-posted from HuSi, sans cool poll.
posted by ReallyEvilCanine at 15:25 (direct link)
2 Comments:
Have you considered that your app _is_ the problem? The problem being that it is a magnet for freaks and fucknuts . :^)
In other sections I might agree but I'm dealing with system administrators. Someone in charge of a rack of AIX machines really ought to know that vi is an editor. Someone demanding encryption ought to know that it necesasrily affects perormance.
Over in the comments on this entry at HuSi, ucblockhead summed it up best:
You seem to have missed the part of the story where REC explained their error to them only to be told to it had to be done anyway.
The point you seem to miss about these stories is that in most of them, REC repeatedly explains things and is ignored.
Yes, everyone makes mistakes. But real idiots refuse to acknowledge mistakes. Like, for example, repeatedly insisting on impossibilities ("I want strong encryption on my entire database without a performance hit!") despite having their mistake pointed out to them.
As to $OurBigApp being a freak magnet, I don't think I can argue with you on that one.
Post a Comment
<< Home