Security tips for dealing with a rogue user

Taken from a live thread on SearchWindowsSecurity.com's ITKnowledge Exchange forum, the following is part one of a two-part peer discussion about technical tips and legal advice for dealing with a rogue user in the network.

Click here to read part two of this discussion on tips for dealing with a rogue user.

QUESTION From: mouse333 Date Sent: 03 Nov 2005 We have a rogue user who knows more than she should. She can grant herself and other users the authority to access files that are supposed to be secured. Does anyone know how we can monitor her activity or go back and review what she has done? is there anything that we can do? We think she may be using a different User ID. There are several we believe she may be using and we have changed those passwords. She knows we're on to her and probably won't do anything for a while. In the past she has made the comment "if you knew what I was doing, you'd take it away from me." Does anyone have any suggestions?

TIPS & ADVICE Response 1 From: solutions1 Date Sent: 03 Nov 2005 Make sure your procedural and policy ducks are in a row and carefully align what you do and say within that policy. Think through your priorities. Suspecting that one end user acquired "super user" access may have such serious overall implications (e.g., you are a defense contractor or have HIPAA obligations) that perhaps the priority should be a rebuild of your access control structure, because one "known" violation suggests that there could be others. Get line management support at an appropriate level before, say, installing key board capture or other detection measures.

Response 2 From: Layer9 Date Sent: 03 Nov 2005 At this point you want to hire a security professional. It is clear that this user knows more than you do about network security, and you are not going to be able to monitor and control her using the knowledge taken from one post. That's why security consultants work in the field, for just such an occasion.

Response 3 From: bobkberg Date Sent: 03 Nov 2005 Solutions1 has made several good suggestions. First, I'd like to emphasize what he or she said. Before you get into any monitoring situations that are tied directly to the users computer: MAKE SURE that you have line management support on this -- probably HR also. But be prepared for some waffling -- take notes, keep records. That said, there are other things you can do that are general. You didn't specify what operating system(s) you're using, so any technical details are going to differ depending on that answer, so I'm going to have to be general here until you post more relevant details. If you're in a Windows environment: List all of the members of the administrators group and check their login history. Turn on security auditing for logins and for system/file/folder access for likely machines -- then check regularly. If you're in a Unix/Linux environment: Check all user and group IDs for root equivalence or root group membership. If you find more than you know about, then check regularly for login time/date and where it occurred from. If you're using NIS, check all user IDs there also. But -- bottom line -- if you don't get management support, e-mail them about the matter clearly and keep their response. It will be your "Pearl Harbor" file.

Response 4 From: ChinaBJ Date Sent: 04 Nov 2005 You should have both IT rules and technical methods to prevent this from happening again. For IT rules, you can ask help from the TOP management team. For technical methods, in addition to Layer9's suggestions: Install remote control client on her computer from the server and log her actions. Stop Windows 98 sharing and Windows 2000 Server's support for previous Windows authentication. Implement IPSec to encrypt the communications of your server.

Response 5 From: mstallings Date Sent: 04 Nov 2005 If you are using OS/400 or i5 operating systems, check your public access level. You should also check if she has all object authority.

Response 6 From: Layer9 Date Sent: 04 Nov 2005 There are some products out there like Vernier's network appliances, which will allow you to restrict users internally, but you really have to know what you are doing to use them. In order to stop this power user from circumventing your network's security, you will need to bring in a security consultant. You cannot learn what you need to know about protocols, operating systems, security appliances, layer 2, 3 and 4 traffic control, etc. from a post in a forum.

Response 7 From: bouncybrit Date Sent: 04 Nov 2005 No disagreement from me: Make sure all your ducks are lined up. Check your policies and make sure that all appropriate use is defined. Make sure all your users have signed an agreement to the effect that if they access anything that they shouldn't, they are fired (work with your legal team on the correct language). Work with management and HR to get permission to begin your investigation. Hire a professional to come in and run the investigation. Work closely with the person you hire so that you know more when you are done and can avoid the mistakes in the future.

Response 8 From: AMBACISA Date Sent: 04 Nov 2005 All of the other replies to your query appear appropriate. However, in addition to the provided reponses, I suggest your organization enlist the aid of a Certified Information Systems Auditor (CISA).

Response 9 From: TIMWATSON Date Sent: 04 Nov 2005 All posts to this question are very good and should be implemented. You may also try installing a virtual machine, configured to be as alike the installed OS as possible. From there, see if the VM could intercept all input (or as complete a blanket as you can) to include those with admin access or better. This may slow access somewhat. From there begin traces. In addition, you could look for the hidden place where this person is storing her project (or other info). In the PGP manual (RTFM IT many years ago), it says the way a person types his password (cadence and speed) can be a part of his password. I have read recently of software that will track people by the way that they type. Finally, if she really is this good, consider hiring her as head of security, with full legal liability (not meant as a joke).

Response 10 From: Layer9 Date Sent: 04 Nov 2005 It's also possible that she just has someone's password.

Response 11 From: this213 Date Sent: 05 Nov 2005 I have to agree with Layer9 on this -- you should seriously consider hiring a security consultant. I also agree that they may have just gotten their hands on someone's password. While all of the posts have been good ones, I find it interesting that there's been no mention of the authentication mechanism in use, or what OSs and resources are involved. There may be options available to you that would not require your getting approval from anyone (depending on your role and your company's policies). If you know which resources are being accessed, you should be able to trace the accesses to those resources -- whether those resources are files in a file system or user changes in AD. If you're set up so that you're not logging accesses to resources, I would ask why not and strongly encourage you to do so from this point onward. If you're in a Windows environment, there are tools for this -- if you're in a *nix environment, the tools are most likely already in place. Bobkberg makes some good points in this direction. I think the responses regarding user monitoring are reactive at best. If your security is in line, you shouldn't have to resort to this. The only way I would see this as being beneficial would be to set up a honeypot (something TIMWATSON alluded to) and set up monitoring on the systems the attacks are coming from -- which you'll know once you've set up/gone through your access logs. From this, you'll be able to see exactly what was being done to gain access in the first place. However, I'll reiterate that this is purely reactive -- your security should be such that it shouldn't matter exactly what methods are being used at the client level. You obviously have a hole somewhere and you need to plug it -- whether that hole is a corrupt password, improper default user access levels or open ports on your DC. The thinking here is that anyone could walk in and just plug any old machine into the network (because it happens). Your network security should be such that it would be protected from that machine just as much as it's protected from any registered client on the network. As far as monitoring just to "catch them in the act," you should already have all of the evidence you need in log files as to who did what -- again, if you don't have such logs, I would ask why not. I would also suggest that you have your network penetration tested, both externally and internally, even if it does turn out to be just a corrupted password. You never know how strong something is until you try to break it. Besides, you're probably going to have to get penetration tested sooner or later to comply with federal regs. As a final note: Document everything. Create a situation file for this and get hard copies of all the logs from the affected systems (just the pertinent parts, mind you) and put them in there. Also document your actions to remedy the situation and put that in there also. Send e-mails to your higher-ups detailing the situation as best as you can, inform them of said file and its location -- and let them know how they can view a *copy* of the contents of the file. Put any e-mails regarding the situation into the file as well. Note that I said a *copy* of the file, always follow the maxim: CYA. The bottom line on this file is that anyone (management, auditors, etc.) should be able to open that file and see the entire situation -- as bobkberg stated, it's your "Pearl Harbor" file.

Click here to read part two of this discussion on tips for dealing with a rogue user.

Start your own discussion
Do you have a Windows security dilemma that needs quick attention? Talk about it in ITKE.