Rules keep users from becoming Phish food

I delivered a bittersweet message to a CEO last week.  We had completed an external penetration test that included social engineering and phishing.  While the client had made many improvements since our last penetration test, a couple helpful end-users helped us bypass their security enhancements.  The message I shared went something like this —

“The URL filtering solution you deployed last year prevented several of our phishing attacks.  In fact, it successfully prevented your end-users from accessing the malicious websites we created to trick your end-users.  This is a great improvement from a technology perspective.  Unfortunately, two of your end-users replied to the phishing email.  One simply shared their username and password when they couldn’t get to the blocked website. This gave us access to their corporate email account.  The other user downloaded and installed the custom “program” we emailed them to help them trouble-shoot the problem.”

It would be easy at this point to highlight how careless end-users can be.  But this post isn’t about how easy it is to bamboozle employees.  No, this post is about a CEO’s realization that more technology won’t solve the “human element” problem (and that’s refreshing.)  He responded to my summary above by asking what protocols they should create and follow to make certain his corporate staff aren’t tricked by intruders pretending to be the help desk or IT support.  Having worked for the Air Force as a teenager, served in the Navy as an adult, and worked within the walls of the NSA, I know a thing or two about security and communications protocols.  I suggested the following:

  • Instruct end-users that no one within the company will ever call or email them regarding patches or software installations.  This includes the Help Desk and IT. Instead, this protocol will be used:
  • The IT Manager will contact the Chief Operations Officer (COO, equivalent, or designated rep) with the details of the emergency update or software install.  The COO will authenticate the email with a phone call to the IT Manager or face-to-face confirmation. Nophishing
  • Once authenticated, this email will be forwarded by the COO or designated rep to the Department Heads.  The Department Heads will verify that the email thread includes request and approval between the IT manager and the COO (or equivalent).  If this is missing, the email is a fraud and must be reported immediately.
  • The Department Heads will forward authentic emails to their direct reports or staff.  Like the Department Heads above, the end-users will verify that the thread includes IT Manager to COO to Department Head forwards.  If this is missing, end-users must report the email immediately.
  • Only after this protocol is followed can an end-user follow the instructions outlined in the email.

Other organizations I’ve worked with also include a keyword that is changed each month and shared between the executive staff and the Department Heads.  Security related emails that do not include this keyword are deemed fraudulent and reported to the security manager.

Now, before you say, “This protocol is too hard — there’s no way we could do this!”, keep this in mind — under normal circumstances you’ll be using software distribution and patch management tools.  You won’t be emailing or phoning end-users and asking them to install a file or follow a link.  Why? Because contacting users directly via phone or email is what the bad guys do.  Since common sense isn’t a commodity, your users need to know how to tell the difference between the real IT team and a fake one. You can’t do that with technology alone.

Without a security protocol that users can follow, they’re at the mercy of creative social engineering tactics.  If you have a protocol you’d like to share, let me know. I’d be happy re-post it here.

— Simon

Leave a Reply

Your email address will not be published. Required fields are marked *