Cfxtrjtrk

I think there is an underlying problem that you will need to address. Why do the users care that they are failing?

Phishing simulations should, first and foremost, be an education tool not a testing tool.

If there are negative consequences to failing, then yes, your users are going to complain if the tests are more difficult than you have prepared them for. You would complain, too.

So, your response should be:

• educate them more (or differently) so that they can pass the tests (or rather, the comprehension tests, which is what they should be)


• remove negative consequences to failing

This might not require any content changes to your education material, but might only require a re-framing of the phishing simulations for users, management, and your security team.

Another tactic to try is to graduate the phishing simulations so that they get harder as the users are successful in responding to phishing. I have done this with my custom programmes. It's more complex on the back end, but the payoffs are huge if you can do it.

Your focus needs to be the evolving maturity of your organisation's ability to resist phishing attacks, not getting everyone to be perfect on tests. Once you take this perspective, the culture around these tests and the complaints will change.

Do it right, and your users will ask for the phishing simulations to be harder not easier. If you aim for that end result, you will have a much more resilient organisation.

We have been getting push back from end users that they have no way of distinguishing a legitimate email that they would receive day to day from truly malicious phishing emails.

This is an indication that tests that could be rooted out as fakes by trained security professionals are being used to evaluate people who aren't. You may have the skills to pick an email apart and interpret the headers, but Dan in Accounting probably doesn't and his management's not likely to agree that a master class in RFC 822 is a good use of his time.

Crafting targeted emails to increase the hit rate has to be done based on intelligence collected about your users and your purported sender. This is not information to which a phisher will be privy and, as Michael Hampton pointed out in his comment, rises to spearphishing. That's a different ball game played on a different field.

If there are adversaries (real or potential) capable of good-enough spearphishing to damage your business, all of the phishing countermeasures and training won't help. Your job is to deploy tools that will give Dan in Accounting a way to distinguish the real ones from the fakes. That might mean security on the sending end like a cryptographic signature that users' mail clients can check and post a prominent warning when something is unsigned or the signature doesn't match. You can't depend on humans to get this stuff right 100% of the time, especially as your organization gets larger and people don't know each other so well.

There's one possible point to make that I haven't seen in other answers, but have seen in the real world.

Users say they "have no way of distinguishing a legitimate email that they would receive day to day from truly malicious phishing emails". What this may tell you, is that legitimate emails about password renewals, service changes and such, do not obey the rules that users are expected to follow.

I have certainly seen organisations whose training materials tell users not to click links in emails, and definitely not to put their passwords into the sites those links point to, or to install software from them. And the service teams at those organisations then send out mass emails about service updates that require action (such as password updates, software installs, etc), with helpful links to click.

One thing that might help would be to clarify that users should report these legitimate emails. It might not help the users directly, but it may help to remind the service team that their emails have rules to follow, which should make things clearer for users in the long run.

1. When is phishing education going too far?

When the cost exceeds the benefit. Benefit is generally measured in lower click-through rates and increased rates of reporting of genuine phishing emails. Cost can be measured in:

• the effort to implement the test


• false positive reporting of (not) phishing emails


• lower engagement rates on legitimate emails


• ill will towards the Security group.

The last is the hardest to measure, and often ignored, but if your job is to trick your own people, you shouldn't be surprised if they start viewing you with suspicion.

2. Is pushback from the end users demonstrative that their awareness is still lacking and need further training,
   specifically the inability to recognize legitimate from
   malicious emails?

Um, maybe?

If their click-through rates remain high, then awareness is still lacking and they need further training.

If click-through rates in general have dropped, but the test emails consistently fool them, then their concerns about the testing may be legitimate.

It sounds like your content is pretty closely tailored to your users and even their job roles. This may be what is generating the negative reaction. Ideally, a phishing test should not rely upon knowledge or understanding of internal email practices, just as an attacker should not have access to those. (And note, your internal messaging should not look like your external messaging, for the same reason).

You may want to consider outsourcing your phishing tests. The organizations that are dedicated to offering this service have a better feel for what "in the wild" looks like, and their tools for measuring and reporting on engagement rates are usually better than you can do on your own.

Personally, I'm not fond of phish testing, because I believe it erodes trust between users and Security. But the fact of the matter is it's one of the best ways to improve your users' defences.

