I belonged to an organization that had password complexity requirements. That's normal and understandable. However one requirement was that no part of my password could contain a three character subsstring that was included in my full name. I won't give my real name here, but sadly it includes some three letter subsequences that are somewhat common in many English words. I can understand a policy that prevents someone from using "matthew1234" as Matthew Smith's password, but this rule also prevents such a person from using "correcthorsebatterystaple" because it has 'att' in it.

Turns out, this rule was not from IT. It was a requirement from the cybersecurity insurance policy the organization had taken.

> Turns out, this rule was not from IT. It was a requirement from the cybersecurity insurance policy the organization had taken.

I wonder if some of these constraints are to try to find a way not to pay out on the policy.

It absolutely was/is.

To bastardize Douglas Adams: For-profit insurance is a scam; breach insurance, doubly-so.

Just an unbreakable law of the universe.

"Why did this stupid shit happen? Oh, it's money again."

It's not money but inertia of very large systems. All these password changes cost money as well. If anything it's a market failure that insurance companies seem to have too little incentive to update their security requirements. This would likely be solved by reducing friction with both evaluating insurers in detail and switching between them.

It's also a sort of moral hazard problem.

If you, the person in charge of these decisions, allow an incumbent policy - even a bad one - to stand, then if something goes wrong you can blame the policy. If you change the policy, though, then you're at risk of being held personally responsible if something goes wrong. Even if the change isn't related to the problem.

It's not just cybersecurity. I have a family member who was a medical director, and ran up against it whenever he wanted to update hospital policies and standards of care to reflect new findings. Legal would throw a shitfit about it every time. With the way tort law in the US works, the solution to the trolley problem is always "don't throw the switch" because as soon as you touch it you're involved and can be held responsible for what happens.

"No-one ever got fired for buying IBM" etc.

I mean that was true about Boeing, right up until it wasn't.

I love the analogy to the trolley problem. It sounds like this logic would literally hold up in a real-life trolley problem in regards to the law.

Not money; incentives

> Point being the people implementing it usually know it’s a bad idea and so do the people asking for it. But politics and incentives are aligned with it being safer for the individuals to go along with it.

we've gone through HITRUST several times and I just told them we weren't going to do forced password rotation since NIST had updated their guidance. it was fine!

and every time we get a vendor security questionnaire I just say "no, we don't do this because it's old guidance" and link to NIST... no one has ever complained.

Should you also question their competence? They should know, right?

this is less about competence and more about update schedules... we happen to feel like it's worth incorporating guidance that's newer than what HITRUST or our customers require us to (though the guidance in question was updated by NIST eight years ago... sometimes it takes a long time for this stuff to change)

is a judge going to think the same way if insurance doesn't pay and you take them to court though, in the event of a breach, etc.

After all it's perfectly possible to do interior work in your house that isn't up to code, but if it burns down in a fire, the insurance company will investigate and may not pay out if they find out.

in this case I'd be more worried about being in court trying to explain why we knowingly used an inferior approach (forced password changes) when we knew the newer approach resulted in higher security... that is a vastly different analogy than being "out of code". additionally, noting the deviation from the old, less secure standard up front (in our HITRUST submissions) and with our customers (in their vendor questionnaires) provides evidence that we are going above and beyond vs. shirking a duty.