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".

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.

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.

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.

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.

>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.

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.

> 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.

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.

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.

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.

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.

I have a class with the guy who was in charge of infosec (or the closest thing they had to 'in charge') for US military in the Middle East from about 2004-2006. When he got there he implemented a policy forbidding use of flash drives, and in doing so made everyone furious. For his entire time there he was pissing off users, but maybe the capacity for accepting unexplained 'No's is greater in the military, so the policy held. Then as soon as he left, they got rid of his rule, and a year later Russia landed their worm on tons of DoD boxes, classified and otherwise, with some flash drives in a parking lot; as the largest ever of DoD networks, it led to the start of CyberCom. Talk about failing to get any buy-in...

The problem with this story isn't that USB drives were used and caused a vulnerability, it's that USB drives could be used to cause a vulnerability.

Let's say the Russians did the same thing dumping a bunch of USB devices whilst the USB drive ban was in place. Almost certainly someone is going to sneak in a USB drive at the risk of getting caught, just so they can do their job more effectively. There is still a good chance that this USB drive hack might have worked, just not as likely.

I really feel that your friend wasn't looking at things from the right perspective. The reason that USB drives were the vector that allowed the Russian hack to work was because they allow the execution of arbitrary code once the drive is mounted. If you prevent the execution of that code, then the issue would largely have gone away.

Instead of only banning USB drives, why not investigate ways of preventing code execution on drive insertion from occurring in the first place? Then you could have the policy of no USB drives, but if someone did sneak one in then it would have removed the vulnerability completely.

A small point of information, it is also problematic (in a highly sensitive enviornment) to let people arbitrarily decide to take gigabytes of information out the door with them.

Indeed. Allowing workstations to connect USB storage should be prevented, even if they actually connect the drive into the USB slot.

Actually, I'm not even sure if Windows allows a way of preventing this.

I've definitely spoken to people who've told me that, when they plug a USB drive in at their place of work, Windows pops up a dialog for an administrator's password in order to mount it. I believe this is some sort of group policy, but I'm afraid I only use GNU/Linux.

I've also seen ones that don't offer even that; they just block it outright.

Funny story: a particular Australian Federal government department I did consulting work for just couldn't figure out how to prevent auto mounting of USB storage and - I kid you not - they superglued all the USB ports on all workstations that had access to their secure servers!

Based on the fact that the policy held for the duration of my classmate's stay, I'm guessing that he did implement a policy forcibly preventing flash drive use. But the whole time he was a thorn in everyone's side, maybe because he didn't try to explain himself adequately (or maybe because the military is too burnt out on mandatory training to pay attention). So after he left they probably "fixed" the systems to allow flash drives again.

Sometimes the "no" exists for a reason. Users don't understand this, and want the path of least resistance. Which is why policies exist for terminating such users from organizations.

But heh, infosec shouldn't exist and everyone should be able to BYOD, amirite? "Frictionless" or something like that?

> Sometimes the "no" exists for a reason. Users don't understand this, and want the path of least resistance. Which is why policies exist for terminating such users from organizations.

I will say that, in my experience dealing with government and DOD contractor security, is that they often fail to articulate the reasons. Users should understand, at some level, the threats you are trying to face. If someone comes to you for permission to do something and your "No" is backed up with nothing more than "That's the policy" or "Because I said so" you can expect them to be much more hostile to it and more likely to go around it.

I agree that user education is required.

I'm not sure I understand. Are you saying that security professionals should lower their standards because too many people don't want to follow the protocols that security professionals have determined to be the best course of action?

Must be nice to have a high enough position in life to ignore security protocols at whim. If I did that I would be fired.

No, security professionals should find adequate solutions to a changing technological (and the corresponding sociological) landscape.

Just saying "No" without investigating alternative solutions to satisfy the spirit of the request is likely the problem.

It's also apparent that there was no routine security auditing which may have caught Clinton's behavior. I'm not sure you can claim the NSA was acting with security in mind when it's quite evident she was walking around with a blackberry every day in "Mahogany Row'.

How do we know that "no" was the only answer with no investigation of alternative solutions?

How do we know there wasn't an audit done?

How is it the lacking of the NSA in considering security when a person who was told don't do that decided to ignore it?

Because when "we" can't do something it's for reasons that are varied, nuanced and entirely justifiable.

When "they" can't do something it's because they are malicious lazy idiots. Obviously.

It's illuminating how someone treats other professions that intersect with their own. If one security team acts in a way you disagree with fine. But if you view all security teams as inherently obstructionist, then that tells me you are self-centered or cut corners. Similar if you always have problems with HR, Accounting, etc...

Probably a combination of:

A) People seeing this play out in their own lives enough to relate it to this experience B) That the quote wasn't "No", it was "shut up and go color", lmao

If you re-read that portion of the article, the State Department rep used that phrase to paraphrase the NSA's response. That was not the actual response; nobody who wants to keep their job communicates inter-agency like that.

I think he means, if you tell somebody that you can't do something that's technically possible, they will find someone who can and will do it.

They did it for the previous administration but refused to do it for her and offered no good alternative. She couldn't fire them and replace them and with someone more capable, so her team found an alternative.

This is exactly how a person who is used to getting shit done would operation. You either break down obstacles or you go around.

Just to be clear, in this case "getting shit done" meant recklessly creating a massive security breach at the highest levels of the government.

During a period of time when government insiders were leaking damaging classified information on the internet.

I can see how she would consider her actions to be the lesser to two evils, at least she could trust her people.

That's the equivalent of someone who sees a bunch of broken windows in the neighborhood and therefore figures it's okay to toss a beer bottle out the window of their car.

