Newer to White Oak Security, but several years into penetration testing – my prior leadership experience has made me particularly interested in supporting leaders in their security endeavors. After conducting many phishing and social engineering tests, as well as speaking with many senior executives in fields spanning the defense industry to the financial sector and beyond – today we are going to examine how to get the basics right when creating a phishing program for your company.
This is a thousand-foot glance at the overall structure of a phishing program. In our part 1 blog on phishing, we introduced you to some of the common pitfalls and raised awareness about the risks of conducting a phishing campaign.
In this part 2, we will continue the leadership focus by looking at the creation of solid and clear policies and procedures about why, when, where, by who, and how that testing will be conducted. I will not be handing over to you a complete set of policies and procedures but instead giving you the knowledge necessary to create them properly and the mindset necessary to create a successful iterative phishing program. The goal is for leaders to improve their security posture and mature their security program correctly.
How To Phish – The Right Way!
“Carpe Diem” does not mean ‘fish of the day.’” – Author Unknown
Creating a phishing program that actually adds value to the company requires post-testing acquired data to be actionable toward improving the security posture of your company. With practical remediation to help change the security posture of your company, it can be retested to ensure improvements have been made and are retained long-term. Creating an iterative phishing program requires one additional step, re-assessment of your entire program after each test. Any type of security program requires an iterative nature or it is useless. Unfortunately, I encounter more companies with repetitive security programs than iterative security programs. Iterative does not mean repetitive. The difference between a repetitive cybersecurity program and an iterative cybersecurity program is best understood by thinking about code. Repetitive code is code that will be executed multiple times, whereas iterative code is code that will be executed until the correct outcome is achieved. Below we can see a simple python program that I wrote to illustrate these differences.
In the repetitive code below a red box contains the code that determines how many times the code will repeat the algorithm that will compare the numbers on the list. In this case, it will compare list items 1-6. 0 indicates that it will begin with the first item on the list and the 6 indicates that it will stop after reaching the 6th item on the list. In this case, it repeats the algorithm but does not actually find the biggest number the user-supplied.
Now within the simple python program that I wrote, we see how in the iterative code below a red box contains the code that determines how many times the code will repeat the algorithm that will compare the numbers on the list. In this case, it examines itself to determine how many repetitions are necessary to iterate through the entire list and find the correct biggest number.
While this is a very simplistic example of iterative vs. repetitive code, I think it does a good job of indicating that iteration requires self-inspection/introspection of some sort!
Here is the plot twist that we all have to deal with: since the technology, people, and the world we deal with are constantly changing, our iterative cybersecurity programs will NEVER achieve a single correct outcome. The best we can do is create an iterative program that has the goal of staying ahead of the looming threats.
With that in mind, let us examine from a practical standpoint the why, when, where, by who, and how of phishing programs.
“Many men go fishing all of their lives without knowing that it is not fish they are after.” – Henry David Thoreau
As cybersecurity professionals, we strive to heighten and overall help mature the security posture of our clients. This analogy has been beaten to death, but let us revive it with a meme.
The simple truth that we have to admit to ourselves is that a bear is going to catch and eat whoever falls behind the pack. With this concept at hand, let’s answer the question:
“Why should we phish?”
Companies should phish to:
- Test IT Security’s incident response capabilities
- Test IT Security’s detection capabilities
- Test IT Security’s defense-in-depth and security tools
- Improve the security mindset of the entire company
- Help employees protect themselves at work (and in their personal lives – education is important!)
You might have noticed a trend here. The first 3 “whys” of phishing all have to do with the IT Security team and helping them evolve the security posture of the company so that when the next successful social engineering attack happens, they can prevent any damage. Humans by their very nature are vulnerable to social engineering. As P.T. Barnum once said, “There’s a sucker born every minute”. We are all suckers by nature, even the IT Security team. No one is immune to social engineering; they can only be well-prepared or ill-prepared. The importance of creating policies and processes that clearly lay out the purpose cannot be stressed enough. The only thing worse than not having them laid out clearly is laying them out poorly. If your policy indicates your focus is on employee knowledge and “fail” rates, then you may have a hard time selling this to your peers. To be frank, I hope it would be difficult to sell your peers on a phishing program that is not focused on improving security which you can control to a large degree but is instead focused on the human element of phishing which cannot ever be remediated completely.
When To Phish?
“Be patient and calm—for no one can catch fish in anger.” – Herbert Hoover
The ”when” of phishing tests and other social engineering tests is directly related to the why. If you are testing the first three bullets above you may want to conduct a full-scope Red Team operation with an emphasis on spear phishing combined with mass campaign phishing every year. If you are in a very strong/mature security posture you may be ready for Purple Team testing- which can take an Incident Response team and SOC team to the next level. Alternatively, testing basic security controls like Proofpoint, improving individual employee security mindsets, and overall company security posture to phishing attacks can usually be supported by regular phishing tests across the whole organization.
Later we will talk about how to respond to the results of that testing, but for now, I would recommend laying the groundwork for continuous improvement by setting metrics that should be met before ascending the ladder of security testing.
Ladder of Phishing Security Testing:
- regular phishing tests
- specific focused phishing tests
- third-party external phishing tests
- red team operations that include social engineering tests
- finally the pinnacle of preparedness – purple team testing
Do not try to swim in the ocean if you cannot doggie paddle in the puddle first, instead have a plan to get into the ocean and swim with the big fish when you are ready!
Where To Phish?
“Most of the world is covered by water. A fisherman’s job is simple: Pick out the best parts.” – Charles Waterman
Where comes into play when you begin testing specific high-value or sensitive teams. It also makes a difference when you begin covert entry testing. As your security posture matures, it can become very valuable to focus on departments with significant access such as treasury or IT Security itself. The focus on this testing, again, is less on the user awareness piece and more on your security team’s awareness of what is happening with those high value targets! Your tools should be much more tuned into these high-value targets. The difference between a business development employee and the SVP of Software Development clicking on a link and submitting credentials is the difference between getting bit by a mosquito and getting bit by a bear.
As your security team conducts more analysis of simulated attacks and breaches focused around these high value targets, their ability to zero in on real breaches when it matters most will grow exponentially. While I was working at a major international company on their Incident Response team, we identified an email account breach that made its way into a highly sensitive team by checking for rules created for accounts that redirected emails away from the “Inbox” and towards “RSS Feeds” (and other rarely opened folders). This technique was utilized by the threat actor to slowly sneak their way in even deeper. Thankfully we identified the threat and shut it down before serious damage was done.
Who Is Phishing?
This may seem like an obvious answer, IT Security, of course! FALSE.
This question might very well be asked by your peers or the c-suite. It is a valid question. Your mission is to ensure that you not only convince them that you have found a world-class team to conduct these highly sensitive tests but actually find/build that world class team.
How To Phish?
“The charm of fishing is that it is the pursuit of what is elusive but attainable, a perpetual series of occasions of hope.” – John Buchan
This is where policies and procedures become extremely important. There should be standard operating procedures laid out in the policy that dictate the limitations on testing. They should also lay out when the testing will be done and precisely what will be done with the results. Now we get to talk about the great controversy that has been raging across the industry: repercussions.
Let me begin this section with a story from a past engagement I conducted.
A long time ago in a galaxy far far away, I was instructed to conduct a phishing test on a large company with thousands of users. I prepared my phishing infrastructure and created a cunning email to trick the users.
The campaign was wildly successful with over 20% credential submission. When the test was over, I submitted the results and debriefed the leadership team. This was the turning point for me regarding phishing – I innocently assumed that the company knew how to handle such brutal results. I was informed that a high-level executive was pushing to create a “3 strikes & you’re fired” rule. The entire IT Security team pushed back against this vigorously. I took a look at the historical data on that executive’s phishing tests. He would have been fired before he ever became an executive if that rule had been implemented in the past. Thankfully, the cooler heads prevailed and the company made the next right choice and forsook punishment for phishing tests.
Phishing Email Example
Here is an example email that a user SHOULD receive upon clicking or submitting credentials via a phishing email:
From: Supercoolsecurityteam@bestcompanyever.com Subject: We’ve got your back! Hi EMPLOYEE, We have been conducting phishing tests to help elevate everyone’s security awareness. While you did click/submit credentials to the “malicious” link/page we understand that these things can be very tricky. That is why we are here. By participating in these tests not only do you elevate your security awareness, but the security team gets valuable practice in protecting users who are tricked by malicious actors. Behind the scenes, we work diligently to prevent them from attacking others/harming you/the systems you use here at the best company ever. We have created some security training that you can take if you have the time and would like to learn some more about how to spot these types of threats. Thank you for your patience and help in securing the best company ever! V/r, Super cool security team
I would guess that the majority of users who participated in the test would also opt to take the training. It is your responsibility to make the training engaging, useful, concise, and actionable. I would also guess that the users who did take the non-mandatory training would actually engage with it instead of just ticking it off the to-do list. This is just an example email intended to emphasize the simple fact that IT Security should have a reputation as the good guys. Additionally, yearly ongoing security awareness training is important as well. Yearly training should be mandatory, but mandatory training after a phishing test is perceived as punishment and often produces a loss of buy-in.
Leaders & Phishing
How do I get buy-in from my peers and leadership?
The TLDR answer is “Servant Leadership”.
If you are an IT Security executive or senior leader your entire job is to serve and protect your peers and their teams. They will not respond well if you just bring them problems. Your primary deliverable is elevated security for them, your internal customers. If your message is focused on protecting and helping other teams succeed, it will go a long way to gaining buy-in. Make sure they understand that when your team finds things like vulnerabilities or weaknesses (and most importantly, fixes them) that instead of losing face – they will have your support, assistance, and respect.
Phishing Leadership Conclusion
The most important idea I want to impart to you as you continue to elevate the security of your company is the difference between the iterative and repetitive program models:
Repetitive = insanity
Iterative = growth through introspection
Additionally, I want to leave you all with a clear understanding of what needs to be included in your processes and procedures to ensure you achieve buy-in and can affect positive change in your company’s security posture!
This concludes the leadership-focused blogs in this Phishing For Success series, let your technical teams know we have some fun stuff coming up for them soon!
MORE FROM WHITE OAK SECURITY
White Oak Security is a highly skilled and knowledgeable cyber security and penetration testing company that works hard to get into the minds of opponents to help protect those we serve from malicious threats through expertise, integrity, and passion.
*Images in this blog are not ours*