magann - Fotolia
With phishing incidents on the rise, there's no better time to get started on a phishing test plan for your Exchange deployment.
Many IT organizations are not yet performing this type of security testing. Recent security reports have shown a high number of end users who open phishing emails, as well as a high number of cyber-espionage incidents involving phishing.
This simple and predictable exploit is likely behind even more breaches that have yet to be discovered in organizations around the globe. In my own experience performing phishing tests, I've seen response rates as low as 5% but as high as 67%. That's a lot of people who open, click and provide sensitive information to an unverified recipient.
As straightforward as a phishing test sounds for Microsoft Exchange, it pays to plan things out in advance. Planning ahead is a solid security procedure and a solid political move -- phishing can embarrass those who take the bait, including end users in managerial positions. While every organization has different specific needs, here are some general pointers on the important parts to include in a phishing test.
- Do you have buy-in from management to do this testing? If not, it's probably not worth doing as you won't be able to use the testing or results to effect change. You may also create more problems than you solve without having the proper clearance.
- Who are you going to test? I support testing all end users and all email accounts. Anything less -- including exemptions for executives or IT staff -- isn't a thorough test. Exemptions will merely serve to create a false sense of security and leave unnecessary gaps that put your business at risk.
- Hit on an attention-grabbing subject, such as HR benefit changes or a security policy acceptance, in your phishing test. Ask for sensitive business information, such as an end user's network login credentials (staying away from personal info), and create a sense of urgency for recipients to quickly respond. This is not entrapment -- this is the real world. If criminals are doing it, why shouldn't you model their behavior for your test? By asking for login credentials, your phishing test can show how your domain password policy is working and who still uses weak passwords. It can also be a good time to force a password change for everyone.
- Run tests that should, in theory, trigger internal security controls such as Web and email content filtering, antivirus software and data loss prevention. Once you send out a test phishing email, you might find that existing security controls get in the way, blocking or flagging the messages as spam. It's OK to disable such controls or work around this blocking -- as long as the changes are documented and considered in your overall phishing risk, you should be OK.
- Ensure that you test all applicable security policies, including sharing passwords and opening email attachments. You should also test security training program lessons, including what to do when someone solicits sensitive information.
- Follow through with your testing to see which parts of your incident response plan are properly invoked and enacted.
- Depending on your initial response rate, consider sending a follow-up email or two over a period of a few days.
- After collecting the phishing test results, remove any sensitive information you've gathered (e.g., network passwords) and keep this information and any subsequent reports secure.
- Most importantly, share your results with the organization's management team. Outline the facts, your findings and any lessons learned. Do what it takes to ensure you help educate end users, aiming for a lower response rate the next time you test your Exchange setup. You'll likely never reach zero phishing responses, but they should trend downward as you move forward.
If you don't perform phishing tests in Exchange now, when will you? It's absolutely guaranteed that criminals are phishing in your business. Cut their efforts off at the pass to have a more resilient network environment via proactive means rather than reactive means during a confirmed breach.
About the author:
Kevin Beaver is an information security consultant, expert witness and professional speaker with Atlanta-based Principle Logic, LLC. With over 26 years of experience in the industry, Kevin specializes in performing independent security assessments revolving around information risk management. He has authored/co-authored 12 books on information security including Hacking For Dummies and The Practical Guide to HIPAA Privacy and Security Alliance. In addition, he's the creator of the Security On Wheels information security audio booksand blog providing security learning for IT professionals on the go. Kevin can be reached at principlelogic.com and you can follow him on Twitter, watch him on YouTube and connect with him on LinkedIn.
Prevent phishing with social engineering tests
Use consistent security protocols to stop phishing
Steps to protect against phishing scams