Manage Learn to apply best practices and optimize your operations.

Security tips for dealing with a rogue user

A rogue user in your network has gained access to files that are supposed to be secure. To what extent has your network been compromised? Your peers provide technical tips and legal advice on dealing with this sensitive situation.

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

  1. Make sure your procedural and policy ducks are in a row and carefully align what you do and say within that policy.

  2. 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.

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

  1. List all of the members of the administrators group and check their login history.

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

  1. Check all user and group IDs for root equivalence or root group membership.

  2. If you find more than you know about, then check regularly for login time/date and where it occurred from.

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

  1. Install remote control client on her computer from the server and log her actions.

  2. Stop Windows 98 sharing and Windows 2000 Server's support for previous Windows authentication.

  3. 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.


    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 last published in November 2005

    Dig Deeper on Windows Server and Network Security

    PRO+

    Content

    Find more PRO+ content and other member only offers, here.

    Start the conversation

    Send me notifications when other members comment.

    By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

    Please create a username to comment.

    -ADS BY GOOGLE

    SearchServerVirtualization

    SearchCloudComputing

    SearchExchange

    SearchSQLServer

    SearchEnterpriseDesktop

    SearchVirtualDesktop

    Close