Insider Attacks From Outside the Firewall Written by Gideon J. Lenkey

When times get tough, things change for everyone, and sometimes employees don't like changes that management makes. This can be especially true if the employee is being "laid off." But what about laying off people with specific and valuable knowledge about your business? That's not an easy call, and it's certainly a risk.

While no one likes to hear that their job position has been eliminated or another person will be doing it, some people will take it very personally, and a small subset of those people will actually attempt to take some sort of revenge.

Sometimes the revenge manifests itself as feeling entitled to the work product they produced while at the company -- a customer list or program source code, for instance. Other times it can take the form of sabotage, such as destroying data or rendering critical computer systems inoperative. While ways to cause damage to a company or former employer are limited only by imagination, we'll keep the focus on things that are information-system related.

Recently I investigated a case where a laid-off employee intruded into the corporate network of his former employer from the public Internet and rendered critical computer systems inoperative, which caused serious damage. It wasn't the first time I've seen this, and it won't be the last. What I'd like to share is what you can do in advance that makes investigating such incidents a smaller and more effective effort. A little preparation will also make the effort much cheaper.

While preventing an incident is obviously the ideal, it's not always possible to defend against a motivated attacker with specific knowledge about the internal workings of a company. Also, what if the individual is a privileged user on the network, such as an administrator, or a help desk or tech support operator? This person could potentially have access to other users' account information and may actually be able to make new accounts for the purposes of covert or continued access from the Internet to the corporate network beyond the scope of employment.

By now, most companies have basic protective controls on their networks such as a firewall. If your company is a little more forward-thinking, perhaps you've also already deployed an application proxy. These controls are necessary and good at what they do, which is controlling the network border with the Internet, denying the known bad traffic, and allowing the known good, at least in theory.

Maybe your company also has an IDS (intrusion detection system), which will look for known signs of malware or abuse and send out an alert; or maybe you have an IPS (intrusion prevention system), which will attempt to block it. All of these things are good and necessary. But what happens when Biff from sales gets fired and logs back into the network via the VPN using Brad's (also from sales) password? He knows Brad's password because he sits next to him and saw the Post-It note/heard him on speakerphone with tech support/or simply guessed it (G1ant$rule!).

The problem here is a simple one: Every rule was followed during Biff's termination -- his accounts were deactivated and he was walked out of the building -- but he was still able to remotely log back in to the network, likely with similar privileges as he had in his former position. Despite the company following industry best practices, the firewall, proxy, IDS, VPN, and even the Windows Domain all see this as a legitimate log-in, though it isn't.

So what can you do? How about trace the IP address? Sure -- it's a library gateway for hundreds of branches around the city... Have fun storming the castle!

This sort of access can go on unnoticed for quite some time, depending on the password policy -- and even then if the attacker can install a key logger, it'll just email him the new credentials anyway. Remember, email is legitimate, allowed traffic!

Here are some thoughts on how to manage this sort of risk:

* Make sure you keep all of your VPN, Domain, and Critical server logs on a separate server. The audit function must be also be separate from IT so that compromised Adminstrator accounts cannot delete or manipulate log data.
* Make sure you can make reports on those logs. There are plenty of third-party products that make this easier; I'm sure some of you folks can chime in with your favorites.
* Record and report failed VPN or remote log-in attempts. Recognizing this clue to impending abuse originating from the Internet early on can really save your bacon.
* Single-factor authentication must die! I know I'm preaching to the choir, but two-factor authentication, while certainly not infallible, raises the bar for remote access abuse on a would-be attacker.