Click here to read part two of this discussion on tips for dealing with a rogue user.
|
QUESTION 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
|
|
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 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:
If you're in a Unix/Linux environment:
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:
|
Response 5 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 No disagreement from me: |
|
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 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 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.
About the ITKnowledge Exchange
ITKnowledge Exchange is a place where IT pros can share ideas, expertise and get answers to their technical and strategic questions. It provides direct access between groups or individuals who are grappling with similar IT issues in a safe and seamless environment. Click to start participating today.
This was first published in November 2005
Enterprise Server Strategies for the CIO
Join the conversationComment
Share
Comments
Results
Contribute to the conversation