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.  :)



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.



3 comment(s)


Putting my old CPA hat back on:
Concept 1: which is embodied in the concept of the auditor's view of separation of duties. In this case, minimum of two administrators with segregated duties. Some mix of permission allow's and deny's that is different for each of the administrators and tailored to their duties.
If there has to be the uber administrator account, and you don't have multi-factor authentication (e.g. RSA and the like) put the uber administrator login name and password in a sealed envelope and give it to internal audit to be locked away in a fire safe (more separation of tasks and duties.) If the uber administrator account is opened and used then it must have the name and password reset, then be locked away again.
Concept 2: Edumacation, especially for the HR department and the supervisory chain as to the risks of this type of personnel or contractor dismissal. (Yeah, it may be a "good-thing" to let your "friend" the admin, know about pending action, but what about your duty to the organization and its well-being? Consider the consequences and responsibilities of shooting your mouth off....)
Concept 3: Role based security. Maybe the administrator saw some new list, report, org chart, internal phone book or such, on-line or in a group printer's output bin which waa the key to letting the cat out of the bag. The role based security system should not let you see extraneous data which does not go with your job and role.
Concept 4: Configuration Management Data Base - and by this, I mean not something some intern put together last summer, but a daily operating data base with maintenance, reporting, security, procedures/practices, backup/restore and auditing/exception alarming.
Concept 5: Good hiring or contracting entry procedures, where policies and procedures are given to the employee or contractor, legally signed for, and violation penalties enumerated. The rules of the road need to be known and acknowledged from the outset.

I'm sure that there are a whole bunch of other ideas that can be found in most standard references, but these are a few that I just pulled off the top of my head, the same way you get that semi-technical question in the hallway...

San Francisco was currently hit by an insider threat:
Segmentation and rotation of administrative roles should help to mitigate risks, but there is no foolproof method for preventing insider threats from administrators. Even a "super admin" who has authority over administrators is a potential insider threat. Who will administer the administrators of the administrators? The cycle can be endless.

Perhaps secondary confirmation of key systems changes, much like banks require for wire transfers from a company's accounts would help mitigate this kind of risk? Require a second administrator to authenticate a password change or core configuration change in certain systems. Banks protect their customers from disgruntled employees with access to money by requiring secondary authorization for transactions; why wouldn't this model work in large corporate IT environments?

In the end, though, the cause of this problem with Mr. Childs started as an HR issue, and ballooned into a larger and more technical issue. Administrators are held to a higher standard than the average user, because they are trusted with more information, access, etc. If an administrator cannot be trusted, their job history should follow them and prevent them from working as an administrator in future. In positions that involve a high level of trust, breaking that trust should incur a much higher penalty.

Diary Archives