Organizations of all shapes and sizes are vulnerable to social engineering attacks. It’s human nature to want to be helpful and to trust those that ask questions of us. This is especially true from people or organizations we feel has authority over us. This is why phishing attacks are so successful. We give our information over to emails and websites because we feel there is a bond of trust. It’s not about being suspicious or not, we are taught from a young age to trust those within places of power. So our bank asking for validation of our information at first glance doesn’t seem suspicious. Our company reporting a password incident and asking for remediation is perfectly plausible. The problem is unless you’ve heard about the policies from these companies on how they will handle this, the request may be genuine and you want to do all you can to help.

The first step in minimizing your organization’s exposure to a phishing attack is to educate users and have policies they can refer to. The best approach to this is to train them when you first adopt them as users. If you are a bank you post your policies on password and account policies when they first sign up for online service. If you are a private website send them a blurb of information in the verification email (users will glaze over at long privacy agreements so have a summary ready for the email body and append any policies after the main text). If you are an organization/company you educate the users when they are in their new hire orientation. For companies there should be a follow-up yearly or bi-yearly on policy changes and a short training session may be required depending on the amount of education you need to impart to entrenched employees.

Companies should have a corporate website that states if there is a time when the IT needs to request your password and how this will be handled. It is inadvisable to have users respond to any password request with their username and or password in email form. This trains the users to accept this type of reply no matter if it’s a real request or a phishing attack. The same holds true for attempting to collect or update their password information on an internal website.

Some companies to alleviate help desk calls have set up a password reset website internally. Users should be taught to verify they are going to the correct URL before entering any information. To secure these configurations users should log in while they know their passwords and have 2-3 challenge/response questions before it will allow them to change their password. To make this more secure allow your users to make up their own questions since they will recognize the questions they have written themselves and make it harder for attackers to just spoof the site and auto-accept answers to things that are industry default questions such as “Mother’s Maiden Name:”.

Unfortunately, since all authentications are tied together you normally would not want to send a verification email before resetting the password, since the user probably isn’t able to get into email either. You can however make the change temporary for 24 hours unless they click the verification email to confirm they did this make this change. If they do not click the email the account automatically locks and users then have to call the help desk. Inform users of this behavior before implementing this and have it state so implicitly on the password reset page.

We have discussed how to raise user awareness and lower the chance of users unwittingly entering their information but how do we reduce exposure to the users of these attacks? The easiest approach is to handle this at your border infrastructure. For simplification I am going to lump the email infrastructure together in my explanations, these parts are your border firewall, any internal firewalls, your anti-spam solutions, and your internal mail server. I am grouping these together because depending on which product you use for these functions different options are available to you.

The first step for locking this down is to have all of your internal users authenticate before sending mail. Authentication requirements may include authenticated SMTP or IMAP sessions, VPN to the internal network, Webmail, or any other options that give you some sort of confidence level that the user you are responsible for is who they say they are.It will also make the next step a lot easier to implement depending on your current corporate policies.

The next thing you do is disallow any mail from outside your organization to allow a “Sent From:” address. For example, if your domain is “mydomain.com” your mail server will not accept mail from bob@mydomain.com going to sally@mydomain.com unless they have been authenticated via one of the earlier proscribed methods or through a desktop email client internally. Make sure that your external firewall does not perform NAT on incoming packets or otherwise your mail server will think all the mail is from an internal source.

Implement a policy to disallow your internal mail server to accept mail connections via telnet. This can be done by smarter firewalls that inspect layer 7 packets and some mail servers. These devices can distinguish the difference between a mail server or client sending the mail by packet length and activity type compared to manually typing in the message by telnetting to port 25 on your mail server and sending mail via telnet.

For phishing and other reasons, your organizations should develop or subscribe to a real-time blackhole list (RBL).Anytime an individual attempts to your internal mail server in an attempt to spam or perform a phishing operation unsuccessfully against your mail server they can be added to the RBL database. This allows you to track and block attempts from the same IP over and over again and reduce overhead on your internal mail server.

To reduce rogue mail servers on your internal network and enforce traffic to traverse the internal mail server the best method for performing this is to block port 25 on all of your internal routers unless the traffic is destined for your internal mail server. Include another rule that allows only your mail server to send email to the internet on port 25 on your firewall. This helps against internal users that may attempt a targeted phishing attack against another internal user.

The next step depends on how smart your mail-filtering software is. Have a queue where suspect email is forwarded if they include strings similar to your own domain (for example bob@my-domain.com, bob@mydomian.com, or bob@mydomain.com.com)this is all dependent on how well your mail filtering software can detect these misspellings. From this queue have a trusted administrator verify if these mailings are not spam (if so implement appropriate filters) or not a phishing attack (add the IP address to your RBL). Since in the scope of this document, I can not scope out how similar your domain is to another domain that may be sending you mail I suggest this as a last resort if you are under a heavy load of phishing attempts.I would not recommend outright blocking this type of mail since it may interfere with legitimate business.

If you discover a phishing attack that has bypassed your border and made it directly to the user the recommended approach is to immediately send a mail to all the affected users as soon as this is detected. When sending the email alert about this include your standard policy on if, how, and when you will collect passwords or usernames from them when it is a legitimate email. This informs the users that you are paying attention; they can gain confidence that you are monitoring for this type of attack, and they are reinforced when and where to give out their private information.

Phishing attacks will never be stopped one hundred percent, but repetition and education can greatly minimize their impact on your organization.