27 comments

[ 7.2 ms ] story [ 77.7 ms ] thread
The problem is real, but all the presented solutions are useless. Every user name, description and profile picture check can be bypassed to create a close enough approximation that average users wont dig further into. And the kind of people who would enter passwords in Slack when prompted by "Slackbot" would just as easily fall for "IT Security Bot" or someone pretending to be their manager.

The real problem can be condensed into – how do you prevent your employees from getting phished? And well, if you had a solution to that you would be worth many billions of dollars.

You can't eliminate the problem but you can put up defenses. One way is a constant internal advertisement campaign that highlights these dangers and possible solutions. Another is essentially constantly pen-testing your workforce. Finally, make it fun to have an IT security mindset by hosting fun activities like a capture-the-flag game.

All of these solutions require process and manpower, and are not automated solutions.

> how do you prevent your employees from getting phished?

Security Awareness Training. Preferably with automated tools and continuous. KnowBe4 is the platform I've used but there are others.

Is there any evidence that security awareness training actually prevents employees from getting phished?
The prevention was obvious anecdotally, also apparently NIST felt the evidence was compelling enough to make it part of the CSF: https://csf.tools/reference/nist-cybersecurity-framework/v1-... As far as academic studies or something like that, I don't know
Anecdotally in that people recognized simulated phishing attacks from the vendor, or that they recognized real phishing attacks, including high-effort spear-phishing (like the one in TFA)?
i am also very skeptical of the phishing companies. It seems like a very scammy industry as a whole. I think yubikeys is a far better solution.
Such training is generally combined with auditing, so yes. The company you work for (assuming it actually does internal audits...) will have such evidence as well.
I'm not sure I follow what you mean by auditing. Do you mean tracking whether employees fall for fake phishing attacks organized by the training companies? Everywhere I've worked that runs these campaigns, they do track whether people "Fall" for them, but the fake phishing attacks are easy to spot a mile away because they were poorly done, and there's no reason to believe that real phishing attacks look anything like them. (They also measure the wrong thing, such as whether people click on the link - which is totally fine, the whole point of a web browser is to click links - and not whether they give up credentials or install software.)

If someone is auditing whether employees are falling for real phishing attacks, that's interesting and I'd be curious to know more about that product.

Clicking a suspected phishing link is a failure, given the absolutely ridiculous amount of potential malware vectors such a site can have. Of course, a good phishing audit also tracks whether or not credentials are leaked (and ideally whether or not these credentials could be real).

With "audits" I refer to checkups that policies are being followed. As for whether or not your phishing audits are good, I cannot say :) I have seen some very good ones, as the best audits are based on (different tiers of) successful phishing campaigns seen in real life.

If you feel that your company could do better, you could always try to speak to your security team about this. It helps the people working there as much as it helps the company, folks falling for phishing happens in all walks of life.

> Clicking a suspected phishing link is a failure, given the absolutely ridiculous amount of potential malware vectors such a site can have.

This is absolutely untrue and it is phishing-vendor propaganda.

If there are any "potential malware vectors" from visiting a website, there are so many other ways you are exposed to those "vectors". For instance, Hacker News is a website that features links to arbitrary user-submitted website. Any click on a website on Hacker News could expose you to all the same "vectors."

