Pistachio is a system that automatically sends out phishing simulations to everyone in your organization. The simulations are sent at varying intervals, and each user is unique, but in total each user will receive between 10 and 20 attacks per year. But how does Pistachio choose which attack to send?[1]
To dig into that question, we need to start by understanding the problem we are trying to solve. And we can only do that by putting ourselves into the mind of a cyber criminal.
Thinking Like a Hacker
Imagine I am a hacker. My hacker boss sends me the name of a company and says I have one week to get a username and password from an employee, otherwise I’m fired. Most people in cybersecurity would assume I’d start researching each employee and create targeted spear phishing attacks for each person.
But that isn’t what I’d do. What I’d do is send a nice looking Microsoft password reset email to every single employee, and be done with it.
Why? Because a Microsoft password reset email is going to seem at least vaguely plausible to almost every recipient, and as a result maximizes my chances of success. It clears the first hurdle of being believable with ease.
But what about the employees that don’t fall for it? Are they phish-proof, given that they passed one of the most successful attacks? No.
The reality is that a well-placed highly targeted attack still might work, it’s just much harder to make those attacks land perfectly. Imagine sending a fake British Airways check-in email. For people who don’t have an upcoming British Airways flight, this attack probably won’t work. But when it lands in front of someone who is flying with British Airways soon, this is weapons grade material.
A good phishing simulation platform has to take all of this into account to utilize similar tactics. Sometimes the attacks need to be generic to cast a wide net, and other times they need to be specific even if they might miss the mark. That’s what Pistachio aims to do.
How Pistachio Selects Attacks
In order to decide which attack a given user will receive, our system runs each piece of content through a series of “scorers”. Each scorer in our system gives a score between 1 and 0 to each piece of content, along with a given weight. The scores are added up (multiplied by their weight), and the content with the highest total score in the end is the attack that we send.
So what are these scorers? The list is too long to go through all of them, but here are some:
- Relevance. If you are a marketing manager at a financial services company that uses Slack, attacks that might make sense include a Google Analytics notification, a Slack MFA alert, or a marketing department survey sent from the CCO. A security alert for Microsoft Teams or an invite to join the tech planning channel makes a lot less sense. This scorer handles this by giving higher scores to content that matches the user’s job, industry, and software used.
- User Variety. Say a user receives a Microsoft OneDrive password reset email. We don’t want to follow up with another Microsoft OneDrive attack, even if we know for a fact that the person uses OneDrive. This scorer therefore gives higher scores to contents that relate to software or scenarios the user has not seen recently.
- Organization Variety. If everyone in an organization gets the same email, word gets around. People get warned not to click. While our system already ensures decent variety, we want to make sure we avoid freak accidents like three users getting the same email in quick succession by pure coincidence. This scorer ensures that attacks that we recently sent are less likely to get sent again for a short period of time, even if the attack is otherwise a great fit.
- Difficulty. The best way to learn is to fail, so the more attacks a user ignores, the harder our attacks get. In contrast, if a user fails an attack, we try to send slightly easier attacks for a little while. All of this is handled by our difficulty scorer.
- Location. Sometimes we have attacks that are a great fit for someone in Norway, not so much for someone in France. For example, a parking ticket in Oslo makes sense only to people located in Oslo. We use our location scorer to ensure we accurately target people based on where they work.
- Language. Our attacks currently come in eight different languages, but not every attack makes sense in every language. The Norwegian government, for example, doesn’t usually send emails in French. Our language scorer attempts to select attacks that make sense in the user’s preferred language.
Choosing Attacks Is a Balancing Act
As you can see, Pistachio’s system isn’t a set of hard rules that say “never send an attack in a foreign language” or “only select attacks that match the user’s software”. Instead, we assign higher scores to content that satisfies certain criteria we care about, and allow the interplay between those scores to make a decision.
That is important, because if we just applied a set of rules we’d be overfitting the data. Every user would only get hyper targeted attacks that fit their specifics 100% of the time, and they’d be totally untrained on some of the other types of attacks that hackers utilize. What makes a good attack is complex and varied, so our simulation platform is as well.
