My professional life has been full of clients devastated by trusted, internal attackers. In every case, the damage done amounted to hundreds of thousands of dollars. In one case, the victimized company incurred costs exceeding $1 million in recovery efforts. Everyone involved is bound by a nondisclosure agreement, so none of these cases has made the news, even though the service outages have been significant and widespread.
Despite multiple efforts over the last two decades, there is still no cost-effective way to stop a trusted insider from doing tremendous damage when they feel so motivated. The best you can hope for is early detection to limit the damage. Many of the preventive efforts I've been involved in have focused on tightening access controls and improving logging and alerting.
I've said it before and I'll say it again: One of the best things you can do to get early warning of internal attackers is to implement honeypots. I don't say this simply because I wrote a book on the subject. I recommend honeypots because they're low cost and low noise -- and they work!
Because the internal attackers you seek could be trusted IT employees, the entire project must be kept secret. It should be known only to the sponsor, management, and the implementers. Often, we give the project a boring code name like Marketing Business Development, which is used in all documents and e-mails, avoiding terms having anything to do with honeypots. Don't even tell the network security people about it, in so far as you can and still have an operational project. Then take a few computers that are destined for de-provisioning or the scrap heap and turn them into your honeypots.
Honeypots by their very nature are fake computers that nothing should ever attempt to contact. Their sole purpose in life is to note any connection attempt and report it for immediate investigation. Normally after setting up a honeypot, you'll spend a few hours (or days) filtering out all the normal, legitimate broadcast traffic, plus that of any of the other legitimate computers that normally search the network looking for systems to install software on (anti-virus servers, software install managers, and so forth).
One of the biggest questions is what type of honeypot software to run. The easy choice is just to use the software already installed on the computer, be it Windows XP, Windows Server 2003, or an old version of Linux/Unix. Give the computer an interesting name, so that it looks like a legitimate server in your environment. Make it look like a database, Web, or file server to get the most attention. Configure the logs to note any connection attempts and to send an alert to the appropriate help desk or response team. Naturally, when events are noted and get a response, keep communications vague. The honeypot administrator should tell the response/investigation team only that suspicious activity was noted by an intrusion detection node or something like that.
If you want to learn more about the hacker's intention, you can make up several different honeypots, each mimicking varying degrees of sensitive data. For one client, I set up some honeypots to mimic online game servers and others to mimic the storage of sensitive data. We made the latter servers look like repositories of top-secret data on the space defense missile shields and Pakistani/Afghanistan espionage. We used directory structures and names sure to attract intruders interested in that type of content. Then we copied slightly related content, freely available in the public domain, into our new "top secret" databases. We used Task Scheduler and cron jobs to keep the content updated and fresh to further fool inquisitors. These types of honeypots, which are elaborate enough to allow intruders to do some exploring, are known as high-interaction.
In most scenarios, though, we just want to note the connection attempt, which is, by itself, very suspicious. You can do that with a low-interaction honeypot. Without a doubt, my favorite honeypot software program is KFSensor. No other honeypot software is as easy to use and feature rich.
Another great resource is the Honeynet Project. Besides providing lots of honeypot content and documentation, it contains a nice list of free honeypot programs, including my open source favorites, Honeyd and the Honeywall CDROM.
I recommend that most clients set up two or three honeypots inside each main datacenter location. Be sure to block all connections from the honeypot to destinations outside your network to prevent illegitimate use of a compromised asset against an innocent third party. You can use a host- or perimeter-based firewall, or do something as simple as slightly "misconfiguring" the gateway IP address so that the honeypot system cannot communicate outside its local segment.
Many of the honeynet projects I have worked on stored all logs and network activity (using network sniffer programs) to a SQL database, but you don't need that level of sophistication. The key point to a honeypot early-warning system is to set up good logging to generate actionable alerts.
I've been setting up honeypot systems for nearly a decade now. In every case, the client has called back to thank me. They caught good people doing bad things, trusted insiders exceeding their authorized authority, external attackers that made it inside, or previously undetected malware -- such as Conficker looking for drive shares and guessing at passwords.
A honeypot can't be guaranteed to catch an internal hacker before any damage is done, but it's one of the best chances you'll have.