[hnbear]

I’ve found it immensely frustrating in numerous roles when discussing security, audit and compliance requests that the requesters can seldom actually explain their reasoning.

I want a clear statement of risk and why their proposed compensating control actually mitigates it.

Far too often the answers are just “it’s securerer” or “it’s the way we do it”, and actually proposing something that genuinely mitigates the underlying issue is ignored.

All that said, I’ll end up referencing this in the future as somewhat useful steps in a number of situations.

Some have simpler approaches - eg for password security can just reference NIST guidelines which currently clearly state not to rotate and just require length above complexity. And they’re backup to with tested evidence and a clear rationale.

[onphonenow]

Agreed totally. I had a nightmare govt double vpn situation. Very hard to get an account, you had to run ancient OS and Java (it would annoy you with warnings about lack of security/age) and comical password complexity / rotation rules. The result was rampant password sharing but also because you had this double vpn setup, each layer rotating - folks just couldn’t remember passwords. So they outsourced password reset. To reset your passwords you provided your 100% predictable username - that was it. Even I had to get a reset due to an inactivity lockout and I had to laugh at how easy it was after all the silliness - I could have given any username

[Kalium]

I've found that quite often, the people suggesting that "they way we do it" mitigates a risk don't understand either aspect. Their goal is to achieve the feeling of having made it go away. They only want to do the thing and compliance is getting in the way, as they see it. Understanding the risk often works against that, as it might put them in a position of having to understand just how much effort they are wasting as they live with lots of residual risk that their superiors don't actually want.

To put it another way, using a risk-mitigation approach instead of compliance only works when you have honest, earnest, and full good faith investment in the process. In practice, this is incredibly rare. We all know, are, or have been engineers who cannot imagine a system they wrote running without them having the ability to SSH in and sudo at will without having to justify anything.

This is where compliance comes in. It sets standards and forces the issue. Even bad faith, low-effort implementations wind up having to meet a whole series of very clear - if occasionally box-tick-y - standards.

[sokoloff]

I aim to build systems that are both secure and compliant. It’s convenient when (but not a given that) those two adjectives overlap with each other.