4 ms·
Hah, fair. I guess my main gripe is that there doesn't seem to be any avenue for backpressure - the security team makes an edict about how things have to be in
by zinodaur 3y ago
Hah, fair. I guess my main gripe is that there doesn't seem to be any avenue for backpressure - the security team makes an edict about how things have to be in order to be secure, and after that there's no reasoning with them. No explaining why their argument doesn't apply in this case, etc. etc. Perhaps because they are so used to everyone hating them that they can't listen, since people will always argue with them.
Our security team also engages in social engineering - making practices deemed insecure gradually more and more difficult through artificial roadblocks (e.g., adding y/n dialogues to commands that previously had none). Doesn't do a whole lot to build goodwill
- MattPalmer1086 3y agoYeah, that is actually a really common problem, and it genuinely is the fault of the security team. One good way to communicate and discuss security requirements is using threat models. A nice data flow diagram or architecture diagram showing the threat actor and attack vector helps a lot, along with any controls that exist. Unfortunately, security often doesn't seem to feel the need to explain themselves or discuss anything if they have a magic edict to wave about. I think that's a mistake, we should try to bring people along with us. And even find out we were wrong occasionally!
- MattPalmer1086 3y agoY/n dialogues don't generally do a lot to stop social engineering attacks. People get used to clicking through them. A better strategy for really sensitive things is to require a separate approver, but that does slow things down.