Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Tracking back internal incidents to users, not IPs |
|---|---|
| Date: | Tue, 21 Feb 2006 21:22:46 -0500 |
Hmm... Working on username tracking at Mazu are we? Check with the guys at Arbor, I think they have something already based on a DC agent and AD integration. Don't know if it works or not. Can't comment on our own efforts in this department. ;) Anyway, this is not an easy problem to solve especially as a vendor that needs to support many unique customer environments and authentication strategies. Good luck and welcome to Ar-One-Zu-Cope. -Adam P. On 2/20/06 10:38 AM, "Charles Kaplan" <ckaplan@mazunetworks.com> wrote:
Given the wealth of expertise here, and the combined hundreds of years of seat of the pants experience dealing with IDS alerts/incidents, I was curious how most of us were figuring out users to contact VS system IPs. Given that this is the 'last mile' for many of us, I believe it an ok topic for this list. My personal interest is as it relates to internal to internal incidents, but it has lots of overlap with external to internal and internal to external incidents as well. Say for example you detect port scanning originating from an un-authorized internal system, how do you go about getting a user name? Note that I am assuming that the source is a DHCP system here (otherwise it is much easier problem). I realize there is a lot of industry talk around DHCP, DDNS, user auth (say Active Directory), NAC and such, but looking at real situations today I am very interested in how people are solving this problem. I am often given an internal IP# on my own network and asked to call the user and ask them why they are doing something strange. I would ideally like to use some kind of extended NSlookup to tell me who to call. And while I won't be a spokes person for Microsoft any time soon, I think it safe to assume that I would like to somehow find this info stored within AD. And yes, I realize that for the info to get to AD, it must be a credentialed user, and maybe this is an area to debate, but I am simply looking for ideas based on how others have solved this, not a 100% perfect solution. Thoughts? Note that I would take an open source or a commercial product as a viable answer. Thanks ________________________ Charles Kaplan ------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly? Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more. ------------------------------------------------------------------------
------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly? Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more. ------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Tracking back internal incidents to users, not IPs, Michael Allgeier |
|---|---|
| Next by Date: | Re: Testing IDS with tcpreplay, Aaron Turner |
| Previous by Thread: | Tracking back internal incidents to users, not IPs, Charles Kaplan |
| Next by Thread: | Re: Tracking back internal incidents to users, not IPs, Kevin |
| Indexes: | [Date] [Thread] [Top] [All Lists] |