(Maybe that's why nobody here reads the article before commenting?)

If an attacker has a way to get malware to you based on your browser accessing some web page and rendering it, they have so many easier ways to do that. They can buy ads leading to the web page they control. They can make organic content that highly ranks a web page they control. They can even render custom iframes inside tweets (https://developer.twitter.com/en/docs/twitter-for-websites/c...) and promote the tweet.

If you're concerned about browser zero-days - and you should be! - phishing is the least of your worries. Automatic browser and OS updates with very short remediation times and aggressive policies on BYOD devices staying up to date will get you a lot farther.

And these policies are actually genuinely compatible with the jobs of a lot of people who, well, have to click on links to do their jobs. If you fall for the phishing-vendor propaganda, you'll end up with people trained not to click on links that look like phishing links but who will happily click on links that don't (because their job requires them to), which defeats the point entirely. Hence my question about whether you're measuring results from the phishing vendor, who is incentivized to tell you that paying them is doing something worthwhile, or from actual phishers.

Finally, TFA was about spear-phishing and about convincing people to do things, not about distributing malware. A "don't click on links" security culture does nothing to protect against "don't trust emails that tell you to do wire transfers."

I have in fact spoken to my security team and convinced them to stop running phishing tests that mark clicking the website as a failure, based on exactly the above reasoning.

> you'll end up with people trained not to click on links that look like phishing links but who will happily click on links that don't

This is fair. I'll think about it and do some more research. It'd be nice to be wrong, in this case :)

> A "don't click on links" security culture does nothing to protect against "don't trust emails that tell you to do wire transfers."

I thought this spoke for itself, but just in case: You can do both. A good policy takes all reasonable steps, of which these are good examples.

> The real problem can be condensed into – how do you prevent your employees from getting phished? And well, if you had a solution to that you would be worth many billions of dollars.

Security Keys.

e.g. https://krebsonsecurity.com/2018/07/google-security-keys-neu...

Notice that Google deployment was almost five years ago. Completely fixes the problem. Your employer presumably doesn't do this, mine doesn't either. That's not because the solution doesn't exist, it's because they don't care.

Stopped reading at the suggestion that "white, male" users are somehow more technically illiterate than other individuals.

With any luck, this style of insufferable faux self-deprecation will not be fashionable with the next generation.

> we’ll need to identify important people with both a high degree of importance but with a low degree of tech literacy, i.e. your average white, male C-level executive

From this, you think the author is suggesting that white male users are more technically illiterate than other individuals? Your detectors are tuned for too much recall.

Can you imagine the shitstorm if was "visible minority, female C-level executive"?
Some types of fraud do particularly target minority women, because they're less likely to be believed when they report the problem, which improves the odds of success, particularly if there's a "clawback" period and the crooks want the timer to expire before the complaint is believed.

Not so much executives though. Usually elderly widows.

It could be interpreted that the object was "C-Level Executives" and if you look at the stats, yeah in general, these are white males due to many. many years of racism and prejudice.
or maybe they’re just good at their jobs
This could also be done with Apps, such as Lattice. If you impersonate you could ask you to reset your password with a link to latticechangepassword.com or something like that.

The solution might be a verified name system, if you change your name of display name, it gets "moderated" by an admin first. In a corporate environment there is no need for people to change their name often, maybe once ever when you either actually change your name or decide to use an alias in real life.

This is similar to HN not allowing someone to use the displayname "dang", or if display names were a thing, it gets moderated somehow.

Probably good idea to do that on the profile pic too!

I'm not sure if there is a cool technical word for this in security jargon, but the "Full Name" "Display Name" and "Profile Photo" are what I'd call "trust-centric fields" and need to be treated differently to say "What I do" or "Phone Number".

In a corporation this is easy, someone's job is to vet changes to this. Whoever sets up systems for employees for example.

Outside of a corporation it may rely on flagging and moderators.

How is your phone number not a trust-centric field?
I don’t trust what you say because of your phone number, but I might trust what you say because you have assumed my bosses name.

Obviously it is definitely a field that needs to be secure, I.e. I can’t set your phone number.

Slightly off topic but I've run into the opposite extreme with in the corporate world. A few years ago the company I was working at was acquired and we were all eventually migrated over to new systems like Office 365, Teams and Workday. From that day onwards it was like profiles were frozen in time; we couldn't change anything on our own and anything we could get updated through the proper channels would eventually, and inexplicably, be reset to what it was when we migrated. Contact information, who was managing who, job titles, everything. Even our previous CTO, title intact, was stuck reporting to another CTO in the system.
Not sure if this is still a feature of the Slack API, but in an older version you could set your name and avatar when sending a message. I trolled our internal GitHub for exposed tokens then wrote a simple bot that used the token from some random app and sent messages as “Servicedesk Bot”. It proved reasonably effective.

I was on the security team and had permission, which is important if you are going to do stuff like this.

I was enjoying this article until it effectively abused the audience to push censorship.
It pointed out systemic issues with slack's platform and proposed solutions to every single one. Abuse definitely did not happen in any form and calling the prevention of neonazi sympathizing "censorship" while strictly true, is tone-deaf in the sense that many countries (probably including yours) spent years fighting a war so that these folks would not have a platform to do what they do best.