The pace at which new malware gets released into the wild is staggering. While rates have been decreasing over the last two years, we still see 12 or more new variants per hour detected in the wild. Ransomware, currently one of the most pervasive variants, is estimated to be infecting 4,000 systems per day. WannaCry, the latest ransomware variant, is reported to have disabled over 200,000 systems worldwide. While the technology used in the attack changes over time, the initial attack vector, “phishing”, has remained consistent. Phishing is when an attacker attempts to fool the recipient into clicking a link, running an application or handing out their authentication credentials. It can be extremely successful, which is why it is leveraged in three quarters of all attacks. While some malware variations include a worm component, this is only useful after the malware has breached your firewall by getting that first user to infect their own system.
In this article I want to address the social components of that initial phishing attack vector. I’ll talk about why phishing (and malware attacks in general) cannot be fixed simply with technology. I’ll also discuss why most security awareness programs fail at modifying user behaviour, and how you can hack your existing security processes to obtain measurable improvements in reducing your risk to phishing, as well as end user malware infections.
It is only natural that we would try and solve end user infections with technology. For example whenever a mass infection occurs we are told to patch our systems, fortify our perimeter and run malware detection software. While these are all great best practices, none of them address the root cause of the infection, which is a user behaviour issue. As an analogy, think about lane departure and collision avoidance systems that are now being added to modern automobiles. These are great technology improvements that are designed to increase driver safety. However put an operator behind the wheel that makes bad decisions, and eventually they are going to cause an accident. Technology can try and keep a driver from making bad choices, but if they are persistent, the worst is going to occur.
Another problem with the technology approach is that patching only works when the attack vector is known and has been resolved with a patch. In the past we have seen 0-day attacks where a patch was not available to resolve the attack vector. So while we should certainly apply security patches, we cannot rely on them to always keep our systems safe.
There is also a “ownership of responsibility” issue here. By solely relying on technology, we are divesting the end user of security responsibility for their own system. This puts security personnel between the proverbial “rock and a hard place”, with bad guys on one side trying to infect the systems, and the end users who utilize the systems participating in risky behaviour. So by shifting some of the responsibility back onto the user, we create a better defense in-depth posture.
If you have ever wondered why most people check their email constantly, it is because email has been shown to elicit a dopamine response in the brain. Dopamine has some positive attributes such as driving motivation, curiosity and ambition. However because it can trigger the pleasure centers of the brain it can also drive addictive behaviour. This is especially true when the behaviour results in unpredictable rewards. Email very much provides unpredictable rewards, as you never know when messages will arrive or what kind of content they will contain. So from a medical perspective, our brain chemistry interacts with email in a similar fashion to gambling.
Note that this creates a never ending cycle which is reinforced by brain chemistry. The anticipation of checking email triggers a shot of dopamine. When we view the emails that have been received, your opioid system triggers a pleasure response. Since we like to be happy, a self supporting system gets created where we constantly feel the need to check mail and reveal the rewards it provides. This is why it is so easy to fall into the habit of constantly checking email, but it is so hard to reverse that habit.
Given what is going on in the brain, it should be obvious as to why simply educating our users is not going to fix the problem. While they may know clicking that link is a bad idea, their brain chemistry is driving them to do so anyway. This means to fix root cause, we need to modify that chemical cycle into a more positive behaviour.
When I’ve made the above argument in the past, many security folks are quick to interject that they are already addressing the behavioural problem via security awareness training programs. The argument is the users have received training and therefore they should know better. However there are a couple of problems with this argument. To start, awareness training typically takes place annually. That leaves 364.25 days for the user to forget and ignore their education. It is well known that to be good at anything you need to train frequently. So we need to be testing users far more frequently than just once a year. Also, “education” is just a small portion of the behaviour problem. As discussed above, the larger hurdle is changing people’s chemically driven habits.
I’ve seen a lot of security awareness programs that tell users “don’t open suspicious emails,” but never qualify what actually makes an email “suspicious.” You should develop a training problem that is specific to the email system you are using. If your mail system presents internal and external “from” addresses differently, show examples of both and explain how the user can tell the difference. If your mail system uses DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) to validate email sources, show examples of verified and unverified senders.
Next, train your users on seeing the real URL they will be brought to if they click a link. Most email clients will display this URL when you hover your mouse over the link. For platforms that do not support mice, you can usually do a long press to see the URL. This is supported on both Android and Apple IOS. You should also train your users on how to read a fully qualified domain name. That way they are not fooled when the URL tries to send them to “www.google.com.evilbadguy.ru”.
While the above info should be in your awareness training material, it should also be readily accessible on your document sharing system. When new attacks are detected, leverage them as training opportunities. Refer back to the posted instructions and use them to identify why the email looks suspicious. This gets your users used to referencing the document and prompts you to modify it when needed to incorporate new attack or detection techniques.
Both a strength and weakness of email is that it accepts messages from outside of your organization. Make sure you convey to your users that they cannot blindly trust all of the messages they receive via email. A healthy dose of skepticism is extremely valuable. Consider implementing an internal messaging system only accessible to employees such as Slack or Mattermost. Identify that this system is more trustworthy than email. You can use this alternate system for critical messaging, or to warn users when an email is expected that may initially seem suspicious but is actually safe to open.
As I mentioned earlier, if you want your users to be effective at preventing malware outbreaks, you need to test them regularly. At a minimum, consider doing this on a quarterly basis. You can do the testing yourself or contract an outside third party. Sometimes it is helpful to do both. This ensures no single technique or messaging is used. You want your users responding to the simulated attack the same way they would to a real attack. You don’t want them treating it special because they spot it is only a test.
You also want to collect metrics on the testing. Were all of the emails received? How many were opened? How many people clicked a link? How many ran an untrusted application? This data will be extremely valuable in identifying if your user’s performance is improving. It will also help identify if you have any consistent problematic users.
Earlier I mentioned that the dopamine to opioid cycle created by email makes it difficult to change user habits. Now that we know that system is in place, we can take steps to modify it. I’ve had extremely good luck instituting reward programs for reporting malware or phishing attacks. If a user forwards an email to the Help Desk or Security team, and that email contains a malware or phishing attack that is attempting to target more than one person in the organization, the user gets a reward. While you can use a fixed reward system, I prefer one that varies with the severity of the attack. The reward can be swag, a gift card, public kudos, or some combination of these or other rewards. The catch is the reward only goes to the first user that reports the attack. So make sure you keep track of date/time stamps when users start reporting in.
Note what we have done here. Instead of trying to deny the dopamine to opioid cycle we have simply replaced the trigger. We’ve provided a greater challenge, which also results in a greater reward, for being the first to identify a message as malicious. I’ve seen huge success in implementing this program. It is not uncommon to see the number of people who get fooled by phishing attacks dropping from 40% to less than 10%.
Once you have implemented new training, begun testing your users and taken steps to modify their behaviour, it is time to focus on your incident response plan. Have a defined procedure for handling these events. Whenever possible, try to leverage the early heads up to protect other users. For example I’ve seen sites that use G Suite for business write up a quick API script to address malware and phishing attacks. The script takes as input some unique characteristic of the malicious email (subject line, sender, attachment name, etc.). The script then searches all user inboxes for the message. When a copy of the message is found, the message is move to the user’s spam folder or trash. This prevents user who may be fooled by the message from even seeing it.
Finally, once you implement a reward program and start testing users, it is not uncommon to see the false positive reporting rate go up. As users start to perceive all messages with a more suspicious eye, they are going to report messages that turn out to be legitimate. First and foremost, do not dissuade this behaviour! Consider how long it will take your team to clean up after just one nasty outbreak. Compare this to the amount of time it will take to respond to a few dozen, or even a few hundred, false positives. Clearly you come out ahead dealing with the false positives. Simply thank the user for the report, indicate how you can tell the message is legitimate if it is obvious, and offer that they should continue to reach out in the future if they receive any messages they are unsure of.
Finally, let’s say you follow all of the above advice but malware still gets through and impacts one or more internal systems. How to respond will depend on the type of damage done by the malware attack. For example if it is a ransomware attack, there may be documented processes to help you recover. For most other malware variants, usually the operating system vendor or third parties will make clean up tools available. What steps to take should be clearly identified in your incident response plan.
Another option is to reduce your reliance on needing to remove the malware. Backups are a conventional method of restoring a system to its last functional state. You can also implement a strategy that reduces your reliance on locally maintained software. For example by leveraging G Suites or Microsoft Online Office, your local system only needs a Web browser. All documents and applications are stored and executed online. This means a quick system swap can have an infected user back to fully functional in a matter of minutes.