[julie78787]

The problem is that quite often security professionals say "No", provide reasons, and the person doing the asking insists that convenience is more important than security.

My favorite story of all time, which I'll share because it's now over 20 years old, had to do with a security vulnerability in the diagnostic trace component of a serial device driver.

The developer in question insisted it had to be there. A meeting with the two of us, as well as our bosses, and a "neutral" odd-numbered party was had.

I started by explaining the exploit. The developer then explained the need to have support staff (who weren't "root" users") able to enable the diagnostic trace feature. I then explained how a non-support person could trace a specific TTY (see, it is an old story!) and capture an entire login dialog.

Things weren't going well for me, so I then explained that it presented a security vulnerability which I'd have to disclose.

At that point in time, the developer got up out of his chair, and came across the table at me. His boss grabbed him, sat him back down, then agreed with my explanation and the feature was changed to require privilege.

If you think being a security professional is fun, it's not all sunshine, roses and egotistical power-tripping. It's a constant struggle to say "No" when people want to make products more "useable" and we want to make sure they are "secure".

[Aloha]

This is a great tale - and clearly an obvious vulnerability. Most of the situations I've entered into are less clear cut however, its organizational policy choosing the easy way out (and being able to tick the 'best practices' box at the same time) over more practical solutions that actually work for a majority of the needed users.

[lamontcg]

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.

[julie78787]

No, it's pretty spot-on.

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.

[lamontcg]

No, you're still making category errors and still completely blind to them.

You slide from race conditions and attaching debuggers, to a policy decision by a bureaucrat not to come up with the resources.

You fundamentally cannot be held responsible for the existence of debuggers in the universe. That is just silly.

The bureaucrat who said 'no' to the request from the state department can be held responsible for justifying that decision. With a $4T budget I can't believe that the US government couldn't find a few bucks under a cushion someplace to dig up another blackberry for the Secretary of State. In fact, its pretty much negligence that they couldn't.

And when you make pure policy decision about security you cannot abdicate responsibility over users deciding to work around those policy decisions when you make bad decision.

[jsprogrammer]

>Unlike your example, a secure solution existed to the problem. Obama used it every day.

In the article the NSA is quoted as saying that additional BlackBerries could not be secured due to lack of resources.

You assume a lot (without apparent basis) about your OP.

[lamontcg]

I'm not assuming a whole lot.

The problem is not fundamentally unsolvable because Obama had one of those phones. The solution existed and at least one of them was produced.

The US Government spent $4 trillion in FY 2016. I can't imagine that a secure blackberry for the Secretary of State would have costed more than a negligible fraction of a fraction of a percentage of that.

The "lack of resources" was someone /deciding/ that they didn't want to spend the resources on securing the US Secretary of State's phone -- not some kind of law of nature or economics.

The person who made the judgement that there were "no resources" to accomplish the task ALSO needs to be held accountable for that decision.

[Swizec]

> The problem is that quite often security professionals say "No", provide reasons, and the person doing the asking insists that convenience is more important than security.

The real problem is that this is true. Just like the fastest and most error-free code is an empty file.

So you are left with tradeoffs.

[andrewflnr]

When security breaches can kill people, you'd better be able to prove that lack of convenience kills even more people, and that there are no other options.

[fabulist]

It seems to me like refusing to provide this convenience did lead to a dangerous breach of protocol.

Without endorsing Clinton's actions, lets learn from this.

[andrewflnr]

Without endorsing the NSA's actions, no. Clinton's reckless disregard for security led to a dangerous breach of protocol. The fact that anyone else might have done the same in that situation makes not the slightest difference to me. If no one will give you a parachute, do you say "screw it" and go skydiving anyway? No, that would be stupid. The reason for the refusal is immaterial.

[jack9]

Until that empty file has the inode edited so it replaced . in a folder, leaving a particularly difficult-to-notice/find backdoor in an SPARC system.