Event log perspectives (local v. remote)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Event log perspectives (local v. remote)

heinbockel
>This leads to a question that I have.  Does the perspective of how an
>event is logged change the information expressed in the event?  For
>instance, if a logon fails from a local user at the console versus a
>remote user from across the network, is the information needed
>different
>or the same?
>
>Then a follow-up question would be what perspectives are present in
>events?  Does anyone have thoughts on this topic?
>

My initial reaction is that, yes, there are different perspectives
and information associated with local vs. remote login events.

For local logins, the user has physical access to the machine. For
IA, a failed login on a local terminal means that either (1) a user
has fat-fingered their password; (2) an insider is trying to break
into someone's account; or (3) someone has gained access to the
system (breaking and entering, has stolen a laptop, etc.).

For remote logins, there is the additional data of the remote system
(IP, MAC, OS, etc.). Also, there are concerns such as whether the
system should be exposed for remote logins, whether the login is being
attempted from inside or outside the network perimeter, and other
network-based questions.

I would care much more if there are many local login attempts to my
machine than remote attempts. Also, for potential log use cases such
as prosecution and investigation scenarios, you bet that they care
about whether login attempts are local or remote.

Reply | Threaded
Open this post in threaded view
|

Re: Event log perspectives (local v. remote)

Eric Fitzgerald
There is probably a common set of information that is desirable across all events, e.g. timestamp, event source/type/id (identification of the schema for the event), severity, etc.

There is probably a common set of information that is desirable across all login events, e.g. the identity of who logged on, authentication mechanism details, etc.

There is, as Bill pointed out, additional information that is useful in certain kinds of login events that might not be applicable to other kinds of login events.

Think of it as subclassing:
+ Event
|-+- Logon Event
| |--- Local Logon Event
| |--- Remote Logon Event

The local/remote distinction is not necessarily useful nor even clear.  What if you log in via a remoting mechanism such as Terminal Services or VNC, vs. sitting at the physical console?  Is that local or remote?  It has characteristics of both.

For that matter, what is a login?  Is it the act of validating a set of credentials or does it also include the act of creating local state and a communication channel for that user to use to interact with the computer?  "Local" logins use human interface devices as the communication channel; "remote" logins use a network channel.  "Remote interactive" logins use remote human interface devices whose output is remoted over a network channel.

For Windows, a login event indicates the creation of a logon session data structure and the associated token, which is effectively cached authorization data.  There are 12 different login types in all, each with different characteristics and threats.

Perhaps you can use a common schema for all login events and just differentiate by event contents- this is what Windows Vista and Windows Server 2008 do.  Or perhaps you can use a different schema for each kind of login event.  This decision affects SEM vendors (who must discover and consume each of the schema) and software vendors (who must implement instrumentation that emits events which comply with the schema) and users (who must consume the events and understand each schema).

The bottom line is this:

1) Events ultimately are generated by instrumentation.  The point of instrumentation dramatically affects the kind of information that is available in the event (or can require significant work to transport desired information to the point of instrumentation).  Software vendors benefit from standards like CEE by knowing what to instrument and what to put in their event records.
2) We should identify commonalities in event records wherever possible to generate the most efficient schema; having a simple schema benefits SEM vendors and end users (I would agree that it's unclear how much this benefits SEM vendors).

Eric



-----Original Message-----
From: Heinbockel, Bill [mailto:[hidden email]]
Sent: Thursday, November 08, 2007 7:07 AM
To: [hidden email]
Subject: [CEE-DISCUSSION-LIST] Event log perspectives (local v. remote)

>This leads to a question that I have.  Does the perspective of how an
>event is logged change the information expressed in the event?  For
>instance, if a logon fails from a local user at the console versus a
>remote user from across the network, is the information needed
>different
>or the same?
>
>Then a follow-up question would be what perspectives are present in
>events?  Does anyone have thoughts on this topic?
>

My initial reaction is that, yes, there are different perspectives
and information associated with local vs. remote login events.

For local logins, the user has physical access to the machine. For
IA, a failed login on a local terminal means that either (1) a user
has fat-fingered their password; (2) an insider is trying to break
into someone's account; or (3) someone has gained access to the
system (breaking and entering, has stolen a laptop, etc.).

For remote logins, there is the additional data of the remote system
(IP, MAC, OS, etc.). Also, there are concerns such as whether the
system should be exposed for remote logins, whether the login is being
attempted from inside or outside the network perimeter, and other
network-based questions.

I would care much more if there are many local login attempts to my
machine than remote attempts. Also, for potential log use cases such
as prosecution and investigation scenarios, you bet that they care
about whether login attempts are local or remote.