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 web sites 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 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 back 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 web site send them a blurb of information in the verification email (users will glaze over at long privacy agreements so have a summary prepared 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 on entrenched employees.
Companies should have a corporate website that states if there is a time where the IT needs to request your password how this will be handled. It is inadvisable to have users to 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 helpdesk calls have setup a password reset web site internally. Users should be taught to verify they are going to the correct URL before entering any information. To secure these configuration users should login while they know their passwords and have 2–3 challenge/response questions before it will allow you 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 minimize the chance of users unwittingly entering in their information but how do we minimize exposure to the users on 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 allow a “Sent From:” address. For example if your domain is “mydomain.com” your mail server will not except 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 methods 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 (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 that these mailing are not spam (if so implement appropriate filters) or not a phishing attack (add 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 mails 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 effected 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 it’s impact on your organization.
Recent Comments