Social engineering attacks will probably be a thorn in security's side for a very long time, if not indefinitely... There's a sort of fundamental disconnect inherent in "Trust the system! It's secure! Except be careful because sometimes something that is not the system will pretend to be the system..."
We keep treating falling for phishing emails as a user error. But, perhaps, having our most "official" means of communicating online (email) be a protocol that has no identity verification, no authentication and no encryption, is actually a technical bug, not a human one.
I mean, you would expect that we should at least be able to tell that if you get a x@snapchat.com email in your y@snapchat.com inbox, it actually came from x who works at Snapchat. However, that is (in general), not how email works, for some reason (yes, I know, ancient protocol, tons of stakeholders, identity is hard, but come on...).
SPF Everywhere would be a start. But, as currently deployed, at least, SPF is nowhere near enough. I do research in security, and even I often have no clue, when faced with a new corporate email system, whether the email addresses I see can or can't be forged, depending on domain.
Hell, if I get bob@company.com on my Gmail inbox, I cannot really tell whether even the @company.com part has been authenticated or not. There isn't even an HTTPS like lock icon or anything, let alone a "Google has verified that this email comes from Amazon.com" assurance.
SPF doesn't really do anything to prevent this. It can only protect the return path address, the scammer is free to use whatever From and Reply-To headers they like in the email itself - they don't really care if a bounce goes to the wrong place.
DMARC protects the From header, but isn't widely deployed.
Of course, because, well, unless you know the whole story of email, down to knowing what SMTP is, there is zero reason to expect that the from address of your email client lies to you. Which is also why all web traffic should be over TLS, because the same can be said of domain names. This is one area of security where our systems really should be made to match the user's expectation, and not the other way around. This is not a "grampa doesn't understand the interwebs" sort of issue, this is clearly broken design.
Non-envelope headers on emails are arbitrary. "From" (as opposed to Envelope-From) is one of these. Some mail clients looking at you, Outlook) just display the minimum amount of data including From, and make it non-obvious that this is not really where the mail was from. You only see this difference in address when you hit reply.
We had a phishing attack on an employee in accounting that was stopped in progress and just in time before a bank transfer took place. The emails in question passed SPF as they weren't actually from another user in our domain.
Adopt PGP signatures as a requirement on emails that include sensitive data. It should be easy enough to have an internal key server and a company key that counter signs all valid company keys. Require the key only be used for signing and kept on a usb stick.
S/MIME and X.509 is a lot more common than PGP signatures -- support for it is built in to most MUAs. Also, typically the keys are on smartcards rather than USB devices where the private key could be accessed.
An unknown person told the manager on the phone that they were with the fire department and needed to conduct a diagnostic test on the fire system, police said. The manager followed instructions and turned on the restaurant’s fire suppression system. The caller then said what the manager had done had caused a gas leak, so everyone had to evacuate the restaurant and the employee was told to break all the windows to avoid an explosion.
Wendy’s employees complied and smashed every single window, while waiting for the fire department to show up. Once officials arrived, they confirmed the call was a hoax.
