Hacker News Reader

I’ll pile onto this- your security process also has to be user friendly. No security tooling in the world is going to protect you if it’s so hard to get a new product out the door that business users actively start subverting the system.

I’ve had US government customers take 3 months to review a CR to connect two systems. I’ve been tossed non-sensical documentation and told to fill it out without any help, a process that can take literally weeks of person time. And I’ve seen security teams cripple critical business functionality for, at best, marginal security gains.

In environments where things like the above are happening you start users and even business organizations rebel, they start operating outside of the it systems (txt message driven shadow business processes are common) and IT broadly and security specifically begin to be seen as the enemy.

How to fix this? Well one, i think security teams really need to focus on making themselves aids to everyone else rather than traffic cops. One model I like is to embed security team members in any development process or acquisition effort as team members, with the expectation these v-team members actually deliver work, including advocating for the team with in the security process and creating any security artifacts. That’s expensive, so they’ll have to be some cross billing set up or something, but it’s worth it IMO.

Regardless, security that reduces an organizations ability to do its mission runs the risk of getting avoided altogether.

> You must make security features extremely easy to use and ergonomic above all else (even above being secure!).

That's definitely not right.

The correct security design is that when things aren't secure you fail entirely. This will sometimes be very annoying but the temptation to prefer not failing leads to disaster. Instead an organisation that prioritises security must dedicate resources to resolving the actual security problem as a priority because it is very annoying.

For example 'thisisunsafe' and its predecessor 'badidea' are indeed, unsafe and a bad idea. The correct design is to simply fail instead. Which organisation do you think gets successfully phished with invalid HTTPS certificates - the Chrome embracing organisation that has taught people they can just type "thisisunsafe" or the one where everybody uses Firefox and it brick walls when HSTS denies access?

> Nobody is going to willingly agree to abandon their productivity or flexibility for your security tool or policy.

This is almost correct. Humans are very lazy. They will give up their productivity or flexibility for your security tool or policy if it's easier than the alternative.

For example when your users are trying to give their credentials to bad guys, you need to make this so difficult they give up.

You might think you can train your users not to want to give their credentials to bad guys, but this is unlikely to be successful enough to bother. Instead get to a place where your users, even though they really want to help the bad guys, just can't see an easy way to do it.

They may even file a helpdesk ticket because they genuinely don't realise what they're trying to do would be a very bad idea. Try not to be smug when responding to the ticket.

When things that people need to do fail entirely, people will develop hacky, under the radar alternatives.

> The correct security design is that when things aren't secure you fail entirely.

Yikes, this is extremely wrong. Security failures should be proportional to the actual cost and consequences.

On top of this, you can’t just fail systems in a business. You’ll lose all your customers and go bankrupt. On the other hand, you _can_ allow security vulnerabilities to continue existing. Sometimes you might lose customers or face legal consequences, so you might _have to_ address those security situations, but they are in the rare minority of all security issues overall, many of which you just need to apply expected value thinking towards and treat like any other trade-off.

Security is a resource to be traded off against other concerns, not an absolute necessity.

You are right in that security is a trade-off, but a security vulnerability should be considered almost as a failed system from a business perspective imho, because sooner or later it will turn into one. If you architect your systems to fail when not secure, you should detect the problem (and fix it) even before going live in production. It’s the fail fast, fail early strategy.

> Security failures should be proportional to the actual cost and consequences.

That's wonderful for Nostradamus, but everybody else is obliged to operate without knowledge of the future. What will the actual consequences be of bad guys being able to send email from the VP Asia Pacific's account to the CFO's office five minutes before close of business?

Maybe nothing right? Or maybe an "urgent cash payment" of $48M to secure a take over deal vanishes into a maze of international accounts never to be recovered...

Security is a special problem because you have unknown sentient adversaries. You completely lack intelligence about the adversary because you don't even know who they are. Don't think about security decisions the way you'd think about decisions like whether to hire a back-up venue in case the company picnic is rained off.

1000%. Modern software security is an exercise in optimizing developer UX.

I think this is an important point.

The first priority needs to be to make it easy and obvious to do the right thing.

Trying to make rules to forbid doing something insecure isn't helpful at all. If I need to do something and the only way I know how is the unsafe way, there's a big risk I'll pick that way. Unfortunately, it seems that security work is often just about trying to stop people from doing things, not helping them to do it the right way.

This reminds me of the way ssh became so popular so quickly in the mid-1990s: it was simultaneously more secure and more pleasant to use than unencrypted telnet or rlogin. I've tried to take the general lesson when writing my own systems: if security is making anything less convenient, I'm not doing it well enough.