3 ms·

The security team at work implemented these policies. The first time we saw the alert it was exciting - they have fired enough that now everyone ignores them I

The security team at work implemented these policies. The first time we saw the alert it was exciting - they have fired enough that now everyone ignores them Is it normal for the security team to be hated at a company?

MattPalmer1086 3y ago
Completely normal for everyone to hate the security team. Also normal to blame security for all delays, and possibly the poor weather. If you don't get hacked, everything we asked you to do was a waste of time and resource. If you do get hacked, we were incompetent.
- 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 ago
    Yeah, 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 ago
    Y/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.
- ldx1024 3y ago
  Sounds familiar. If you are a developer and quietly forsee a future problem with the code base and fix it, are you rewarded for that? Nope, the code will quietly continue working, and that's what it's supposed to do. Rarely do people recognize the ability to avoid problems. In most cases you would benefit more personally by letting things get screwed up (but not too bad) and then be the hero fixing the mess. Sounds like better PR might be in order. If you're quietly averting disaster that's not enough, you have to make sure people are aware of that. Easier said than done, I know.

MattPalmer1086 3y ago

Completely normal for everyone to hate the security team. Also normal to blame security for all delays, and possibly the poor weather. If you don't get hacked, everything we asked you to do was a waste of time and resource. If you do get hacked, we were incompetent.

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 ago
  Yeah, 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 ago
  Y/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.
ldx1024 3y ago
Sounds familiar. If you are a developer and quietly forsee a future problem with the code base and fix it, are you rewarded for that? Nope, the code will quietly continue working, and that's what it's supposed to do. Rarely do people recognize the ability to avoid problems. In most cases you would benefit more personally by letting things get screwed up (but not too bad) and then be the hero fixing the mess. Sounds like better PR might be in order. If you're quietly averting disaster that's not enough, you have to make sure people are aware of that. Easier said than done, I know.