First and foremost, if you must perform simulated phishing, don't be a jerk! I hate to think how simulated phishes such as GoDaddy's "$650 one-time bonus" (1, 2) and Tribune Publishing's "up to $10,000" (1, 2, 3) have affected trust and morale within those organizations. What benefits did those efforts really offer to their stakeholders?

Phishing is the fraudulent use of email to trick a target into giving up personal / sensitive information (via reply to email, or submission of a web form), or perhaps taking some other action with consequences (opening an attachment, making a phone call, executing a business process). It's real, it's constant, and the impact can be high.

Phishing simulation (aka. simulated phishing, phishing test, fake phishing) is the crafting of "fake" phishing emails by a trusted party (generally a security team) targetting members of their own organizations. They'll generally track and educate (shame?) those who fall for the fake phish. There are various vendors that have the ideal solution to help you execute simulated phishing. Phishing is a risk to be managed, yes... but simulated phishing also presents risk.

Before simulating a phish...

Even if you're not to going to the extent of the terrible examples above, here are several questions to consider as a security team before running your own phishing simulation:

• Is responsibility for fighting off phishing attacks primarily across all employees? Yes, they have some responsibility, but there's an argument to be made that primary responsbility for this must sit with the security team who has the experience and resources to affect change. If this is the case, then a focus on testing of the security team and associated controls/systems seems more appropriate. ("Security is everyone's responsibility" feels like a tired old trope that is given too much weight, but that's a discussion for another time.)

• Have you done the work to reduce exposure to and impact of phishing? As a security team, you should probably have implemented email security features (SPF/DKIM/DMARC/new-hotness, anti-spoofing rules, content filtering, etc), strong authentication mechanisms (multi-factor!), effective endpoint controls (both prevention and detection!), and resilient business processes - among other things.

• How is organizational perception of and interaction with your security team affected? There's a very significant likelihood that phishing simulation exercises may reduce trust or increase friction between the security team and others. There's somewhat a juxtaposition at the intersection of working to build a positive working relationship with folks who you're also trying to "trick" or "test".

• Is "phishing awareness" really what you want to focus on? Ideally, the security team should be setting your organization up for success with a broad and healthy awareness of a range of security threats, not just phishing.

• Are you clear on goals? What is the security team hoping to learn? You already know that people click links and open attachments, and more specifically that people fall for phishing emails.

• Is your simulation realistic? If you have existing anti-phishing controls within your email system, you probably shouldn't bypass them for the sake of a simulation. Also, just because a recipient "clicked a link", that doesn't mean an undesired security outcome would have eventuated and there are likely nuanced lessons to be learned from any simulation results.

• Do you have reasonable visibility into actual phishing activity, and is the security team able to respond appropriately? (See alternative #1 below.)

• Is there value to be gained by testing employees, vs testing security controls? (See alternative #2 below.)

Alternative 1: Don't focus on simulation, focus on reality

As an alternative to simulated phishing, can you track actual phishing activity? As phishing attempts are reported to or detected by your security team, investigate and check for message opens/reads, unique/harmful URL access, outbound replies to sending addresses, etc. Proactively block or yank known-bad messages. Use resulting data and metrics to tune anti-phishing, email platform, endpoint protection, and broader security controls and also to monitor employee response to known-bad emails.

There are going to be privacy trade-offs to consider here; in perception or reality, "big brother" is not always welcome!

Alternative 2: Don't test people, test security controls

As another alternative to simulated phishing, instead of testing the susceptibility of random employees to a pseudo-phish, how about testing the vulnerability of security controls across broader systems and processes to phishing-associated events and outcomes? Have members of your security team or other trusted partners execute various phishing-related actions in a controlled fashion and learn from the results.

For example:

• Craft various spoofed/faked phishing messages and send them from external/untrusted sources to briefed, read-in internal recipients - start with members of your own security team! Does your email system and its security mechanisms operate effectively, or does the phishing message make it through to the recipient's email client intact? Are there any indicators in the email client that they should be suspicious? How can you improve these mechanisms/indicators?

• Assume the disclosure of Active Directory (or O365, or Gsuite, or Okta, or [high-value target]) credentials for an employee account and attempt to use those credentials from an untrusted system/location. Do they result in unauthorized access to the system, or is there another control (strong multi-factor authentication!) that makes the credentials relatively worthless? If the former, does least-privilege mean the account credentials only get an attacker so far, or do they allow an unacceptable breadth/depth of access?

• "Click the link" or open a malicious attachment on a standard end-user system (with additional safeguards/sandboxing/monitoring, if deemed necessary), and observe. Is this going to results in exposure or breach of data and systems, or does an endpoint protection mechanism kick in and minimize the impact? Does your security monitoring detect the event and alert appropriately?

• Attempt to execute an unauthorized financial transaction (with appropriate selective awareness on finance/exec teams). Have the business processes, communications methods, and approval chains been designed and implemented such that a purported "urgent request from the CEO" will not result in financial loss?

One of the keys to these four examples is that it is members of the security team (or trusted partners) triggering the test scenarios. This removes the "trickery" element required when targetting random employees, and takes away the "shaming" element when somebody inevitably does fall for a simulated phish.

Performing testing of this type has potential to provide much deeper insight into the effectiveness of your security program, and keeps primary responsibility for security where it belongs - with your team! The usable signal you get from this testing, and opportunities for improvement identified, should significantly exceed the results of a simulated phishing exercise.

If you really must do simulated phishing...

Said it before, I'll say it again... don't be a jerk! Be conscious of how specific simulated phishes are crafted / structured and what pretexts you're attempting to utilize. Consider the environment, moment, and mindset that the targets are in. Don't just "do whatever it takes" to get that click.

"A criminal would do it, so we should too" is not justification for abuse or mistreatment (or making it look like someone is getting an unexpected bonus). Simulated phishing is not the only way to address all scenarios or pretexts, and you have other options to such as various flavors of training and awareness.

Go read @RachelTobac's recent thread, which starts by addressing some of this.

The takeaways

If you must do simulated phishing, do it thoughtfully and don't be a jerk. Before you do simulated phishing, consider the alternatives!

(If this didn't mean much to you, and you're only here because the many uses of the word "phishing" somehow landed you here ... don't get phished! Know how to recognize and avoid phishing scams.)