Re: Tracking back internal incidents to users, not IPs

[Kevin <kkadow () gmail com>]

On 2/20/06, Charles Kaplan <ckaplan () mazunetworks com> wrote:
> 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.

In my experience, handling customer incidents is handled pretty much
the same for corporations as for ISPs --  by reviewing audit logs.

One advantage in a private network is that you are likely to have
end-to-end control, and if a machine shows up as doing something
not-quite-right on the network, you have a good chance of being able
to take physical possession of the box.  Seldom an option for a
traditional ISP :)


> 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?

In the past  when all we had to go by was which hub port had the
highest blink rate, I've been known to walk downstairs, find the right
jack number, trace the cable to one particular dustbunny-covered CPU
and loudly ask "Okay, who use the workstation named... (read windows
login screen) 'sweetums3'?"

Since then most corporations have upgraded to managed (usually Cisco) switches.

Assuming the information security group has been empowered to take
action (not always a safe assumption in a corporate environment), my
first priority would be to track down the switch port and shut it
down.

This stops the scan, and gives an approximate physical location to
send in the guards (or at least the PFY with a pair of cable cutters
and a "get out of jail free" card signed by the CSO).


> 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

Something like nbtscan or NetBIOS Audit Tool can sometimes get the
workstation to tell you what it thinks it's own nodename, username and
MAC is, but a smart attacker will have disabled or even boobytrapped
TCP/137.


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

I've been told that AD has all this, and also makes curly fries.

I don't have access to the corporate Active Directory details, so I
usually use Cisco commands to isolate the hardware address and switch
port, and then check the DHCP server logs for further details.


> 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?

If implemented correctly, NAC along with a good audit log should
address this need.

Kevin Kadow

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