Mind you, I could see that being her thought process, it's very human. But it is hardly a ringing endorsement of her behavior and principles, to say the least.

And that's how you open up security holes that people can breach. People who do such things should not be commended.

Welcome to the downside of disruption.

No, he's saying if you work in a department that has been given the power to oversee security at your organization, then your job is as much to service your customers (the other departments) as much as it is to ensure their safety. Trying to use that position as a means to be change-averse or to power-play is just going to ultimately lead to people finding another way.

There's also a real line between ultimately flaunting the rules and "just trying to get your job done" in these kinds situations. Obviously if you're imperiling classified secrets that distinction will not apply to you. But for most other people this is just an item in the toolbox for effecting the change you want to see, lol.

I would hope security's main concern is security, not making people feel happy about their preferences. If a person can show that it is a power-play then those security people are failing at their jobs, which is a different matter. So far I've only seen speculation that this situation was politics.

There are a lot of situations in life that end up having come down to "do you want to be right or do you want solve the problem?"

If you're a security professional who doesn't spend a fair amount of your energy making your users happy, you're failing at your main job of ensuring security, for exactly the reasons on display here. Security doesn't end when you've sent out the memo outlining your policy.

So back in the real world, no one's job is ever to go "do the best for the best's sake", outside of maybe academia. That's not how people work together, and as you get into more heavily politicized environments, the more true that is.

And we wonder why we see so many companies and government agencies failing at security.

It's a very high standard to force a user to change his password every 24 hours. It also guarantees this user will write it down on a post it next to the screen. Security professional should think also in term of practicality.

I was trying to enter a 26 characters wifi passcode when setting up a new MacBook recently (so without access to clipboard). All characters hidden, not even certain the keyboard was set up with the right region. It might be secure but the guy who designed this step of MacOS should still be fired.

I've worked in an environment where it'd be impossible to do your job if you didn't ignore IT.

I've posted about this before on here - "It was worse at $last_company where at my best count, I had 20+ different passwords, all with differing rules, and expiration policies, the solution in the end was a spreadsheet (contrary to IT policy) - which was stored on my workstation with full disk encryption."

If you have a choice between loosing 8 hours a week just to information access management or just ignoring the rules, which one would you pick?

Document and lose the 8 hours/week. Its not your 8 hours.

When you're a contractor, you often dont have that advantage - if for example all of your co-workers (and managers) violate policy in the same way, you're left being the odd man out, which does not bode well for your employment future. That said a large amount of "I cant because I'm locked out" was tolerated - if for no other reason that managing the account circus was too much for any one person.

I'll go against the grain and say yes.

The difficulty with the best protocols as designed by security professionals is that they are not necessarily designed based on how users actually work. And if they are not, it is likely that users will subvert them. This paper from 2010 is along those lines, "The True Cost of Unusable Password Policies: Password Use in the Wild" (http://www.cl.cam.ac.uk/~rja14/shb10/angela2.pdf).

I particularly like two of their observations from the introduction:

"Based on our results, we make three key observations:

1. When users cannot cope with the demands of strict password policies, it a) reduces their productivity, and b) leads them to adopt coping strategies - which usually reduce security.

2. Although passwords are usually considered in terms of authentication for a service or a device, today they are encountered in many other ways in the workplace – and existing password policies do not cover these. As a result, users adopt ad-hoc solutions, which are usually insecure."

The security we actually get is the result of the technology we use, and the human behavior that interacts with that technology. Sometimes, in order to get higher actual security, we may need to relax the technological security so that we get the human behavior we want.

I think he is saying that often people have a legitimate need and security professionals should try understand these needs and not just say "No".

In my company IT puts all kinds of restrictions on the network but for automated testing we need these restrictions removed or we can't do our job. Since IT didn't accommodate us or provide an approved workaround we had to hack around them and make the system less secure as a consequence.

The point is the security professionals exist in order to facilitate the needs of the users they serve, not the other way around. It's always easier to just say no, but a good security professional knows how to assess risks, find creative ways to mitigate them, and serve the needs of the user to as great an extent possible without compromising security.

If you say "yes" rather than "no", you become involved in the process of implementing the system and can provide security fixes and mitigations. If you say "no" they they probably do it anyway, stick it in Digital Ocean, and never tell you about it. It stops getting patched when they leave the company. Years later, someone kicks the door down and finds it littered with your IP.

Of course they were wrong to go through unofficial channels, but as a security professional, you don't plan for things to happen as you expect. You plan for things to go wrong, and you plan so they go wrong less.

> Must be nice to have a high enough position in life to ignore security protocols at whim. If I did that I would be fired.

Ivory towers take a stain too easily, so I only summer there. The rest of the year I stay on the ground with you commoners.

"Must be nice to have a high enough position in life to ignore security protocols at whim. If I did that I would be fired."

Only if you get caught, usually by (losing the device and having to tell everyone|getting a virus or what-not that noticeably impacts some other system). Which is sufficiently rare that you can get away with "it won't happen to me" for an arbitrary period of time.

I think most companies (large and small) are unwilling to dismiss c-suite executives on the word of a security professional in their IT department.

And we wonder why we see so many companies and government agencies failing at security.

Another way of thinking about it is that the security team is supposed to help other people do what they want to do securely. If X is insecure, make it secure. Now, if you're an IT department at some corp, you probably don't have the budget or the manpower to do that, so you have to say no as much as you can get away with it.

But when the Secretary of State wants to Do A Thing, and you're the NSA...

How is this a classic story? It's a story on Clinton just casually dismissing the security requirements, not some security technology meme where people game the password length and character requirements and monthly expiration and the arstechnica editor is going "we feel you!".

It's the state department. The same people that invoke "but secretz!" on every lawsuit.