| The huge problem with your analogy is that what you're describing is saying 'no' to a feature that can't exist or else it is inherently a security backdoor. The feature that Clinton wanted was not inherently a backdoor. The feature even existed and Obama was given the solution. Obama's blackberry proves that a legitimate need existed and there was a secure solution to it. But Clinton was told 'No' and this is the kind of situation where it leads users to simply bypassing the security. You can't justify the 'No' response to Clinton on the basis of your 'No' response to a diagnostic backdoor. The fact that you can't see the difference in the two circumstances is why the security industry has a credibility problem, and why you've probably got a credibility problem. Unlike your example, a secure solution existed to the problem. Obama used it every day. Clinton was told 'No' and she chose, like many users do, to view it as a broken policy rather than as a legitimate security concern--because it probably was. Some users are dumb and want stupid broken things and have to be told why they can't have it. Other users are pretty smart and know when the reason they're being told 'No' has more to do with petty government feuds and bureaucratic infighting. Your post sounds like a well-rehearsed speech, and I suspect that you've used this a lot to say 'No' to requests--are you certain that all of those cases have been as legitimate as the case in your speech? I tend to doubt it or you wouldn't have posted it here in a case that shares little of the same circumstances. |
People try to divide security vulnerabilities into "super-obviously-bad" and "no one will ever find / exploit / do much of anything with it."
The problem is that rather often little holes can be leveraged into bigger holes. The argument against the change I'd requested was that no one would ever write a program which would process the trace hook events. Because they just wouldn't. Except no one needed to - there was a program that took trace identifiers and dumped the events for all to see.
That's an argument to "difficulty to exploit". The same thing has happened with various race-related exploits -- a race that's fractions of a millisecond long is considered "unexploitable" until process scheduling, and how to control it via various means is discussed.
It doesn't matter the problem space - fixing bugs in code, configuring servers securely, proper OPSEC, choice of programming languages or development methodologies. It always comes down to security versus convenience. Sometimes "convenience" is replaced by "cost" or "resources". In this case, the NSA didn't have the "resources", which is a proxy for "convenience" because if giving Clinton a secure BlackBerry had been dead simple and free ("convenient") she'd have gotten one.
As for being "well-rehearsed", yeah, I've spoken publicly on security and try to make my little anecdotes fun to read or hear.