3 ms·
The problem is that quite often security professionals say "No", provide reasons, and the person doing the asking insists that convenience is more important tha
by julie78787 11y ago
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 11y agoThis 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.
- Swizec 11y ago> 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 11y agoWhen 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 11y agoIt 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 11y agoWithout 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 11y agoUntil 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.
- lamontcg 11y agoThe 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.
- jsprogrammer 11y ago>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 11y agoI'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.