Ask HN: How to protect users from social engineering attacks?
Apart from using strong passwords and enabling MFA, are there any other better methods to enhance network security for developers and business owners?
Without embarrassing or punishing them ensure the ones that put in credentials get trained. The credentials should automatically sign them up for interactive mandatory online courses so they are not being embarrassed in a classroom. Reward the teams that don't get phished. Reward the managers, sr. managers, directors and sr. directors who's teams and orgs do not get phished. The higher level of management organization that is free of phishing victims, the higher the rewards. Incentivize the leadership to discourage warning others in company chat that a phishing test campaign is in progress. I'm sure the director of incident management at my last place is reading this. It's up to them if they want to share high level stats. I would not be allowed to disclose details but I do know this methodology absolutely works, at least in a place that has integrity and employee trust.
This of course only works for employees of a company because they have signed legal agreements that would permit the company to phish their own employees and have their own corporate attorneys that reviewed this process. Any other scenario should have a small army of lawyers review the plan.
I'm not sure if it's configuration-dependent, but the emails should be realistic and reflect the tools/services your org uses. Sending them Zoom-branded emails foe example while the org has never used Zoom is pretty pointless. The ones I've experienced unfortunately can be spotted from a mile away due to how low-effort they were (something an actual targeted attack will never do - a targeted attack email would look perfect with the exception of the factors they can't fake such as the "From" address).
> Without embarrassing or punishing them
At the end of the day, the objective is that they don't engage with suspicious e-mails - whether they do that out of concern for security or out of fear of embarrassment/losing their paycheck is irrelevant.
You want people to be afraid to fall for an attack. The fear should be about negative consequences to the organization and the general unpleasantness that comes out of it, but fear of embarrassment works too.
For customer IAM, passkeys. Both hosted and open source idps support them.
The best way IMHO is to make a damn fun security awareness training. The best training I've done was basically doing running an "attack" against somebody and going through the whole process like an attacker would, but with the group as passengers and with explanations as I go. Seeing under the hood can be a lot of fun, and can be very enlightening.
I'd recommend Yubikeys (or actual smartcards even, if hardware constraints allow) used in PIV mode with a client certificate authing to an internal SAML/OIDC provider which seamlessly bridges to third-party apps.
This is immune to phishing because there's literally nothing to phish, beyond maybe the PIN but it's pretty pointless as it would still require the Yubikey/smartcard to be of any use. When done well, it's also a great UX because nobody ever sees an actual login screen. Unlocked smartcard present = you are logged in everywhere.
We'd have to extend this with the concept of a multi-sig wallet to unlock processes or transactions