[AtlasBarfed]

Already makes the crucial mistake:

Security people always want to "set policy" "educate on practices" and "enforce". You've already lost the battle.

PROVIDE SOLUTIONS. Why recommend all this "policy" when what you need to do is provide, at a minimum, a reference implementation. If you get called in as part of security architecture, PROVIDE A SOLUTION.

Because if you don't the devs will do the absolute minimum, and likely will have backdoors galore, especially as your policies impose real restrictions on their systems support quality of life, ability to respond to production issues, and iterate to produce features.

The other persistent issue with security is that it is anathema to automation, and therefore efficiency. So dovetailing with providing a solution, these practices for 2FA and SSO (which invariably involves horrible popup UIs and other hacky things) will block, say, automated backups, auditing, monitoring, etc that also require access. So be ready with those.

[fsflover]

> Security people always want to "set policy" "educate on practices" and "enforce". You've already lost the battle.

>PROVIDE SOLUTIONS.

Here you go: https://qubes-os.org

[raesene9]

I think this is correct but is tricky to put into action as companies rarely staff security departments to do this, typically you'll see ratios of 20 devs or even 50 devs to 1 security person. At that level it's very difficult for the security person to know enough/have enough time for detail work.

Ideally technical security implementation should be seen as a function of the development/DevOps teams. You can have security teams to provide specific advice but the work of designing and implementing controls is best done within the team managing the system.