Insider Threats - How Do You Protect Against Them?

Published: 2008-07-16
Last Updated: 2008-07-16 17:15:03 UTC
by Chris Carboni (Version: 2)
3 comment(s)

Chris writes

"I read about the situation out in San Francisco on Slashdot this morning, where a disgruntled administrator locked everyone out of the system he was responsible for after learning he was going to be fired.

I was wondering if the handlers or readers had any advice on protecting the Windows Administrator account, or any advice on protecting the organization from insider attacks of this sort in general?"

Now, I haven't yet read that article but as I mentioned to Chris if an administrator finds out before hand he is to be fired, that also is a break down of information security.  Policies and procedures need to be in place to prevent exactly this kind of thing from happening.

Send in your suggestions for how you protect your organization and network from the people who manage it and I'll post some of the submissions later in the day.

My belief is that you have to trust the people who manage the systems.  If you can't they shouldn't be there.  Trust, but verify.  :)

-Chris

Update:

Gary writes,

Normally people are disgruntled on how things are handled. usually the person being fired is the last to know, and thats the wrong way to handle it. Rumours spread and eventually some one spills the beans. mangements needs to handle things alitte more "personal".

I have seen a pow-wow of "trusted" admins and network security people being given priviledged information, such as releases and firings, and they assess whether the person is trustworthy til their last day. Thats decided first - before they inform the individual. That way the person leaving can fall into 3 categories. Continue working as normal til the last day, and allowed to look for work elsewhere. The second is an escorted out of the building, and given a 2 week payed at home option. That person is a "mild threat" more of bragging about how much more they can make at another job, and just stirring the hornets nest as a last act. Then of course there are the disgruntled that are simply ousted and let go.

How do you protect against such a thing? Create different groups with limited priviledges. Not everyone, including admins need rights to everything.

Worse than kicking out all admins, or in conjuction with a mass eviction, is the threat of an admin going into the server room and lowering defenses, removing patches and making the network vulnerable to the outside world. How long would that go undetected in a stereo-typical IT world?

Log viewing and auditing is important, but that takes waaaaaay too much time, effort and manpower and money for software automation. All that typically is worthless anyway, if the "act" is performed at the end of a day, say on a Friday evening.

Breaking back into your network is painful, and it may work with ERD commander or a Linux Boot disk, but messing with a DC (domain controller) to get back into your network is like playing with Nitro glycerine on a bumpy road.

Short of limiting priviledges to each security group, and possibly having a Domain controller set off in its own area with limited (enterprise level acess only) access only, it becomes tough to control such a thing - unless there is a 3rd party software to prevent this from happening?

All I have to say is there needs to be a national registry that people who do this are entered in. That way the digruntled will not work for some one else, and do the same thing. If they are hired for an IT area again, the company knows they will have to put some protections in place in order to prevent this from happening again.

I am sure the non disclosure for admins can have a statement about adding disgruntled employees that docking of pay, arrest, and restitution for company downtime / repairs will be initiated after a extensive investigation. That will make people think twice.

My job is information assurance. Its simple, trust no one, but respect them for the (honest) things they do.

Thanks Gary!

I'll summarize the thoughts of fellow handler Swa Frantzen who I'm sure will feel free to correct me if I misunderstood anything.

Watch your logs which are moved beyond the reach of the admins for 'normal' unusual activity as well as 'sneaky' unusual activity.   It's not a bad idea to ask a few questions from time to time as well.  This let's people know activity is being watched and can be a deterrent itself.  Yes, this will take quite a bit of time and the software to be able to do this effectively isn't cheap but, protecting against insider threats is important in certain environments.

Segregate and rotate duties.  No one should have all the keys to the castle at the same time and where possible, job duties should be rotated. It's much harder to hide long term malicious activity when someone else will be responsible for a given area when you rotate out.

Please make sure to read the great comment posted earlier as well.

More updates to come as suggestions arrive.

 

 

Keywords:
3 comment(s)

Firefox 2.0.0.16 fixes two security vulnerabilities

Published: 2008-07-16
Last Updated: 2008-07-16 10:02:33 UTC
by Maarten Van Horenbeeck (Version: 1)
0 comment(s)

The Mozilla Foundation has just released Firefox 2.0.0.16 which fixes two critical security vulnerabilities:

MFSA 2008-35 (CVE-2008-2933) Command-line URLs launch multiple tabs when Firefox not running
MFSA 2008-34 (CVE-2008-2785) Remote code execution by overflowing CSS reference counter

It should be noted that the second vulnerability would also affect users that run Thunderbird with Javascript enabled for e-mail reading. Needless to say this is a no-no. We recommend users to upgrade their Firefox installation. Firefox 2.x will still be supported only until mid-December, so investigating and planning an upgrade path to Firefox 3 is advised.

0 comment(s)

Comments


Diary Archives