Re: Tracking back internal incidents to users, not IPs

["John H. Sawyer" <jsawyer () ufl edu>]

Hey Charles,

I recently reviewed three products that do what you are looking for.
ConSentry Secure LAN Controller [1], Arbor Network's PeakFlow X [2] and
PacketMotion's PacketSentry [3]. They all work with Active Directory
while that latter two _only_ work with AD. They also vary from being
network control devices that can't prevent access based on policies or
attacks to being in-depth auditing devices. All of them track the
user/IP/MAC so you can attribute network activity to the right users.

Each product has been reviewed by Network Computing [4] and Secure
Enterprise [5] magazines.

[1] http://www.consentry.com/products_slc.html
[2] http://www.arbornetworks.com/products_x.php
[3] http://www.packetmotion.com/products.html
[4] http://www.networkcomputing.com/
[5] http://www.secureenterprisemag.com


-jhs
-- 
-------------------------------
John H. Sawyer - GCFA GCIH GCFW
    UF IT Security Engineer
-------------------------------


Charles Kaplan 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.
------------------------------------------------------------------------