There's one way in which this may have gone too far:

We have adopted a highly targeted strategy based not only on the user's job role but also on the content such employees are likely to see.

You need to ask yourself whether employees at your company will actually be subject to this level of spearphishing. If the answer is no, then you've gone too far. Of course, this is all dependent on what the group does. If its the DNC, then the answer is yes.

The question of "going too far" requires context; what part is going too far?

The thing that phishing tests are trying to do is to make people suspicious of their email, because when they aren't then they are at risk of literally inviting unauthorized users onto the network.

So there shouldn't be an overwhelming amount of emails to the point that they are sifting through known bad emails to get to the ones they need to do their job, but there should be enough that it is commonly known that someone in the organization is portraying an attacker and trying to get them to click the wrong link because there are already people outside the organization trying to get them to do that.

The question then becomes when someone does go for the ploy, are you glad that you caught them instead of a malicious actor? As other people have mentioned here (and @BoredToolBox should not have been downvoted in my opinion) this is about education.

If you put that into the wording of the question then, I'm sure that it's not meant as "How much education is going too far?" right?

What is probably going too far in most organizations is the reaction to people who are clicking thorough, and especially if there is a punitive aspect to it. You should be glad when you are the one that caught the action, because it is a chance for you to help the user understand what could possibly have happened and why you are performing this exercise. People should not be punished or shamed.

Imagine that this was an exercise on how to prevent an illness from spreading worker to worker. A deadly virus that will lay dormant until it has found an appropriate host and will then possibly kill everyone, but they don't know that it is spread by people that are randomly coming in the front door handing them packages.

We have enough common sense to know not to just accept packages from people that walk into the building, but what people don't see is that this is exactly what is happening with their emails. So this is about a change in culture and perspective, and I don't really see what part of the knowledge of this is going too far when you are talking about education.

Faced something similar and currently part of a team that runs something similar. Here are my two cents:

Education is a very tricky concept as the way people learn are
different for different individuals. But what I have seen is that if
you try to concise the information you want to convey in 2-4 points,
in as few words as possible that always help. We do something like
this when it comes to educating people:

Whenever you get an email from someone outside the org ask these questions:

• Do you personally know this email id?


• Does the email id and the domain name look fishy to you?


• Do you really want to click that link or want to give this guy your personal info?

And lastly we always mention that:

• 
  

  if you are not sure please forward this email to {email id that verifies this}@{yourorg}.com

  
  
  
  
  
  2. Definitely. Since all they need to do (I guess) is to ignore that email or maybe forward it to your internal security team for review.
  
  
  
  

I guess what needs to be done here is more on education. Because the employees need to know how a successful phish can not only hurt the company but also the employee as well.

I don't know whether this applies to your case or not, but one potential problem may be if your expectations about user awareness are higher than the security norms put into use. For example:

• You may educate users to always check the https certificates, but at the same time some internal web sites may use self-signed or expired certificates, or even require submitting usernames and passwords through plain unencrypted http.


• Or you may educate users that all official internal tools reside on your company domain, but in reality you use popular third-party services like Gmail or Slack connected with OAuth.

While the first example is an actual issue with the infrastructure, the second one is a safe practice paired with out-of-date recommendations. I have seen both happening in the wild and in these cases the principles that you are trying to teach can not be applied in day-to-day practice and may ultimately lead to confusion and failure to comply.

I'm not sure the size of your organization, but the most practical advice I can offer is that you can go too far when you overthink it.
- Make some spoofy emails, send them to users, see what users do.

We use a tool (KnowBe4)- run a few trials against the users, and use that to educate them/get them aware. We capture who passed, who failed, and use the overall process to educate and demonstrate that we educate.

Don't overthink the audience with custom targeting; don't do complicated data analysis... If you are, you are probably wasting time you could spend on the next challenge.

If you see there's spear phishing at your execs or certain folks, engage them personally and often, and maybe do something operational to make sure that if they are fooled, you catch it. By operational change, for example, if someone's trying to get your CFO to release wire payments- then the CFO better have an additional maker/checker process, or get secondary non-email (Voice?) confirmation that a wire should go out.

I suspect that your simulation is using knowledge about your intended targets that no genuine phisher would ever know. That is why they complain about your fakes being too hard to distinguish from the real thing. In a word, you are cheating.